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.
Source Article:
https://www.theregister.com/2025/02/14/postgresql_bug_treasury/?utm_source=tldrinfosec