PostgreSQL patches SQLi vulnerability likely exploited in BeyondTrust attacks – Source: www.csoonline.com

Attackers who exploited a zero-day vulnerability in BeyondTrust Privileged Remote Access and Remote Support products in December likely also exploited a previously unknown SQL injection flaw in PostgreSQL, a widely used open-source object-relational database system. The PostgreSQL issue was fixed on Thursday and users are advised to upgrade their database servers as soon as possible.

At the end of December, the US Department of the Treasury disclosed that state-sponsored Chinese attackers accessed some of its workstations and obtained unclassified information. The Treasury said the access occurred through a cloud-based remote support service operated by BeyondTrust.

BeyondTrust launched an investigation and confirmed that an API key was compromised and was used to access customer accounts. But the company also identified two zero-day command injection issues in its products — CVE-2024-12356 and CVE-2024-12686 – which the US Cybersecurity and Infrastructure Security Agency (CISA) later added to its Known Exploited Vulnerabilities (KVE) catalog.

Researchers from security company Rapid7 analyzed the patches for the CVE-2024-12356 vulnerability in order to understand the flaw and in the process discovered the SQL injection issue in PostgreSQL’s interactive tool psql, which the BeyondTrust Remote Support product uses and which is capable of executing system commands. The PostgreSQL SQL injection flaw is now tracked as CVE-2025-1094.

“In every scenario Rapid7 researchers tested during analysis of CVE-2024-12356, a successful exploit for CVE-2024-12356 had to include exploitation of CVE-2025-1094 in order to achieve remote code execution,” the researchers wrote in their report. “In other words, based on our analysis, we believe the exploit for BeyondTrust RS CVE-2024-12356 would have relied on exploitation of PostgreSQL CVE-2025-1094.”

The PostgreSQL Global Development Group, which maintains the PostgreSQL software, advised users to upgrade to the patched version for their respective branch: 17.3, 16.7, 15.11, 14.16 and 13.19.

Input sanitization bypassed

When the Rapid7 researchers looked at the patches, they noticed some sanitization being added to a value called $gskey which was being passed to a script called $ingrediRoot/app/dbquote via the echo command.

“The change in how the $gskey value is passed to the echo command is a classic argument injection issue,” the researchers wrote. “In a shell script, when passing an unquoted variable to a command, the shell will pass the contents of the value to the command as individual arguments to the command, as parsed by the shell. If the value is wrapped in double quotes, the shell will pass the entire value as a single argument to the command.”

But the BeyondTrust advisory said that exploiting this vulnerability “can allow an unauthenticated remote attacker to execute underlying operating system commands within the context of the site user.” And the argument injection on its own is not achieving that, so the researchers had to keep digging.

They then looked at dbquote and saw it was a PHP script that took the echoed $gskey value, passed it through the PostgreSQL PHP helper function pg_escape_string, then wrapped the output in single quotes and printed it back as a variable called quoted.

The purpose of the pg_escape_string function is to “escape” any special characters, such as single quotes, from untrusted input before using it in an SQL command. That’s because unwanted strings can lead to SQL injection – injecting unintended commands controlled by the attacker.

The researchers were a bit confused at this point. The use of pg_escape_string should have mitigated any risk of SQL injection. So why was $gskey being sanitized in the first place?

This question sent them down a much deeper rabbit hole that ended with the finding that PostgreSQL’s interactive terminal psql appears to incorrectly handle input that contains invalid UTF-8 characters. When presented with a string that has a certain combination of invalid UTF-8 bytes, it causes the SQL statement to terminate early and opens the possibility to execute an additional statement from the string that follows the invalid UTF-8 character and a semicolon.

“We have managed to achieve a SQL injection via a correctly escaped untrusted input, due to the psql tool’s incorrect handling of invalid UTF-8 characters,” the researchers wrote. “This vulnerability is now known as CVE-2025-1094.”

Furthermore, psql has a feature called meta-commands that allows the execution of shell commands via the ! meta-command. This capability transforms the SQL injection into OS command code execution.

The researchers even found a way to directly exploit CVE-2025-1094 in the BeyondTrust product without having to rely on the CVE-2024-12356 argument injection vulnerability. However, the additional checks put in place for $gskey as part of the patch for CVE-2024-12356, mitigating this more direct attack path as well.

More specifically, the patch now checks the $gskey value using a regular expression pattern of a-zA-Z0-9 – lowercase letters from a to z, uppercase letters from A to Z and digits from 0 to 9. Meanwhile, a successful exploit requires adding a raw byte like 0xC0 into the value in order to trigger psql’s incorrect handling of invalid characters, and this fails the newly added check.