In der Speicherverwaltung (CVE-2026-109618) und im Fehlermanagement (CVE-2026-109619) der Skriptsprache PHP stecken zwei kritische Sicherheitslücken, die den CVSS-Schweregrad 9,2 von 10 aufweisen und sich ohne besondere Rechte von außen angreifen lassen. Web-Server, die PHP nutzen, müssen umgehend abgesichert werden. Auch Geräte wie Router oder NAS-Systeme, auf denen Web-Server mit PHP-Unterstützung laufen, sind betroffen. Und leider sind die Schwachstellen und die Korrekturen zu früh durchgesickert, so dass zeitnahe Angriffe drohen.

Nennen wir es "Chaotic Disclosure"
Das ist ziemlich dumm gelaufen. Eigentlich hatte sich die Sicherheit bei PHP über die vergangenen Jahren stark verbessert, was angesichts der großen Verbreitung dieser Skriptsprache auch dringend erforderlich war. Doch ausgerechnet in dem Moment, als zwei der schlimmsten Fehler in der Geschichte des Projekts geplant geschlossen werden sollten, ging alles schief:

• Der Speicherfehler CVE-2026-109618 wurde bereits im Jahr 2024 im Nachgang eines externen Audits durch Quarkslab von einem PHP-Entwickler gefunden. In der Folge wurde an einem Fix gearbeitet, aber da jede Korrektur zu größeren Nebenwirkungen führte, rutsche das Problem immer weiter nach hinten.
• Am 11. August 2026 stolperten die Sicherheitsfirma Calif und die KI-Firma OpenAI zeitgleich über den Fehler. In der Folge wurde das Problem näher untersucht und es fanden sich immer neue Angriffsvektoren, welche nach und nach das wahre Ausmaß des Problems offenbarten.
• Die Veröffentlichung eines Patches wurde für den 22. Oktober 2026 um 14 Uhr UTC angesetzt, doch erste Informationen sickerten bereits im Vorfeld durch. Um die Lage zu beruhigen, veröffentlichte das PHP-Team am 20. Oktober 2026 um 19:30 Uhr UTC eine Vorankündigung.
• Nun ging alles schief: Die Presse berichtete über den bevorstehenden Untergang des Internets, die Sicherheitsfirma Calif gab irrtümlich erste Details zu den Schwachstellen frei und dann brach Chainguard das Embargo und lieferte die Patches zu früh aus, so dass Angreifer diese vorab analysieren konnten.
• Einen Tag zu früh, am 21. Oktober 2026 um 14 Uhr UTC, zog man bei PHP die Konsequenzen und gab die Updates auf PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 frei. Später sollen Backports für die Versionen 7.4, 8.0 und 8.1 folgen. Doch den Fehler gibt es mindestens seit PHP 5, welches von 2009 bis 2014 aktuell war.

Details zu den beiden Sicherheitslücken

• RCE via OOM corruption (CVE-2026-109618) - CVSS 9,2
  Sollte PHP der Speicher ausgehen, wird dies im Normalfall mittels longjmp() abgefangen. Doch in bestimmten Fällen kann es dazu kommen, dass Speicherzugriffe schon möglich sind, bevor der Speicher vollständig initialisiert wurde. Wenn dies geschieht, wird der Speicherfehler nicht abgefangen und der Speicherinhalt auch nicht zurückgesetzt, sondern verbleibt in einem unbestimmten Zustand. Angreifer können diesen Zustand gezielt provozieren und dabei eigenen Code in den Speicher schreiben, welcher dann im Kontext der Webseite ausgeführt wird.
• RCE via stale global state (CVE-2026-109619) - CVSS 9,2
  PHP verwendet verschiedene globale Zustände, beispielsweise bei der Fehlerbehandlung, welche auf Speicher verweisen, der von einer einzelnen Anfrage belegt ist. Bevor der Speicher dieser Anfrage freigegeben wird, müssen die Zustände zurückgesetzt werden. Bei Fehlern wie CVE-2026-109618, aber auch unter anderen Umständen, funktioniert das jedoch nicht, so dass der Request-Heap freigegeben wird, obwohl das globale Worker-Feld noch darauf verweist. Führt das zu einer Verwendung nach Freigabe (Use After Free), kann ein Angreifer eigenen Codes einschleusen und ausführen.

Au-Ja geht offline
Auf unserem Server läuft aktuell eine angreifbare Version von PHP. Inwiefern unser Hoster bereits Sicherheitsmaßnahmen ergriffen hat, ist unklar, da dessen eigene Seite derzeit offline ist und wir bisher keine Informationen zum weiteren Vorgehen erhalten haben. Und es macht in einer solchen Ausnahmesituation auch keinen Sinn, den Support des Hosters mit Anfragen zu bombadieren. Aus Sicherheitsgründen haben wir unsere Seite daher vorerst offline genommen.