Security · PHP PostgreSQL-Erweiterung (ext-pgsql)
SQL-Injection in vier PHP-Helfern für PostgreSQL
kritisch
Vier Komfortfunktionen von PHPs PostgreSQL-Erweiterung konnten fremde Werte falsch in eine SQL-Anweisung einsetzen. Angreifbar sind nur Anwendungen, die solche Werte an diese Funktionen übergeben. Betreiber sollten PHP aktualisieren und auf Abfragen umstellen, bei denen SQL-Code und Werte getrennt übertragen werden.
- CVE
- CVE-2026-17543
- Betroffen
- Upstream: PHP 8.2 vor 8.2.33, 8.3 vor 8.3.33, 8.4 vor 8.4.24 und 8.5 vor 8.5.9; Distributionen pflegen zusätzlich ältere Zweige. Betroffen ist ext-pgsql bei Verwendung von pg_insert(), pg_update(), pg_select() oder pg_delete() mit nicht vertrauenswürdigen Werten und standard_conforming_strings=on.
- Behoben
- Upstream: 8.2.33, 8.3.33, 8.4.24 und 8.5.9; Ubuntu: 22.04 ab 8.1.2-1ubuntu2.26, 24.04 ab 8.3.6-0ubuntu0.24.04.11, 26.04 ab 8.5.4-0ubuntu1.3; Debian: Bullseye ab 7.4.33-1+deb11u12, Bookworm ab 8.2.33-1~deb12u1, Trixie ab 8.4.24-1~deb13u1
ext-pgsql ist die PHP-Erweiterung für den Zugriff auf PostgreSQL-Datenbanken. Ihre Komfortfunktionen pg_insert(), pg_update(), pg_select() und pg_delete() erzeugen SQL-Anweisungen aus PHP-Arrays. Genau dabei behandelten verwundbare PHP-Versionen Backslashes in nicht vertrauenswürdigen Werten falsch.
Die Folge ist CVE-2026-17543, eine SQL-Injection. Das ist eine Schwachstelle, bei der als Daten gedachte Eingaben zu Befehlen innerhalb einer Datenbankabfrage werden. Der Fehler betrifft den seit PostgreSQL 9.1 üblichen Betrieb mit standard_conforming_strings=on: In dieser Einstellung behandelt PostgreSQL Backslashes in gewöhnlichen Zeichenketten als normale Zeichen. GitHubs Upstream-Advisory stuft den Fehler als High ein; wegen des möglichen Fernzugriffs ist er im Radar für tatsächlich erreichbare Anwendungen bedingt kritisch. Ohne Anmeldung gelingt dieser Zugriff nur, wenn auch der verwundbare Endpunkt ohne Anmeldung erreichbar ist.
So sieht der Angriff für Betreiber aus
Ein Besucher sendet eine normale Formular- oder API-Anfrage an eine PHP-Anwendung. Es gibt keine Warnung, keinen besonderen Dialog und keine Konsole. Erreicht der manipulierte Wert einen der vier betroffenen PostgreSQL-Helfer, kann eine Kombination aus Backslash und Apostroph die vorgesehene Zeichenkette beenden. Der danach folgende Teil der fremden Eingabe wird dann Teil der SQL-Anweisung.
Abhängig vom Abfragekontext kann eine erfolgreiche SQL-Injection innerhalb der Rechte des Datenbankkontos Daten lesen, verändern oder löschen. Eine Ausführung von Code im Betriebssystem folgt aus den geprüften Quellen nicht. Für Betreiber sind unerwartet breite Suchergebnisse, unplausible Änderungen oder Löschungen sowie auffällige Zeichenfolgen in HTTP- und Datenbankprotokollen denkbare, aber unspezifische Hinweise. Der Angriff kann auch ohne offensichtliche Wirkung bleiben; unauffällige Logs sind keine Entwarnung.
Der Fehler ist nicht durch jede öffentlich erreichbare PHP-Seite nutzbar. Der konkrete Pfad entsteht erst, wenn fremde Werte in pg_insert(), pg_update(), pg_select() oder pg_delete() gelangen. Parametrisierte Abfragen mit pg_query_params() oder vorbereiteten Statements trennen SQL-Struktur und Werte und verwenden diesen fehlerhaften Erzeugungsweg nicht.
Betroffene und korrigierte Versionen
Upstream nennt für die von PHP selbst unterstützten Zweige folgende Grenzen:
- PHP 8.2: korrigiert ab
8.2.33 - PHP 8.3: korrigiert ab
8.3.33 - PHP 8.4: korrigiert ab
8.4.24 - PHP 8.5: korrigiert ab
8.5.9
Distributionen pflegen darüber hinaus ältere PHP-Zweige. Canonical veröffentlichte am 10. September 2026 korrigierte Ubuntu-Pakete: 8.1.2-1ubuntu2.26 für Ubuntu 22.04, 8.3.6-0ubuntu0.24.04.11 für 24.04 und 8.5.4-0ubuntu1.3 für 26.04. Der Debian Security Tracker führt Bullseye ab 7.4.33-1+deb11u12, Bookworm ab 8.2.33-1~deb12u1 und Trixie ab 8.4.24-1~deb13u1 als korrigiert.
Was jetzt sinnvoll ist
Zuerst die tatsächlich installierte Distributionsversion des PHP-Pakets prüfen und aktualisieren. php -v allein verrät nicht immer genug, weil Distributionen Sicherheitskorrekturen unter einer älteren PHP-Versionsnummer ausliefern können. Danach im Code gezielt nach pg_insert, pg_update, pg_select und pg_delete suchen und kontrollieren, ob Werte aus HTTP-Anfragen, Imports oder anderen fremden Quellen dort ankommen. Auch nach dem Update sind pg_query_params() oder vorbereitete Statements die bessere Systemgrenze: Ein Fehler in der Maskierung sollte nicht darüber entscheiden, ob Text Text bleibt.
In den geprüften Primärquellen wird keine aktive Ausnutzung bestätigt. Das ist kein Beweis für Entwarnung, sondern nur die Grenze der belegbaren Aussage.
Quellen
- PHP-Upstream-Advisory GHSA-7qpv-r5mr-78m4, veröffentlicht am 30. Juli 2026
- Ubuntu Security Notice USN-8743-1, veröffentlicht am 10. September 2026
- Debian Security Tracker: CVE-2026-17543, abgerufen am 11. September 2026
Quellenstand: 11. September 2026.