SQLi

Sequence Break: Unraveling CVE-2025-46337 - SQL Injection in ADOdb's PostgreSQL Driver

Robert Morgan

Robert Morgan

— 7 min read

Alright folks, grab your coffee (or your preferred caffeinated beverage), because we're diving into another CVE. This time, we're looking at CVE-2025-46337, a sneaky SQL injection vulnerability lurking within the popular ADOdb PHP database abstraction library, specifically affecting its PostgreSQL drivers. If you're using ADOdb with PostgreSQL, this one deserves your immediate attention. Let's break it down.

TL;DR / Executive Summary

What's the issue? CVE-2025-46337 is a SQL injection vulnerability in the ADOdb PHP library.
How bad is it? Severity is context-dependent but can be High/Critical in worst-case scenarios, potentially allowing arbitrary SQL execution. (CVSS score not officially assigned yet, but treat it seriously).
Who's affected? Applications using ADOdb versions <= 5.22.8 with PostgreSQL drivers (postgres64, postgres7, postgres8, postgres9).
The Culprit: The pg_insert_id() method fails to properly escape the $fieldname parameter when constructing a query to retrieve the last inserted ID using PostgreSQL sequences.
The Fix: Update to ADOdb version 5.22.9 or later. As a workaround, ensure any data passed to the $fieldname parameter is either strictly controlled or manually escaped using pg_escape_identifier().

Introduction: The Double-Edged Sword of Abstraction

Database Abstraction Layers (DBALs) like ADOdb are fantastic tools. They promise a consistent API across different database systems, saving developers countless hours and headaches. Write your code once, run it (mostly) anywhere – sounds great, right? But abstraction can sometimes hide complexity, and hidden complexity is where vulnerabilities often like to play hide-and-seek.

Enter CVE-2025-46337. This vulnerability reminds us that even helper functions designed for convenience, like fetching the ID of the last inserted row, can become attack vectors if not implemented carefully. For anyone running a PHP application using ADOdb to talk to a PostgreSQL backend, this isn't just theoretical; it's a potential open door for attackers. Let's peek behind the curtain.

Technical Deep Dive: When Identifiers Go Rogue

So, what exactly is going wrong here? The vulnerability lies within the pg_insert_id() function in the ADOdb PostgreSQL drivers. Its job is simple: after you insert a row into a table that uses an auto-incrementing primary key (often managed by a PostgreSQL SEQUENCE), this function helps you retrieve the newly generated ID.

In PostgreSQL, sequences often follow a naming convention like tablename_fieldname_seq. The vulnerable ADOdb code attempts to query the current value of this sequence after an insert. Here’s the problematic line (simplified from drivers/adodb-postgres64.inc.php prior to the fix):

// drivers/adodb-postgres64.inc.php (Vulnerable Version <= 5.22.8)

function pg_insert_id($tablename, $fieldname)
{
    // Uh oh... $tablename and $fieldname are concatenated directly into the SQL string!
    $result = pg_query($this->_connectionID, 'SELECT last_value FROM '. $tablename .'_'. $fieldname .'_seq');
    // ... (rest of the function)
}

Root Cause Analysis: The core issue is improper neutralization of special elements used in an SQL command (SQL Injection), specifically targeting database object identifiers rather than data values. The code directly concatenates the $tablename and $fieldname variables into the SQL query string without proper escaping.

Think of it like SQL Mad Libs, but instead of filling in nouns and verbs, the attacker gets to fill in parts of the database object name. If an attacker can control the value passed as $fieldname (and potentially $tablename), they can break out of the intended sequence name structure and inject arbitrary SQL commands.

Attack Vectors: How could an attacker control $fieldname?

  1. Direct User Input: A web form or API endpoint might take a field name as a parameter and pass it down to pg_insert_id(). This is the most direct route.
  2. Configuration Injection: If table or field names are derived from configuration files or database schemas that an attacker might influence.
  3. Second-Order Injection: The vulnerable function might use a field name retrieved from the database itself, which was previously tainted by an attacker.

