Critical PostgreSQL bug tied to zero-day attack on US Treasury A high-severity SQL injection bug in the PostgreSQL interactive tool was exploited alongside the zero-day used to break into the US Treasury in December, researchers say. Rapid7's principal security researcher, Stephen Fewer, disclosed CVE-2025-1094 (8.1) on Thursday, saying it was a key part of the exploit chain that also …
The commentards missed the mark by miles, but for one small thing.
Emperor Elon said that the US government doesn't use any SQL databases.
Which I knew was nonsensical, as we had tons of PostgreSQL and Oracle databases that I monitored the patch level of.
Made a statement based upon an assessment that was, to put it gently, based upon a hilariously erroneous view of reality.
As for this, hairy zero day attack that'll get patched quickly enough, such always get pushed to the high priority list due to an actual attack involving that bug.
Anonymous, lest I get a visit that they'd briefly not enjoy.
For the underlying bug to be of consequence you have to have psql exposed to be invoked with user-input or your server was already compromised (but then it was already game-over).
I always thought that you never ever had these command-line tools exposed to direct or indirect (external) user input, regardless whether the data is escaped or not. The risk of introducing problems are so high when you give (indirect) access to psql... The tool can do so much that it shouldn't be exposed directly or indirectly to anything touching external users.
And, sure, the underlying bug is bad and we are all happy that it is (will be) fixed. But, some common sense in separation principles could have prevented the chain of events in the first place.
Have to agree with you and the real bug is somewhat obscured by some fairly hair-raising deployment practices: it should never really get that far:
$(echo "SELECT COUNT(1) FROM gw_sessions WHERE session_key = $quoted AND session_type = 'sdcust' AND (expiration IS NULL OR expiration>NOW())" | $db)
Where $db = /path/to/psql. I mean, really?
Not only do we have the underlying bug in Postgres, but also quoting to the shell and a requirement for psql locally and apparently without further authentication.
But I'm impressed by the skills of the exploit.
As soon as it became clear how this worked I was screaming "why would you run SQL statements that way?". *Especially* because the part of this doing the scripting is a PHP script, and you could just use a prepared statement with that rather than risking any shenanigans at all the the CL psql command !
"He could be right: all their systems could predate SQL..."
OK, then this bug couldn't happen, since it involved SQL.
Some systems do indeed predate SQL, they use a fair number of mainframes. Many other systems do use various SQL databases, from Postrge to Oracle and others in between. Wouldn't be shocked to see some old btrieve ones too. The magic trick is making sure everything is up to date in software update patches.
Can I please , one day, stop having to flag sql interpolation bugs from jr or stupid developers. No, "but I escaped it" is not enough. Theres a reason there are multiple escape implementations in PHPs mysql escape code, because its always been a risky approach.
All modern DB libraries (And by modern I mean "More recent than 25 years ago") support prepared queries. Use it. Its not a complete guarantee (theres all sorts of ways you can goof an SQL insert) but it makes 99% of SQL injection bugs moot.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
