Zwei kritische PHP-Lücken mit CVSS 9,2 sickerten einen Tag vor dem Patch durch, Exploits sind schon unterwegs

Das PHP-Projekt hat Fixes für zwei Fehler veröffentlicht, über die ein Angreifer ohne Anmeldung Code auf einem Server ausführen kann. Ein Leak der CVE-Nummern und ein versehentlich veröffentlichtes Video haben Angreifern einen Vorsprung verschafft. Admins laufen jetzt gegen funktionierende Exploits an.

Die Patches kamen einen Tag früher, weil die CVE-Nummern durchsickerten

Am 21. Oktober hat das PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie beheben zwei kritische Fehler mit CVSS v4.0 9,2. Der erste (CVE-2026-109618) entsteht, wenn eine Anfrage im falschen Moment an memory_limit stößt. PHP hält dann halb initialisierte Daten für gültig und beschädigt den Speicher. Der zweite (CVE-2026-109619) hinterlässt nach einem fatalen Fehler einen Verweis auf Speicher, den eine frühere Anfrage schon freigegeben hat.

Geplant war der 22. Oktober um 14:00 UTC. Einen Tag vorher, gegen 15:00 UTC, tauchten beide CVE-Nummern in Foren und sozialen Netzwerken auf, dazu mit einem falschen Score von 10,0. Laut PHP Foundation sind keine technischen Details durchgesickert. Das Projekt zog das Release um einen Tag vor. Am Abend veröffentlichte die Sicherheitsfirma Calif versehentlich ein Video, in dem ihr Proof of Concept gegen mehrere Ziele funktioniert. Sie löschte es, doch Kopien verbreiteten sich weiter und beschleunigten laut der Stiftung weitere Exploits.

Am schlimmsten trifft es Apache mit mod_php. Dort reicht eine einzige Anfrage ohne Anmeldung, die den Angriff auslöst, bevor überhaupt Anwendungscode läuft, und zwar mit Standardeinstellungen. Betroffen sind aber alle Installationen, die Webanfragen bedienen, auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Wiz Research, eine der meldenden Firmen, hat Angriffe ohne Anmeldung auf WordPress, Drupal und Joomla vorgeführt. Laut Wiz ist jede PHP-Version seit 5.4 betroffen. Dieselbe Firma schätzt, dass PHP 70 % aller Websites antreibt.

Der Fehler steckte zwei Jahre in PHP, bis Frontier-Modelle ihn knackten

Am spannendsten ist die Zeitleiste. Ein von der PHP Foundation bezahlter Entwickler fand erste Spuren des Speicherproblems schon 2024. Das geschah bei einem externen Audit, das die Sovereign Tech Agency finanzierte und Quarkslab durchführte. Einen Weg zur Codeausführung kannte damals niemand. Das Team wog mehrere Fixes ab, und jeder machte etwas kaputt: Kompatibilität, Performance oder Erweiterungen von Drittanbietern. Die Stiftung nennt die Verzögerung selbst ein strukturelles Versagen eines kleinen Teams, das im Konsens entschied.

Die Wende kam im August 2026. Am 11. August meldete Calif eine bedingungslose Codeausführung mit derselben Ursache. Wiz und OpenAI lieferten weitere Angriffswege. Wiz gibt an, den ersten Fehler mit dem eigenen Werkzeug Wiz Atlas und den Modellen Gemini 4 Argon und GPT-5.6 Sol gefunden zu haben. Der Exploit verlangt laut Wiz, mehrere Fehler zu verketten und auf das Speicherlayout jedes Ziels abzustimmen. Frontier-Modelle haben diese Arbeit auf Stunden verkürzt.

Hier liegt die zweite Ebene der Geschichte. Die Komplexität des Exploits war lange ein stiller Schutz: Der Fehler war bekannt, aber niemand hatte Zeit, ihn zu Ende zu bringen. Erledigt ein Modell diese Arbeit, wartet ein theoretischer Fehler nicht mehr jahrelang. Admins bleibt weniger Zeit zwischen Bekanntgabe und Angriff, Open-Source-Projekte bekommen mehr Arbeit bei wenigen Leuten. Seit dem 1. Juli hat das PHP-Team 15 CVEs veröffentlicht und mehr als 100 Meldungen bearbeitet, die ungültig, doppelt oder nicht reproduzierbar waren.

Keine Konfiguration schützt den Server vollständig

Das PHP-Projekt beschreibt Übergangsmaßnahmen, etwa session.upload_progress abzuschalten oder memory_limit anders zu handhaben. Es sagt aber selbst, dass keine davon eine Installation sicher macht. Vollen Schutz bietet nur das Update. Versionen vor 8.2 bekommen vom Projekt keinen Fix. Wer sie betreibt, ist auf Backports der Distribution oder eines LTS-Anbieters angewiesen. Das von Freiwilligen gepflegte Paket-Repository, auf das sich viele Server verlassen, hatte am Release-Tag kein Update.

Für Websites in Europa geht die entscheidende Frage an den Hoster. Bei Shared Hosting können Kunden die PHP-Version oft nicht selbst ändern, das Risiko hängt also an der Reaktionszeit des Anbieters. Eigene Container und Images reparieren sich nicht von allein. Sie müssen neu gebaut und alle Worker neu gestartet werden.

Das Tempo der Hoster zeigt, wie viele Websites offen bleiben

Das erste Signal kommt von Hostern und Distributionen. Linux-Distributionen und LTS-Anbieter haben die Patches vorab erhalten und sollten sofort Pakete haben. Websites bei langsamen Anbietern stehen ganz oben auf der Liste von Angreifern, die schon einen funktionierenden Exploit haben.

Das zweite Signal ist langfristig. Die PHP Foundation bittet Unternehmen, die auf PHP setzen, die Sicherheitsarbeit mitzufinanzieren. Wenn KI sowohl die Fehlersuche als auch die Ausnutzung weiter beschleunigt, wird Geld für Wartung zu einer Frage der Betriebssicherheit. Version 8.2 erreicht außerdem am 31. Dezember 2026 ihr Supportende, der nächste Fix dieser Art geht also an ihr vorbei.

Liliths Urteil

Ein Fehler aus 2024 lag zwei Jahre in den Notizen eines kleinen Teams, bis Frontier-Modelle daraus einen Exploit machten. Dann genügte ein versehentlich veröffentlichtes Video, und die Angreifer starteten in derselben Nacht wie die Server-Admins.