Business Impact: A successful exploit could lead to:

  • Data Exfiltration: Reading sensitive data from any table the database user has access to.
  • Data Manipulation: Modifying or deleting data.
  • Denial of Service (DoS): Executing commands like pg_sleep() to tie up database connections or dropping tables (if permissions allow).
  • Potential Remote Code Execution (RCE): In some PostgreSQL configurations and versions, database-level code execution might be possible.

This isn't just about fetching the wrong sequence value; it's about potentially compromising the entire database.

Proof of Concept (PoC): Seeing is Believing

Let's illustrate with a simplified, hypothetical scenario. Imagine a PHP script that allows specifying a field name via a GET parameter (never do this in production without strict validation!):

<?php
// WARNING: Simplified theoretical example. Do not use in production.
require('adodb/adodb.inc.php');

// Assume ADOdb connection $db is established to PostgreSQL
// $db = ADONewConnection('postgres');
// $db->Connect(...);

$tableName = 'users'; // Let's assume table name is fixed for simplicity
$fieldNameFromUser = $_GET['field']; // Attacker controls this!

// Simulate an insert (details omitted)
// $db->Execute("INSERT INTO users (username) VALUES ('testuser')");

// Now, the vulnerable call:
echo "Attempting to get last insert ID...\n";
try {
    // Pass the user-controlled field name directly
    $lastId = $db->pg_insert_id($tableName, $fieldNameFromUser);
    echo "Last Insert ID: " . $lastId . "\n";
} catch (Exception $e) {
    echo "Error: " . $e->getMessage() . "\n";
}

?>

An attacker could craft a malicious request:

http://example.com/get_last_id.php?field=id'); SELECT pg_sleep(10); --

Let's trace the execution within the vulnerable pg_insert_id function:

  1. $tablename = 'users'
  2. $fieldname = 'id'); SELECT pg_sleep(10); --'
  3. The SQL query becomes:
    SELECT last_value FROM users_id'); SELECT pg_sleep(10); --_seq

PostgreSQL sees two commands here:

  1. SELECT last_value FROM users_id (This will likely fail or return garbage, depending on quoting rules and object existence).
  2. SELECT pg_sleep(10) (This command executes successfully, causing the database connection to hang for 10 seconds).
  3. --_seq (The rest is treated as a comment).

The pg_sleep(10) demonstrates successful injection. An attacker could replace this with far more malicious queries to steal or modify data.

Mitigation and Remediation: Patch Up!

Okay, enough scary stuff. How do we fix this?

  1. Immediate Fix: Patch ADOdb: The absolute best solution is to update ADOdb to version 5.22.9 or later. The patch directly addresses the vulnerability.

    composer update adodb/adodb-php

    Or download the latest release from the ADOdb website/GitHub.

  2. Workaround (If patching is delayed): Sanitize Input: If you absolutely cannot update immediately, you must ensure that any value passed as the $fieldname (or $tablename) to pg_insert_id() is safe.

    • Best: Use a strict allow-list of known-good field names.
    • Alternatively: Manually escape the identifier using PostgreSQL's specific function before calling pg_insert_id():
      // Assuming $db is your ADOdb connection object
$safe_fieldname = pg_escape_identifier($db->_connectionID, $potentially_unsafe_fieldname);
$lastId = $db->pg_insert_id($tableName, $safe_fieldname);
      Note: Accessing _connectionID directly is using an internal property, which isn't ideal but necessary for the workaround.

  3. Long-Term Solutions:

    • Input Validation: Always treat external input (from users, APIs, files) as untrusted. Validate and sanitize rigorously.
    • Principle of Least Privilege: Ensure your application's database user has only the minimum permissions necessary. It shouldn't be able to drop tables if it only needs to SELECT/INSERT/UPDATE.
    • Web Application Firewall (WAF): A WAF might catch some generic SQLi attempts, but tailored attacks against specific logic flaws like this can sometimes bypass them. Don't rely solely on a WAF.
    • Security Audits & Code Reviews: Regularly review code, especially parts handling database interactions and external input.

  4. Verification:

    • Check your composer.lock file or ADOdb library version to confirm you are running 5.22.9 or later.
    • Use static analysis tools (SAST) to scan your codebase for potentially unsafe uses of pg_insert_id().

