PHP 8.5.9, 8.4.24, 8.3.33, 8.2.33: Koordinierter Security-Release schließt PostgreSQL-SQL-Injection und BCMath-Speicherfehler

TL;DR — 90 Sekunden

Betroffen?

PHP 8.2.x vor 8.2.33, 8.3.x vor 8.3.33, 8.4.x vor 8.4.24 und 8.5.x vor 8.5.9 — praktisch jede aktuell unterstützte PHP-Linie.

Risiko?

Vier Schwachstellen in einem koordinierten Release: SQL-Injection in der PostgreSQL-Anbindung (PGSQL/PDO_PGSQL) über eine Lücke im Escaping der E'...'-Syntax (CVE-2026-17543), ein Out-of-Bounds-Write in BCMaths bccomp() bei präparierten Zahlenwerten (CVE-2026-17544), ein Denial-of-Service-Crash in Phar durch rekursive Symlinks (CVE-2026-7260) sowie ein Upgrade der gebündelten libgd-Bibliothek (CVE-2026-9672). Offizielle CVSS-Werte hat php.net nicht veröffentlicht.

Sofortmaßnahme?

Auf die aktuelle Patch-Version der eigenen PHP-Linie aktualisieren (8.2.33 / 8.3.33 / 8.4.24 / 8.5.9). Zusätzlich Codebasen prüfen, die Nutzereingaben ohne Parameterbindung in PostgreSQL-String-Literale mit E'...'-Syntax einbauen.

Empfehlung?

Kritisch vor allem für Codebasen mit direkter String-Interpolation in PGSQL-Queries oder mit ungefilterten Werten in BCMath-Vergleichsfunktionen — für alle anderen ein Routine-Update mit hoher Priorität.

Kritikalität?

hoch (Hero-Badge) — kein bestätigtes RCE, aber SQL-Injection-Potenzial plus Speicherfehler in weit verbreiteten Extensions, betrifft alle unterstützten Branches gleichzeitig; nach aktuellem Kenntnisstand keine aktive Ausnutzung.

Was ist das Problem?

CVE-2026-17543 — SQL-Injection in PGSQL/PDO_PGSQL (GHSA-7qpv-r5mr-78m4)

PostgreSQL erlaubt String-Literale in der erweiterten Escape-Syntax E'...', in der Backslash-Sequenzen wie \x00 oder \n als Steuerzeichen interpretiert werden. PHPs PGSQL- und PDO_PGSQL-Erweiterungen haben diese Sequenzen beim Aufbau von Query-Strings nicht durchgängig korrekt behandelt: Baut eine Anwendung Nutzereingaben direkt — ohne pg_query_params() oder vorbereitete Statements — in ein E'...'-Literal ein, kann ein Angreifer mit einer präparierten Backslash-Sequenz aus dem Literal ausbrechen und eigene SQL-Syntax einschleusen. Betroffen ist damit nicht die parametrisierte Query-Ausführung selbst, sondern ausschließlich Code, der Werte weiterhin per String-Konkatenation in PostgreSQL-Statements einfügt.

CVE-2026-17544 — Out-of-Bounds-Write in BCMath (GHSA-x692-q9x7-8c3f)

Die BCMath-Erweiterung für Arbitrary-Precision-Arithmetik verarbeitet Zahlen intern über die Funktion bc_str2num(), die von bccomp() beim Vergleich zweier Zahlen aufgerufen wird. Ein präparierter numerischer Eingabewert kann bc_str2num() dazu bringen, außerhalb des für die interne Zahlendarstellung reservierten Speicherbereichs zu schreiben — klassische Speicherkorruption. Jedes Projekt, das ungefilterte externe Werte in BCMath-Vergleichsfunktionen wie bccomp() fließen lässt, ist betroffen.

CVE-2026-7260 — Crash durch rekursive Symlinks in Phar (GHSA-vc5h-9ppw-p5f3)

Die Phar-Erweiterung kann beim Verarbeiten von Archiven, die rekursive bzw. zirkuläre symbolische Links enthalten, in eine Endlosschleife bzw. einen Speicherschöpfungs-Crash laufen. Der Effekt ist ein Denial of Service, keine Codeausführung; relevant überall dort, wo Phar-Archive aus nicht vollständig vertrauenswürdigen Quellen verarbeitet werden.

CVE-2026-9672 — libgd-Upgrade

Der Release aktualisiert die in PHP gebündelte libgd-Bibliothek (GD-Erweiterung für Bildverarbeitung). Weder php.net noch die von uns geprüften Sekundärquellen nennen technische Details zur zugrunde liegenden Schwachstelle — wir wollen an dieser Stelle nichts erfinden. Praktisch bedeutet das: Wer Bild-Uploads oder -Verarbeitung über die GD-Erweiterung anbietet, sollte das Update dennoch mitziehen, auch ohne genaue Kenntnis des Angriffsvektors.

