Critical PostgreSQL bug tied to zero-day attack on US Treasury(theregister.com)
theregister.com
Critical PostgreSQL bug tied to zero-day attack on US Treasury
https://www.theregister.com/2025/02/14/postgresql_bug_treasury/
13 comments
https://www.postgresql.org/support/security/CVE-2025-1094/
> Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns. Specifically, SQL injection requires the application to use the function result to construct input to psql, the PostgreSQL interactive terminal.
Wait, what kind of system design uses programmatic input to psql, the command-line tool? Are they like shelling out to psql, instead of using a SQL client library?
> Similarly, improper neutralization of quoting syntax in PostgreSQL command line utility programs allows a source of command line arguments to achieve SQL injection when client_encoding is BIG5 and server_encoding is one of EUC_TW or MULE_INTERNA
BIG5 is Chinese encoding, so I'm assuming the actual attack was the other route.
> Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns. Specifically, SQL injection requires the application to use the function result to construct input to psql, the PostgreSQL interactive terminal.
Wait, what kind of system design uses programmatic input to psql, the command-line tool? Are they like shelling out to psql, instead of using a SQL client library?
> Similarly, improper neutralization of quoting syntax in PostgreSQL command line utility programs allows a source of command line arguments to achieve SQL injection when client_encoding is BIG5 and server_encoding is one of EUC_TW or MULE_INTERNA
BIG5 is Chinese encoding, so I'm assuming the actual attack was the other route.
A little more context at https://www.rapid7.com/blog/post/2025/02/13/cve-2025-1094-po... really does imply somebody is programmatically generating a SQL statement and then passing it to psql in a subprocess.
belter(1)
"Because of how PostgreSQL string escaping routines handle invalid UTF-8 characters, in combination with how invalid byte sequences within the invalid UTF-8 characters are processed by psql, an attacker can leverage CVE-2025-1094 to generate a SQL injection."
UTF-8 and its consequences have been a disaster for information security
UTF-8 and its consequences have been a disaster for information security
But also this:
"Running meta-commands can extend psql's functionality, and it's through these that an attacker can feasibly achieve ACE by using the exclamation mark meta-command to execute a shell command on the operating system. Attackers can also use the vulnerability to execute SQL statements of their choosing."
I don't know PostgreSQL very well, but being able to execute shell commands by default seems like an obvious footgun.
"Running meta-commands can extend psql's functionality, and it's through these that an attacker can feasibly achieve ACE by using the exclamation mark meta-command to execute a shell command on the operating system. Attackers can also use the vulnerability to execute SQL statements of their choosing."
I don't know PostgreSQL very well, but being able to execute shell commands by default seems like an obvious footgun.
I use shell commands alright. I don't let internet randos use shell commands on my system tho.
I've been keeping a casual eye on sql injection stuff, and unicode escaping seems to be a source of problems.
I've been keeping a casual eye on sql injection stuff, and unicode escaping seems to be a source of problems.
[deleted]
It's been a while since I've studied journalism but I'm pretty sure this belongs in the first paragraph.