CVE-2025-46337: ADOdb PHP Library SQLi Vulnerability

CVE-2025-46337 Overview

CVE-2025-46337 is a SQL Injection vulnerability affecting ADOdb, a popular PHP database class library that provides abstractions for performing queries and managing databases. Prior to version 5.22.9, improper escaping of a query parameter in the pg_insert_id() function may allow an attacker to execute arbitrary SQL statements when the code using ADOdb connects to a PostgreSQL database and is called with user-supplied data.

Critical Impact

This vulnerability allows unauthenticated remote attackers to execute arbitrary SQL commands against PostgreSQL databases, potentially leading to complete database compromise including data theft, modification, or destruction.

Affected Products

• ADOdb versions prior to 5.22.9
• Applications using ADOdb with PostgreSQL database connections
• Systems calling pg_insert_id() with user-controlled input

Discovery Timeline

• 2025-05-01 - CVE-2025-46337 published to NVD
• 2025-05-26 - Last updated in NVD database

Technical Details for CVE-2025-46337

Vulnerability Analysis

This SQL Injection vulnerability (CWE-89) exists in the PostgreSQL driver component of ADOdb, specifically within the pg_insert_id() function located in drivers/adodb-postgres64.inc.php. The vulnerability stems from the direct concatenation of user-supplied table and field names into a SQL query without proper sanitization or escaping.

When an application passes user-controlled data to pg_insert_id(), an attacker can craft malicious input that breaks out of the intended query structure and injects arbitrary SQL commands. This is particularly dangerous because the function constructs a sequence name by concatenating the $tablename and $fieldname parameters directly into the query string.

The vulnerability is remotely exploitable over the network without requiring authentication or user interaction. The scope extends beyond the vulnerable component, meaning a successful attack could affect resources beyond the ADOdb library itself, potentially impacting the entire database server and any applications relying on it.

Root Cause

The root cause is the absence of proper input validation and escaping when constructing the SQL query within pg_insert_id(). The vulnerable code directly concatenates the $tablename and $fieldname parameters into a SQL query string without using PostgreSQL's pg_escape_identifier() function to safely escape the identifier names. This allows specially crafted input containing SQL metacharacters to alter the intended query logic.

Attack Vector

The attack vector is network-based, targeting web applications or services that use ADOdb to connect to PostgreSQL databases. An attacker can exploit this vulnerability by:

1. Identifying an application endpoint that calls pg_insert_id() with user-controllable parameters
2. Crafting malicious input containing SQL injection payloads in the table name or field name parameters
3. Submitting the payload through the application's interface
4. Executing arbitrary SQL commands against the PostgreSQL database

The following code shows the security patch that addresses this vulnerability:

 	// get the last id - never tested
 	function pg_insert_id($tablename,$fieldname)
 	{
-		$result=pg_query($this->_connectionID, 'SELECT last_value FROM '. $tablename .'_'. $fieldname .'_seq');
+		$sequence = pg_escape_identifier($this->_connectionID, $tablename .'_'. $fieldname .'_seq');
+		$result = pg_query($this->_connectionID, 'SELECT last_value FROM '. $sequence);
 		if ($result) {
 			$arr = @pg_fetch_row($result,0);
 			pg_free_result($result);

Source: GitHub Commit Update

Detection Methods for CVE-2025-46337

Indicators of Compromise

• Unusual or malformed SQL queries in PostgreSQL logs containing sequence name references with injection patterns
• Application errors related to pg_insert_id() function calls with unexpected syntax
• Database access logs showing queries with SQL metacharacters in table or field name positions
• Evidence of data exfiltration or unauthorized database modifications

Detection Strategies

• Review application code for calls to pg_insert_id() that accept user-supplied input for table or field names
• Implement Web Application Firewall (WAF) rules to detect SQL injection patterns in request parameters
• Enable PostgreSQL query logging and analyze for anomalous query structures targeting sequence tables
• Conduct static application security testing (SAST) scans focusing on ADOdb library usage patterns

Monitoring Recommendations

• Enable verbose PostgreSQL logging to capture all queries including those targeting sequence objects
• Configure intrusion detection systems to alert on SQL injection attack signatures
• Monitor application logs for exceptions or errors from the ADOdb PostgreSQL driver
• Set up database activity monitoring to detect unauthorized data access or modification patterns

How to Mitigate CVE-2025-46337

Immediate Actions Required

• Upgrade ADOdb to version 5.22.9 or later immediately
• Audit all code paths that call pg_insert_id() to ensure user input is not passed directly to this function
• Implement input validation to restrict table and field names to expected alphanumeric patterns
• Review and test all applications using ADOdb with PostgreSQL connections for SQL injection vulnerabilities

Patch Information

The vulnerability has been patched in ADOdb version 5.22.9. The fix introduces proper escaping of the sequence name using PostgreSQL's pg_escape_identifier() function before incorporating it into the SQL query. Organizations should upgrade to this version or apply the patch from commit 11107d6d6e5160b62e05dff8a3a2678cf0e3a426.

For additional information, refer to the GitHub Security Advisory GHSA-8x27-jwjr-8545 and the Debian LTS Security Announcement.

Workarounds

• Avoid passing user-controlled data to the pg_insert_id() function until the patch is applied
• Implement strict allow-list validation for any table or field names that must be user-supplied
• Use parameterized queries and prepared statements throughout the application as a defense-in-depth measure
• Consider using database user accounts with minimal required privileges to limit potential damage from exploitation

# Update ADOdb via Composer
composer require adodb/adodb-php:^5.22.9

# Verify installed version
composer show adodb/adodb-php | grep version