Critical PostgreSQL bug tied to zero-day attack on US Treasury – Source: go.theregister.com

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 included the BeyondTrust zero-day (CVE-2024-12356).

In fact, CVE-2025-1094 was so important to the chain that the BeyondTrust attack couldn’t have been pulled off without it, we’re told.

“Rapid7 discovered that in every scenario we tested, a successful exploit for CVE-2024-12356 had to include exploitation of CVE-2025-1094 in order to achieve remote code execution,” said Fewer.

“While CVE-2024-12356 was patched by BeyondTrust in December 2024, and this patch successfully blocks exploitation of both CVE-2024-12356 and CVE-2025-1094, the patch did not address the root cause of CVE-2025-1094, which remained a zero-day until Rapid7 discovered and reported it to PostgreSQL.”

According to Rapid7’s director of vulnerability intelligence, Caitlin Condon, CVE-2025-1094 affects all versions of the PostgreSQL interactive tool, but, fortunately, it isn’t particularly simple to exploit. Given the complexity of the exploit pattern, Rapid7 doesn’t expect attacks to be carried out away from the BeyondTrust versions already known to be vulnerable.

She said via Mastodon: “But with the above said, it’s clear that the adversaries who perpetrated the December attack really knew the target technology, which is yet another example of a zero-day exploit trend Rapid7 started tracking in 2023.”

The vulnerability in the PostgreSQL interactive tool (psql) can lead to arbitrary code execution (ACE) and there is also a technique to exploit it independently from CVE-2024-12356. Rapid7 said BeyondTrust’s patch for its zero-day didn’t address the root cause of the psql bug, but it does prevent the two from being exploited together.

The psql vulnerability can be exploited because of an incorrect assumption that a SQL injection attack can’t be carried out when a malicious input is safely escaped via PostgreSQL’s string escaping routines, Fewer said.

However, the researcher discovered that a malicious input can still be executed by the psql tool under specific conditions as part of a SQL statement.

• Mysterious Palo Alto firewall reboots? You’re not alone
• Have I Been Pwned likely to ban resellers from buying subs, citing ‘sh*tty behavior’ and onerous support requests
• Feds want devs to stop coding ‘unforgivable’ buffer overflow vulnerabilities
• February’s Patch Tuesday sees Microsoft offer just 63 fixes

Fewer said: “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.”

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.

The full technical rundown of both vulnerabilities can be found on AttackerKB, which details all the important indicators of compromise and remediation steps. However, to summarize, users should apply the latest versions, released on February 13, to keep themselves safe.

Condon praised the PostgreSQL team for their cooperation and communication during the disclosure process.

She said: “One teeny tiny last semi-personal note – this is one of the most straightforward disclosure timelines we’ve been able to put in a [coordinated vulnerability disclosure] blog in a while, which is extra nice (and unfortunately not the norm in recent years) and also makes me extra grateful to the PostgreSQL dev group.” ®