Improper escaping of backslashes in attacker-provided parameters would

CVE-2026-17543 is a SQL injection in PHP's ext-pgsql extension, specifically in php_pgsql_convert(), the internal function behind pg_insert(), pg_update(), pg_select(), and pg_delete(). When PostgreSQL runs with standard_conforming_strings = on (the default since PostgreSQL 9.1), PQescapeStringConn() does not escape backslashes. But php_pgsql_convert() wraps results in escape-string constants (E'...'), where backslashes *are* significant. An attacker sends zzz\' OR 1=1 -- as a parameter value; the function doubles the quote to '' but leaves the backslash, so the \' becomes a literal quote character followed by a string-terminating quote — classic second-order escaping mismatch. Affected versions span PHP 8.2 before 8.2.33, 8.3 before 8.3.33, 8.4 before 8.4.24, and 8.5 before 8.5.9.

There is no vendor CVSS score to compare against. GitHub's GHSA advisory rates this High, which aligns with the technical reality: when conditions are met (app uses the specific pg_* convenience functions with user input), exploitation is trivial and unauthenticated, with a complete PoC in the advisory itself. However, these convenience functions are niche — the vast majority of PHP+PostgreSQL applications use PDO, pg_query_params(), or ORM query builders. The affected population is a narrow slice of a narrow slice (PHP + PostgreSQL + legacy convenience functions + user-controlled input), which significantly limits real-world exposure even though the bug itself is textbook-critical.

Why this verdict

• Trivial, unauthenticated SQLi with public PoC — the advisory itself contains a working one-liner. No authentication, no user interaction, no race condition. When the code pattern exists, exploitation is copy-paste.
• Narrow reachable population — the vulnerability only fires in applications using pg_select(), pg_insert(), pg_update(), or pg_delete() with user-controlled input. Most PHP+PostgreSQL applications use PDO, pg_query_params(), or ORM query builders. This is a niche API within a minority database choice (PostgreSQL is ~10-15% of PHP database usage).
• No authentication or privilege required — the attacker only needs HTTP access to a vulnerable endpoint. This is a pure remote, unauthenticated attack vector.
• Role multiplier: PHP+PostgreSQL applications occupy a spectrum from low-value dev tools to production SaaS platforms handling PII/financial data. When the vulnerable code pattern exists in a production app backed by a database with sensitive data, the blast radius is full database compromise (confidentiality + integrity). However, PHP's ext-pgsql convenience functions are *not* canonically high-value-role components (they are not hypervisors, DCs, identity providers, etc.). The worst-case role is a production web application with regulated data — serious but contained to that application's database, not fleet-scale. This sets a HIGH floor, not CRITICAL.
• PHP is ubiquitous but the intersection is small — PHP runs on millions of servers, but the chain of PHP → PostgreSQL → ext-pgsql (not PDO) → convenience functions → user input is a compounding narrowing filter. Each layer reduces the exposed population significantly.

Why not higher?

CRITICAL would require either active exploitation, a canonically high-value-role component (DC, hypervisor, IdP, kernel-mode agent), or a much broader reachable population. The vulnerability is in niche convenience functions that modern PHP frameworks do not use. The blast radius is limited to the individual application's database — not fleet-scale, domain-scale, or supply-chain-scale. The attack complexity is technically low but requires a specific uncommon code pattern to exist in the target.

Why not lower?

MEDIUM would undercount the risk because: (1) the SQLi is trivially exploitable with zero authentication and a public PoC published in the advisory itself, (2) PHP is the most widely deployed server-side language, so even a small percentage of vulnerable apps represents thousands of targets globally, and (3) successful exploitation yields full database read/write — not a partial information disclosure or DoS. The 48-hour-old disclosure with a public PoC creates an immediate exploitation window before patches propagate to distros and containers.

1. Audit codebase for pg_select, pg_insert, pg_update, pg_delete usage — Run grep -rn 'pg_select\|pg_insert\|pg_update\|pg_delete' /path/to/app across all PHP codebases. If none are found, this CVE does not affect you. If found, prioritize those applications for patching within the noisgate HIGH mitigation SLA of 30 days.
2. Deploy WAF rules blocking backslash-quote sequences — Add ModSecurity or cloud WAF rules to detect \' patterns in request parameters targeting affected endpoints. OWASP CRS rules 942100-942999 cover most SQLi patterns. Deploy within 30 days per noisgate mitigation SLA.
3. Replace pg_* convenience functions with pg_query_params — Refactor affected code to use pg_query_params() with parameterized queries. This eliminates the vulnerability entirely regardless of PHP version. Example: replace pg_select($db, 'user', ['name' => $input]) with pg_query_params($db, 'SELECT * FROM "user" WHERE name = $1', [$input]).
4. Restrict database user privileges — Ensure the PostgreSQL user used by PHP applications has minimum required permissions — no superuser, no CREATEROLE, limited to specific schemas. This limits blast radius if SQLi succeeds.
5. Upgrade PHP to patched versions — Apply PHP 8.2.33, 8.3.33, 8.4.24, or 8.5.9. These are the definitive fix. Target remediation within 180 days per noisgate HIGH remediation SLA, but faster if your codebase grep confirms affected function usage.

Run on each PHP application server to check if the installed PHP version is vulnerable. Requires read access to the php binary. Execute as any user: bash check_cve_2026_17543.sh

#!/bin/bash
# CVE-2026-17543 checker — PHP ext-pgsql SQL injection
# Run on PHP application servers. No special privileges needed.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

PHP_BIN=$(command -v php 2>/dev/null)
if [ -z "$PHP_BIN" ]; then
  echo "UNKNOWN — php binary not found in PATH"
  exit 2
fi

# Check if pgsql extension is loaded
HAS_PGSQL=$($PHP_BIN -m 2>/dev/null | grep -ci '^pgsql$')
if [ "$HAS_PGSQL" -eq 0 ]; then
  echo "PATCHED — ext-pgsql not loaded; CVE-2026-17543 does not apply"
  exit 0
fi

VERSION=$($PHP_BIN -r 'echo PHP_VERSION;' 2>/dev/null)
if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not determine PHP version"
  exit 2
fi

# Parse major.minor.patch
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3 | sed 's/[^0-9].*//')

VULN=0
if [ "$MAJOR" -eq 8 ]; then
  if [ "$MINOR" -eq 2 ] && [ "$PATCH" -lt 33 ]; then VULN=1; fi
  if [ "$MINOR" -eq 3 ] && [ "$PATCH" -lt 33 ]; then VULN=1; fi
  if [ "$MINOR" -eq 4 ] && [ "$PATCH" -lt 24 ]; then VULN=1; fi
  if [ "$MINOR" -eq 5 ] && [ "$PATCH" -lt 9 ]; then VULN=1; fi
fi

if [ "$VULN" -eq 1 ]; then
  echo "VULNERABLE — PHP $VERSION with ext-pgsql loaded (CVE-2026-17543)"
  exit 1
else
  echo "PATCHED — PHP $VERSION is not affected or is patched"
  exit 0
fi

Sources

1. GHSA Advisory — SQL injection in ext-pgsql
2. PHP 8.3.33 and 8.4.24 Release Announcement
3. TheHackerWire — CVE-2026-17543
4. PHP CVS Commit — Fix for PHP-8.5
5. PHP CVS Commit — Merge into PHP-8.3
6. PHP CVS Commit — Merge into PHP-8.4