Patch Analysis: How the Fix Works

The fix applied in commit 11107d6d6e5160b62e05dff8a3a2678cf0e3a426 is beautifully simple and correct. Let's look at the change in drivers/adodb-postgres64.inc.php:

--- a/drivers/adodb-postgres64.inc.php
+++ b/drivers/adodb-postgres64.inc.php
@@ -138,7 +138,8 @@ function IfNull( $field, $ifNull )
  	// get the last id - never tested
  	function pg_insert_id($tablename,$fieldname)
  	{
-		$result=pg_query($this->_connectionID, 'SELECT last_value FROM '. $tablename .'_'. $fieldname .'_seq');
+		// Construct the full sequence name first
+		$sequence = pg_escape_identifier($this->_connectionID, $tablename .'_'. $fieldname .'_seq');
+		// Use the properly escaped sequence name in the query
+		$result = pg_query($this->_connectionID, 'SELECT last_value FROM '. $sequence);
  		if ($result) {
  			$arr = @pg_fetch_row($result,0);
  			pg_free_result($result);

What does pg_escape_identifier() do? This PHP function is specifically designed to make strings safe for use as SQL identifiers (like table names, column names, or sequence names) in PostgreSQL. It quotes the identifier (usually with double quotes) and handles any embedded special characters (like quotes or backslashes) appropriately.

Why does it work? By escaping the entire constructed sequence name ($tablename .'_'. $fieldname .'_seq'), the database now sees it as a single, atomic identifier. Even if $fieldname contains malicious characters like '); SELECT ..., they are treated as part of the literal name being looked up, not as separate SQL commands. For our malicious example id'); SELECT pg_sleep(10); --, the escaped identifier might look like "users_id'); SELECT pg_sleep(10); --_seq". PostgreSQL will search for a sequence with that exact, bizarre name (which won't exist) instead of executing the embedded SELECT pg_sleep(10) command. Problem solved.

Timeline

  • Discovery: Credit to Marco Nappi (@mrcnpp). The exact discovery date isn't public, but likely occurred sometime before the fix was developed.
  • Vendor Notification: Assumed to have happened responsibly prior to the fix commit.
  • Patch Development: The fix commit 11107d6d6e5160b62e05dff8a3a2678cf0e3a426 was likely created in April 2025.
  • Patch Availability: ADOdb version 5.22.9 containing the fix was released.
  • Public Disclosure: The vulnerability advisory (GHSA-8x27-jwjr-8545) was published around May 1st, 2025.

(Note: Some dates are inferred based on commit and advisory publication times.)

Lessons Learned: Trust, But Verify (Especially Identifiers)

This CVE serves as a potent reminder of several key security principles:

  1. SQL Injection Isn't Just About Data: We often focus on injecting malicious values into WHERE clauses or INSERT statements. However, injecting into identifiers (table names, column names, sequence names) is equally dangerous and requires different escaping mechanisms (pg_escape_identifier vs. pg_escape_string or parameterized queries).
  2. Abstraction Layers Aren't Magic Shields: While DBALs simplify development, they are still code written by humans and can contain vulnerabilities. Understand how your abstraction layer works under the hood, especially for security-sensitive operations.
  3. Defense in Depth: Relying solely on escaping within a library function isn't enough. Robust input validation, least privilege database users, and regular security reviews form essential layers of defense.

Key Takeaway: Never trust input, especially when it's used to construct code or commands – and that includes database object names! Always use the appropriate escaping mechanism for the context.

References and Further Reading

Stay safe out there, keep your libraries updated, and treat all input like it's trying to break things (because sometimes, it is!). What other "helper" functions do you think might harbor hidden dangers?

Read more