"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
"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.
> 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.
13 comments
[ 2.9 ms ] story [ 41.6 ms ] threadIt's been a while since I've studied journalism but I'm pretty sure this belongs in the first paragraph.
UTF-8 and its consequences have been a disaster for information security
"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've been keeping a casual eye on sql injection stuff, and unicode escaping seems to be a source of problems.
> 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.
The claim that this vulnerability was required seems quite dubious.