Wer ist betroffen?

Alle vier aktuell unterstützten PHP-Linien sind betroffen, was für einen koordinierten Security-Release typisch ist — die zugrunde liegenden Fehler stecken in Code, der branchübergreifend gleich oder ähnlich ist (PGSQL-Escaping, BCMath-Zahlendarstellung, Phar-Pfadverarbeitung). Besonders praxisrelevant für TYPO3-/Sylius-/Symfony-Betreiber: PGSQL bzw. PDO_PGSQL ist nur relevant, wenn PostgreSQL tatsächlich als Datenbank im Einsatz ist — die deutlich verbreitetere MySQL/MariaDB-Anbindung ist von CVE-2026-17543 nicht betroffen. BCMath und Phar sind dagegen Bestandteil vieler Standard-Installationen und potenziell überall relevant, wo Composer-Pakete .phar-Archive verarbeiten oder Arbitrary-Precision-Arithmetik (z. B. in Preisberechnungen, Kryptografie-Bibliotheken) zum Einsatz kommt.

Auswirkungen

Die vier Schwachstellen wirken sehr unterschiedlich und sollten nicht über einen Kamm geschoren werden. CVE-2026-17543 (PGSQL-SQL-Injection) hat das größte Schadenspotenzial, ist aber bedingt: Es benötigt Anwendungscode, der Nutzereingaben ohne pg_query_params() bzw. vorbereitete Statements direkt in ein E'...'-String-Literal einbaut — in modernen Codebasen mit konsequenter Parameterbindung (wie es Doctrine DBAL, PDO mit Prepared Statements oder TYPO3s Query-Builder standardmäßig tun) ist der Angriffspfad in der Regel nicht erreichbar. Ist er es doch, reicht die Bandbreite von Informationsabfluss bis zu Datenmanipulation, abhängig von den Datenbankrechten der Anwendung.

CVE-2026-17544 (BCMath-Speicherfehler) ist eine klassische Speicherkorruption — der unmittelbare Effekt ist ein Crash, das theoretische Eskalationspotenzial bis zu Codeausführung hängt stark vom konkreten Speicherlayout und der PHP-Build-Konfiguration ab und ist nicht öffentlich demonstriert. CVE-2026-7260 (Phar-Symlink-Crash) ist ausschließlich ein Denial-of-Service-Risiko. Für CVE-2026-9672 (libgd) liegt uns keine verifizierte Aussage zur konkreten Auswirkung vor — wir empfehlen das Update dennoch aus Vorsicht.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Heute handeln, wenn … Ihre Anwendung PostgreSQL nutzt und irgendwo Nutzereingaben ohne Parameterbindung in SQL-Strings einbaut — prüfen Sie das unabhängig vom Patch-Stand.
• Mit Priorität patchen, wenn … Sie BCMath oder Phar-Verarbeitung mit extern beeinflussbaren Eingaben nutzen.
• Regulär einplanen, wenn … keiner der genannten Fälle zutrifft — das Update bleibt trotzdem Pflicht, da es Teil des koordinierten Security-Release ist.

Schritt 1 — PHP-Version identifizieren und aktualisieren

# Aktuelle Version pruefen
php -v

# Debian/Ubuntu mit sury.org- oder distro-eigenem PHP-Repository
sudo apt update
sudo apt list --upgradable | grep -i php
sudo apt install --only-upgrade 'php8.3*'   # Branch entsprechend anpassen (8.2/8.3/8.4/8.5)

# Alpine/Docker-Images: Basis-Image-Tag auf die gepatchte Version anheben
# z.B. FROM php:8.3.33-fpm-alpine  (statt php:8.3-fpm-alpine, das ungepinnt neuere Patch-Level zieht)

# Aus dem Quellcode gebaute Installationen: aktuellen Tarball von php.net/downloads.php ziehen
# und Signatur/Checksumme vor dem Build verifizieren

Schritt 2 — Defense-in-Depth unabhängig vom Patch

# PGSQL: niemals Nutzereingaben per String-Konkatenation einbauen,
# sondern konsequent parametrisierte Queries verwenden
# Unsicher:
# pg_query($conn, "SELECT * FROM t WHERE name = E'" . $_GET['name'] . "'");
# Sicher:
pg_query_params($conn, "SELECT * FROM t WHERE name = $1", [$_GET['name']]);

Schritt 3 — Nach dem Update verifizieren

