pREST-o Change-o: Turning REST APIs into Remote Shells via CVE-2025-58450

pREST (PostgreSQL REST) is one of those tools developers love. It promises to take your existing PostgreSQL database and, with a wave of a wand, expose it as a fully functional RESTful API. No boilerplate, no ORM headaches, just instant CRUD operations. It’s efficient, fast, and—until recently—dangerously trusting.

The core promise of pREST is that it handles the SQL generation for you. You send a GET request to /users, and it builds SELECT * FROM users. You add ?age=$gt:18, and it adds the WHERE clause. It’s a translation layer. But as any security researcher knows, translation layers are where the bodies are buried.

CVE-2025-58450 isn't just a simple 'oops' in a search bar. It is a systemic failure in how pREST constructed its SQL queries. The application was taking URL parameters intended to define query structure—like which tables to join or which columns to return—and pasting them directly into the SQL string. It’s the architectural equivalent of letting the user write their own police report.

The root cause here is a classic that refuses to die: String Concatenation. In 2025, we should be using parameterized queries (prepared statements) for everything. But pREST sits in a unique position where it has to build dynamic queries based on dynamic URL parameters. While the values might have been parameterized in some places, the identifiers (table names, column names) and keywords (JOIN types) were not.

The vulnerability was identified in four critical areas:

1. _returning: Used to define what data comes back after an INSERT/UPDATE. The code blindly trusted this list.
2. _join: Used to link tables. The join type (INNER, LEFT) and the table identifiers were vulnerable.
3. _groupby: Specifically the HAVING clause, which often handles aggregate filtering.
4. Script Templates: Custom SQL templates that lacked proper parameterization mechanisms.

Because pREST acts as a direct interface to the DB, failing to sanitize these inputs means the attacker isn't just tricking a web app; they are speaking directly to the PostgreSQL engine with the privileges of the API user.

Let's look at the "Smoking Gun" in the code. The patch, found in commit 47d02b87842900f77d76fc694d9aa7e983b0711c, reveals the extent of the negligence.

The Vulnerable Pattern (Conceptual) In the _join handler, the code was essentially doing this:

// Pseudocode representation of the flaw
sqlQuery += " " + joinType + " JOIN " + tableName + " ON " + ...

There was no check to see if joinType was actually a valid SQL keyword like INNER or LEFT. An attacker could theoretically pass LEFT JOIN users ON 1=1; DROP TABLE logs; -- as the join type, and the query builder would happily stitch it together.

The Fix: Regex and Whitelists The developers introduced a strict regex validator and a whitelist for join types. Here is the logic that saved the day:

// The new Sheriff in town: Regex Validation
var identRe = regexp.MustCompile(`^[A-Za-z_][A-Za-z0-9_]*(\.[A-Za-z_][A-Za-z0-9_]*)*$`)
 
// Whitelisting Join Types
validJoinTypes := map[string]bool{
    "INNER": true, "LEFT": true, "RIGHT": true,
    "FULL": true, "CROSS": true,
}
 
if !validJoinTypes[strings.ToUpper(joinType)] {
    return fmt.Errorf("invalid join type")
}
 
// Quoting Identifiers
formattedTable = fmt.Sprintf("\"%s\"", tableName)

They now force every table and column name to match a strict alphanumeric pattern AND wrap them in double quotes. This prevents the injector from breaking out of the identifier context.

So, how do we weaponize this? We don't need a fancy exploit script; curl is enough. The goal is to manipulate the query structure to leak data we shouldn't see.

Scenario 1: The _returning Leak When you perform an operation that supports RETURNING (like an INSERT or sometimes a forced SELECT context), you can ask the DB to return specific columns. If this input is unsanitized, we can inject functions.

# Conceptual Exploit
GET /public/users?_returning=password,pg_read_file('/etc/passwd')

If the application blindly appends the query to RETURNING password, pg_read_file('/etc/passwd'), the API response might include the file contents alongside the user data.

Scenario 2: The _join Smash The _join parameter takes a complex syntax like table:field. If we manipulate the join type or the table identifier, we can alter the logic.

# Injecting into the Join Type (Pre-fix)
GET /public/products?_join=UNION SELECT usename, passwd FROM pg_shadow --:products.id:id

Because the code didn't validate that the join type was actually a "JOIN", we replace INNER with a UNION SELECT, effectively appending a second result set containing the database shadow file (hashes).

A CVSS score of 9.3 is reserved for vulnerabilities that effectively mean "Game Over." This isn't an obscure race condition; it is a reliable, unauthenticated remote code execution (via SQL) vector.

1. Full Data Exfiltration: Attackers can dump the entire database. Since pREST is designed to expose data, it does half the work for them.

2. Lateral Movement: If the PostgreSQL instance has extensions enabled (like plpython or dblink), an attacker could escalate from SQL injection to Operating System Command Execution.

3. DoS: Trivial. ?_returning=pg_sleep(1000) on a public endpoint will exhaust the connection pool instantly.

[!NOTE] The severity is compounded by the fact that pREST is often deployed as a middleware layer, meaning it might be the only thing standing between the public internet and your core database.

The remediation is straightforward but urgent. You must update pREST to version 2.0.0-rc3 or later immediately. The patch does not just "fix" the specific injection points; it changes the philosophy of how identifiers are handled by enforcing quoting and regex validation.

Mitigation Strategies if You Can't Patch:

• WAF Rules: Block any request containing SQL keywords (UNION, SELECT, RETURNING, pg_) in the query string. This is brittle but better than nothing.
• Least Privilege: Ensure the database user that pREST connects with has restricted permissions. It should not be a superuser. It should not have access to pg_shadow or file read functions.
• Disable Features: If you don't use the _join or _returning features, consider using a reverse proxy (like Nginx) to strip those parameters from incoming requests before they reach pREST.