CVE-2026-17543: 
PHP vulnerability analysis and mitigation

CVE-2026-17543 is a SQL injection vulnerability in PHP's ext-pgsql extension (PGSQL and PDO_PGSQL) caused by improper escaping of backslashes in attacker-provided parameters. The flaw resides in the php_pgsql_convert() function, which uses PQescapeStringConn() wrapped in an E'...' escape string constant — a combination that fails to correctly escape backslashes when PostgreSQL's standard_conforming_strings is enabled (the default since PostgreSQL 9.1). Affected PHP versions are 8.2.x before 8.2.33, 8.3.x before 8.3.33, 8.4.x before 8.4.24, and 8.5.x before 8.5.9. It carries a CVSS v4.0 base score of 8.1 (High) (GitHub Advisory, Feedly).

The root cause (CWE-89) lies in php_pgsql_convert(), which calls PQescapeStringConn() to escape user input and then wraps the result in an E'...' escape string constant via php_pgsql_add_quotes(). With standard_conforming_strings = on, PQescapeStringConn() does not escape backslashes, so an attacker can supply a value like zzz\' OR 1=1 --: the backslash escapes the first single quote (making it a literal '), while the second single quote terminates the string, injecting arbitrary SQL. This affects the pg_insert(), pg_update(), pg_select(), and pg_delete() functions when applications pass untrusted user input directly as parameters. The fix changes php_pgsql_convert() to wrap parameters in non-escaping string constants instead of E'...' (GitHub Advisory).

An unauthenticated remote attacker can execute arbitrary SQL queries against the backend PostgreSQL database, enabling unauthorized reading, modification, or deletion of database contents. Because no authentication or special privileges are required and the attack is automatable over the network, the confidentiality, integrity, and availability of the database are all at high risk. In worst-case scenarios — particularly where the PostgreSQL role has elevated privileges — exploitation could extend to operating system command execution via PostgreSQL's COPY TO/FROM PROGRAM or similar mechanisms (GitHub Advisory, Feedly).

1. Reconnaissance: Identify web applications running PHP with PostgreSQL backends using ext-pgsql functions (pg_insert, pg_update, pg_select, pg_delete) on affected PHP versions (8.2.x < 8.2.33, 8.3.x < 8.3.33, 8.4.x < 8.4.24, 8.5.x < 8.5.9). Tools like Shodan, Censys, or manual fingerprinting can help identify PHP version banners.
2. Identify injectable parameters: Locate application endpoints that accept user-supplied input passed directly to pg_select(), pg_insert(), pg_update(), or pg_delete() as associative array values.
3. Craft the payload: Construct a parameter value that exploits the backslash escape flaw. For example, supply zzz\' OR 1=1 -- as a field value. The backslash causes the first ' to be treated as a literal character, and the second ' terminates the string, injecting OR 1=1 -- into the query.
4. Submit the request: Send the crafted input via the vulnerable endpoint (e.g., HTTP POST or GET parameter). The resulting query becomes: SELECT * FROM "user" WHERE "name"=E'zzz\'' OR 1=1 --', which returns all rows.
5. Escalate: Use more advanced SQL injection payloads (e.g., UNION SELECT, COPY TO/FROM PROGRAM) to exfiltrate data, modify records, or — if the PostgreSQL role permits — execute OS-level commands (GitHub Advisory).

• Network: Unusual or malformed HTTP requests containing backslash-quote sequences (\') or SQL keywords (OR 1=1, UNION SELECT, --) in parameter values sent to PHP application endpoints.
• Logs: PostgreSQL query logs (pg_log) showing unexpected SQL syntax such as OR 1=1, UNION, or -- comments originating from application queries; PHP application error logs showing unexpected query results or PostgreSQL errors.
• Application Behavior: Unexpected data returned from database queries (e.g., all rows returned when only one is expected); anomalous database read/write activity from the application's PostgreSQL role.
• Database: Unusual queries in pg_stat_activity or audit logs involving COPY, pg_read_file(), or other privileged functions executed under the application's database role.

Upgrade PHP to the patched versions: 8.2.33, 8.3.33, 8.4.24, or 8.5.9, which fix php_pgsql_convert() to use non-escaping string constants instead of E'...' (GitHub Advisory). As an immediate workaround, replace direct use of pg_insert(), pg_update(), pg_select(), and pg_delete() with parameterized queries or prepared statements (pg_query_params(), PDO with placeholders), which are not affected by this flaw. Additionally, apply the principle of least privilege to database accounts used by PHP applications to limit the blast radius of any successful injection (Feedly).

The vulnerability was publicly disclosed on July 30, 2026, and quickly picked up by security news outlets. CyberSecurityNews and CyberPress both covered the release of PHP patches addressing this and two other flaws (CyberSecurityNews, CyberPress). The Linux ecosystem responded rapidly, with Fedora, RHEL, Slackware, and Debian packaging updates noted within hours of disclosure (LinuxCompatible). Remi Collet's PHP repository blog also noted the new releases (Remi's Blog). The oss-security mailing list received a disclosure post, and the DailyCyberSecurity Mastodon account flagged the issue for the infosec community (oss-security).