php -v
# erwartete Ausgabe enthaelt die jeweils gepatchte Versionsnummer,
# z.B. "PHP 8.3.33" statt einer fruaheren 8.3.x-Version

Detection / Prüfung

Bestand feststellen

# PHP-Version auf allen Servern/Containern inventarisieren
for h in $(cat hosts.txt); do ssh "$h" 'php -v | head -n1'; done

# In Kubernetes: PHP-Version je laufendem Pod pruefen
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' \
  | xargs -I{} kubectl exec {} -- php -v 2>/dev/null | head -n1

Code-Basis auf riskante PGSQL-Nutzung durchsuchen

# Rohe String-Konkatenation in Richtung pg_query() aufspueren
grep -rnE "pg_query\s*\(.*\\$_(GET|POST|REQUEST|COOKIE)" --include='*.php' .

# Vorkommen von pg_query_params (sicherer Pfad) zum Abgleich zaehlen
grep -rn "pg_query_params" --include='*.php' . | wc -l

BCMath- und Phar-Nutzung mit externen Eingaben prüfen

grep -rnE "bccomp\s*\(" --include='*.php' .
grep -rn "Phar::" --include='*.php' .

Betreiberempfehlung

Mid-Market

Rollen Sie das Update auf 8.2.33/8.3.33/8.4.24/8.5.9 über den regulären Patch-Zyklus aus — keine der vier Lücken ist als aktiv ausgenutzt bekannt, ein Notfall-Fenster ist daher in den meisten Fällen nicht nötig. Priorisieren Sie trotzdem PostgreSQL-Anwendungen mit historisch gewachsenem Datenbankzugriffscode zur manuellen Prüfung auf String-Konkatenation in SQL-Statements.

Enterprise

Nutzen Sie den Release als Anlass für eine flottenübergreifende PHP-Versionsinventur — gerade bei vielen Microservices oder Legacy-Anwendungen läuft häufig ein älterer Patch-Level als angenommen. Ergänzen Sie das Patch-Rollout um ein statisches Code-Audit auf pg_query()-Aufrufe mit String-Konkatenation als dauerhafte Kontrolle, nicht nur einmalig anlässlich dieses CVEs.

Entscheidungsblock

• Sofort patchen: Update auf 8.2.33 / 8.3.33 / 8.4.24 / 8.5.9 je nach eingesetzter Linie.
• Zusätzlich prüfen: PostgreSQL-Codepfade auf String-Konkatenation in SQL-Statements, BCMath- und Phar-Nutzung mit externen Eingaben.
• Beobachten: Offizielle CVSS-Bewertung und ggf. nachträgliche Detailveröffentlichung zu CVE-2026-9672 (libgd).

Fazit

Dieser Release ist ein gutes Beispiel dafür, dass Sicherheitslücken nicht immer spektakulär aussehen müssen, um handlungsrelevant zu sein. Keine der vier Schwachstellen ist ein unauthentifiziertes Pre-Auth-RCE mit öffentlichem Exploit-Code — trotzdem lohnt sich der Blick ins Detail: CVE-2026-17543 zeigt, dass Escaping-Logik in Datenbank-Interpretern selbst fehlerhaft sein kann, unabhängig davon, wie sorgfältig eine Anwendung ihre Eingaben behandelt — ein zusätzliches Argument dafür, konsequent parametrisierte Queries statt String-Konkatenation zu verwenden, nicht nur als Stilfrage, sondern als zweite Verteidigungslinie für den Fall, dass der Interpreter selbst Lücken hat. Die BCMath- und Phar-Fixes erinnern daran, dass auch selten im Rampenlicht stehende Extensions kontinuierliche Pflege brauchen. Und der knapp dokumentierte libgd-Fix zeigt eine Grenze dieses Formats: Wir berichten nur, was sich verifizieren lässt — und nennen es klar, wenn eine Quelle das nicht hergibt.

Quellen

• php.net — PHP 8 ChangeLog (offizielle Release Notes 8.5.9 mit GHSA-/CVE-Zuordnung)
• php.watch — PHP 8.5.9 Release Summary
• LinuxCompatible — PHP 8.3.33 and 8.4.24 Released: Critical Security Fixes for PGSQL SQLi and BCMath Memory Corruption
• LinuxCompatible — PHP 8.5.9 and 8.2.33 Security Updates Drop Alongside 8.6 Alpha 3
• GitHub Security Advisory GHSA-7qpv-r5mr-78m4 (CVE-2026-17543)
• GitHub Security Advisory GHSA-x692-q9x7-8c3f (CVE-2026-17544)
• GitHub Security Advisory GHSA-vc5h-9ppw-p5f3 (CVE-2026-7260)