PHP-Sicherheitsupdate Oktober 2026: zwei kritische RCEs

Die letzten zwei Monate waren für PHP-Administratoren ungewöhnlich bewegt: vier Security-Releases im September, ein außerplanmäßiger Notfallpatch im Oktober und EOL-Termine, die die Versionsplanung dringend machen. Was passiert ist — und was jetzt zu tun ist. Alle Punkte stammen aus den offiziellen php.net-Ankündigungen und den verlinkten Advisories.

24. September 2026: Security-Releases für 8.2, 8.3, 8.4 und 8.5

PHP hat 8.5.11, 8.4.26, 8.3.35 und 8.2.34 (https://www.php.net/archive/2026.php#2026-09-24-5) als eigene Security-Releases für alle gepflegten Zweige veröffentlicht. Die GitHub-Advisories dieses Zyklus umfassen rund ein Dutzend CVEs; drei davon betreffen typische Server-Setups direkt:

• CVE-2026-91768 (GHSA-62xp-839h-2637 (https://github.com/php/php-src/security/advisories/GHSA-62xp-839h-2637)): IPv6-ACL-Bypass in PHP-FPMs listen.allowed_clients. Die FastCGI-Zugriffskontrolle verglich nur 12 der 16 Adressbytes — ein Angreifer mit /96-Präfix-Gemeinsamkeit konnte den FPM-Endpunkt erreichen. Unix-Sockets und reine IPv4-Setups sind nicht betroffen.
• CVE-2026-91769: Die TLS-Hostname-Verifizierung der OpenSSL-Extension konnte nach SAN-Fehlschlag auf den Common Name zurückfallen — vor allem bei Verbindungen in private PKIs und interne CAs relevant.
• CVE-2026-91766: Der HTTP-Stream-Wrapper leitete Authorization-/Cookie-Header bei Cross-Origin-Redirects unverändert weiter.

Im selben Zyklus wurden außerdem Probleme in SOAP, Phar, mysqlnd und den Standard-Streams behoben (eine komplette CVE-Tabelle pflegen Dritte, z. B. PatchMyPHP (https://patchmyphp.com/php-vulnerabilities/)). Fazit dieser Runde: aktualisieren, FPM-Worker neu starten und php -v auf jedem SAPI prüfen — nicht nur in der CLI.

21. Oktober 2026: Notfall-Release für zwei kritische RCEs

Zehn Tage vor Monatsende wurde es ernst. Nach einer ungewöhnlichen Vorabankündigung (https://news-web.php.net/php.announce/509) — für sich genommen ein Schweregrad-Signal — hat PHP am 21. Oktober 2026 um 14:00 UTC 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (https://www.php.net/archive/2026.php#2026-10-21-5) veröffentlicht. Behoben werden zwei kritische Schwachstellen, in der Vorabankündigung mit 9,2 (CVSS v4.0) eingestuft:

• CVE-2026-109618 — „RCE via OOM corruption“ (GHSA-w8hw-w9fx-j79w (https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)): Die Out-of-Memory-Behandlung kann PHP unterbrechen, während interne Request-Daten nur teilweise initialisiert sind; das Aufräumen kann die fehlerhaften Daten dann als gültig behandeln.
• CVE-2026-109619 — „RCE via stale global state“ (GHSA-6wmf-4rv5-p3rp (https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)): Request-eigener State kann das Freigeben des Speichers überleben und vom nächsten Request desselben Workers wiederverwendet werden.

Beide erlauben unauthentifizierte Remote-Code-Execution, bevor Anwendungscode überhaupt läuft. Nach Einschätzung von php.net ist das Risiko bei Apache mit mod_php am höchsten (dort existiert ein demonstrierter Exploit); betroffen sind aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Im offiziellen Advisory (https://www.php.net/archive/2026.php#2026-10-21-5) steht klar: Es gibt keine vollständigen Mitigationen — nur das Update ist sicher. Die Linux-Distributionen erhielten die Patches vorab, die Pakete waren daher meist am selben Tag bereit.

Wenn ein sofortiges Update nicht geht

Nur das Update schließt die Lücke vollständig, aber das Advisory listet Übergangsmaßnahmen, welche die Angriffspfade verengen:

• memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können (php_admin_value im FPM-Pool bzw. Apache-Konfiguration), und post_max_size niedrig halten (8M ohne Uploads, 32M mit), mit upload_max_filesize darunter.
• Limits für Request-Größe, Feldzahl und Verschachtelungstiefe auf Webserver-/Proxy-Ebene erzwingen; cgroup-/Container-Limits als Verfügbarkeits-Grenze nutzen. Nicht RLIMIT_AS bzw. RLIMIT_DATA einsetzen — sie lösen den verwundbaren Allokationspfad erst aus.
• session.upload_progress.enabled=0 setzen und jeden Worker neu starten; unter PHP 8.5 zusätzlich fatal_error_backtraces=0.
• Dranbleiben: Am 23. Oktober folgte eine Informations-Advisory (https://www.php.net/archive/2026.php#2026-10-23-1) zu CVE-2026-115560, einer unwahrscheinlichen Kombination aus Serialize-Handler-Wechsel und Upload-Progress als RCE-Vektor — die vollständige Lösung kommt mit dem nächsten regulären Bugfix-Release.

Ältere Zweige und die 8.2-Frist

PHP 8.1 und älter erhalten vom Projekt keine Updates mehr; es gibt nur minimale Source-Backports für 7.4, 8.0 und 8.1 als Zwischenlösung für Selbst-Kompilierer. Planen Sie bewusst: Laut der Supported-Versions-Tabelle (https://www.php.net/supported-versions.php) endet die Security-Unterstützung von PHP 8.2 am 31. Dezember 2026 — in zwei Monaten. Jede 8.2-Inventur braucht deshalb einen jetzt terminierten Upgrade-Pfad auf 8.3 oder neuer, nicht erst nach dem Jahreswechsel. PHP 8.6.0 steckt noch in Release Candidates (RC4 enthält die Fixes, RC5 ist für den 5. November 2026 geplant) und gehört nicht in die Produktion.

Windows-Hosts

Am 26. Oktober erschienen neu gebaute Windows-Pakete (https://www.php.net/archive/2026.php#2026-10-26-1) (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) mit Brotli 1.2.1, das CVE-2026-111497 behebt — einen Out-of-Bounds-Write in der Brotli-Dekompression. Auf Windows-Systemen prüfen Sie, dass Sie die Rebuilds mit -1 einsetzen, nicht die Original-Binaries.

Checkliste für Server-Administratoren

• Alle PHP-SAPIs im Bestand inventarisieren (php -v in CLI, FPM- und mod_php-Kontext) — die NCSC-Leitlinie (https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php) zu CVE-2026-109618/109619 betont die Auffindung, nicht nur das Upgrade.
• Auf 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 aktualisieren (oder das Backport-Paket Ihres Herstellers) und alle Worker neu starten.
• Falls das Patchen sich verzögert: Mitigationen umsetzen — internetseitige Systeme mit besonderer Dringlichkeit.
• Auf Systemen, die eine Weile exponiert waren, vor dem Abschluss nach Kompromittierungs-Spuren suchen.

Fazit

Zwei unauthentifizierte RCEs im PHP-Kern sind ein Ereignistyp, bei dem Stunden zählen und der Zustand der Distribution-Pakete, der FPM-Pool-Konfigurationen und der Update-Disziplin entscheidet, ob die Flotte sicher ist. Genau das ist der Alltag von Linux-Server-Admin.com s.r.o. (https://linux-server-admin.com): Wir verwalten Linux-Server und PHP-Stacks, koordinieren Notfall-Patching mit den jeweiligen Anwendungsverantwortlichen und halten einen getesteten Update-Pfad bereit — leise, in Wartungsfenstern, bevor sich die Alarme stapeln. Wer das nächste Notfall-Release nicht allein durchstehen will, erreicht unsere Teams in Prag über die Website.

Quellen

• php.net News-Archiv 2026 und das Security-Advisory vom 21. Oktober: https://www.php.net/archive/2026.php
• GHSA-w8hw-w9fx-j79w / GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories
• NVD-Einträge: https://nvd.nist.gov/vuln/detail/CVE-2026-109618 und https://nvd.nist.gov/vuln/detail/CVE-2026-109619
• PHP Supported Versions: https://www.php.net/supported-versions.php
• UK NCSC-Leitlinie: https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
• CERT/CC VU#763488: https://www.kb.cert.org/vuls/id/763488