What Happened
In December 2024, state-sponsored attackers exploited a PostgreSQL SQL injection zero-day to infiltrate the US Treasury. This vulnerability allowed them to bypass authentication controls and access sensitive government systems. Alarmingly, SQL injection was responsible for 12% of all data breaches in 2025, up from 9% the previous year.
Despite being a well-documented vulnerability for over 15 years, the attackers exploited this fundamental flaw, which has persisted since the early 2000s.
Timeline
Pre-December 2024: The PostgreSQL zero-day existed undetected in production Treasury systems. There is no evidence that defenders were aware of the vulnerability before it was exploited.
December 2024: State-sponsored actors identified and exploited the SQL injection vulnerability. While the specific entry point remains classified, the attack vector was confirmed as SQL injection against a PostgreSQL database.
Post-breach: Treasury initiated incident response. The PostgreSQL community released emergency patches. The incident highlighted the ongoing prevalence of SQL injection attacks, even in high-security government environments.
Which Controls Failed or Were Missing
Input Validation Failure: The application accepted unsanitized user input directly into SQL queries. This was the root cause—developers concatenated user-supplied data into a SQL string without proper escaping or parameterization.
Code Review Gaps: The vulnerable code passed through the review process unnoticed. This suggests the vulnerability existed in a legacy component or third-party dependency that escaped modern review standards.
Static Analysis Blind Spots: If static analysis tools were used, they either didn't scan this code path or the findings were ignored. Many organizations fail to act on static analysis results, particularly for lower-priority systems or inherited codebases.
Runtime Protection Absence: The application lacked web application firewall (WAF) rules or runtime application self-protection (RASP) controls that could have detected and blocked SQL injection attempts. These measures provide a critical safety net.
Dependency Management Weakness: If the vulnerability existed in a third-party library or framework, it indicates gaps in software composition analysis and patch management. Organizations often neglect the dependencies that make up 70-80% of modern applications.
What the Relevant Standard Requires
PCI DSS v4.0.1 requires public-facing web applications to be protected from known attacks through automated solutions that detect and prevent web-based attacks, including SQL injection.
OWASP Top 10 2021 lists injection attacks as the third-highest web application security risk. It requires parameterized queries, stored procedures with parameterized inputs, or ORM frameworks that automatically parameterize queries.
NIST 800-53 Rev 5 Control SI-10 mandates that applications validate information inputs to prevent injection attacks, with server-side validation being authoritative.
ISO/IEC 27001:2022 Annex A.8.3 requires secure coding principles, including input validation, output encoding, and the use of parameterized queries to prevent injection attacks.
The standards are clear. The gap lies in implementation and enforcement.
Lessons and Action Items for Your Team
Audit Your Query Construction Patterns: Search your codebase for string concatenation in SQL contexts. Look for patterns like "SELECT * FROM users WHERE id = " + userId. This can be done quickly with tools like grep or a static analysis tool.
Enforce Parameterized Queries at the Framework Level: Configure your ORM or database library to reject non-parameterized queries. Enable this feature to prevent developers from writing vulnerable code.
Fix the Legacy System Problem: Wrap legacy components with input validation layers. Deploy a WAF with SQL injection rules in front of systems you can't immediately refactor.
Make SAST Findings Blocking: Ensure your CI/CD pipeline fails builds on SQL injection findings. Set a threshold where high-severity injection findings block deployment.
Test Your Third-Party Dependencies: Run DAST tools against applications using third-party frameworks and libraries. Include dependency scanning in your security testing program and prioritize patches for data access layers.
Train Developers on Prepared Statements: Continuously educate your team on SQL injection prevention. Make it part of your code review checklist and use vulnerable queries as teaching moments.
The Treasury breach shows that attackers exploit fundamental vulnerabilities when available. Your organization likely has similar SQL injection risks in production. Prioritize fixing them before someone else finds them first.
