PHP kannte die Fehlerart der neuen Sicherheitslücke seit 2004

„Eine neu entdeckte, schwerwiegende Sicherheitslücke“ meldete dpa-AFX am 21. Oktober in PHP. Auf dieser Programmiersprache läuft unter anderem WordPress. Dem PHP-Team gemeldet hatte die Sicherheitsfirma Calif sie schon am 11. August. Neu ist an ihr der Angriffsweg. Die Fehlerart ist seit 2004 bekannt, erste Anzeichen der Lücke selbst gab es 2024.

Den Namen PHP2Shell gab Calif. Darunter laufen zwei verwandte Lücken, CVE-2026-109618 und CVE-2026-109619. Die Berichterstattung dreht sich seither um Updates. Welche PHP-Versionen den Fix enthalten¹, steht im Beitrag vom 21. Oktober.

Jede PHP-Anfrage darf nur eine bestimmte Menge Arbeitsspeicher belegen. Die Grenze steht in der Einstellung memory_limit. Wird sie erreicht, bricht PHP die Anfrage hart ab. Geschieht das an einer unsicheren Stelle, bleiben halb angelegte Daten im Speicher zurück. Beim Aufräumen liest PHP sie trotzdem. Darüber führt ein Angreifer eigenen Code auf dem Server aus.

Stefan Esser beschrieb den Abbruch an der Speichergrenze 2004#

Im Juli 2004 veröffentlichte der Sicherheitsforscher Stefan Esser eine Warnung mit dem Titel „PHP memory_limit remote vulnerability“². Als Risiko gab er „Critical“ an. Ein Angreifer könne den Abbruch an der Speichergrenze „an Stellen auslösen, an denen eine Unterbrechung unsicher ist“, schrieb Esser. So lasse sich beliebiger Code ausführen (eigene Übersetzung).

Betroffen waren damals unter anderem der Code für Datei-Uploads und die Session-Erweiterung. 2026 fand Calif die Angriffswege wieder dort: beim Upload mehrteiliger Formulare und bei der Fortschrittsanzeige für Session-Uploads. In Essers Beispiel wie in Califs erstem Fund traf der Abbruch eine Hashtabelle, eine Grundstruktur von PHP, die erst halb eingerichtet war.

PHP reparierte 2004 die gemeldeten Stellen, mit Version 4.3.8³. Den Abbruch selbst baute PHP erst 2026 um.

PHP empfiehlt heute wieder Essers Notbehelf von 2004#

Esser nannte 2004 einen Notbehelf: memory_limit abschalten. Die Seite bleibe dann verwundbar für „speicherhungrige PHP-Skripte“ und für POST-Anfragen, die riesige Variablen anlegen.

Für Server ohne Update lautet der Notbehelf 2026 wieder: memory_limit=-1, also keine Grenze. Die Sicherheitsmeldung von PHP⁴ schreibt dazu: „Das ist keine vollständige Abhilfe.“ Schlägt eine Speicheranforderung auf anderem Weg fehl, springt PHP trotzdem an der unsicheren Stelle heraus. Calif warnt wie Esser: Ohne Grenze steige das Risiko, dass der Speicher ausgeht.

2006 verließ Esser das PHP-Sicherheitsteam im Streit#

Im Dezember 2006 trat Esser aus dem PHP Security Response Team aus. In seinem Blog⁵ nannte er am 9. Dezember jeden Versuch, PHP „von innen“ sicherer zu machen, „zwecklos“. Die „langsame Reaktionszeit“ bei Sicherheitslücken werde er nicht länger verbergen. Manche seiner Warnungen würden ohne Patch erscheinen. Das Team habe sich „monatelang geweigert“, sie zu beheben.

Zeev Suraski, Technikchef der PHP-Firma Zend, widersprach gegenüber heise Security. Falsch sei, dass das Projekt etwas vertusche. Man wolle nur einen Patch haben, bevor ein Fehlerbericht erscheint.

Seit 2024 kannte PHP erste Anzeichen der Lücke#

2024 bezahlte der Bund über den Sovereign Tech Fund eine Sicherheitsprüfung des PHP-Kerns. Die Firma Quarkslab führte sie durch. Beim Beheben eines ihrer Funde stieß ein von der PHP Foundation bezahlter Entwickler auf „erste Anzeichen“ des Problems. Im Auditbericht selbst steht es nicht.

Ein Angriff sei 2024 „theoretisch erwogen“ worden, schreibt die PHP Foundation⁶. Konkrete Angriffswege habe niemand gefunden, andere Funde mit klarer Wirkung hätten die Bedenken überlagert. Für den Fix entwickelte das Team mehrere Ansätze. Jeder hatte Nachteile: Brüche mit altem Code, neue Wege für Überlastungsangriffe oder Änderungen an vielen Erweiterungen Dritter. Das Team entschied nur im Konsens. Die Arbeit kam über Monate „immer wieder ins Stocken“.

Calif suchte 2026 gezielt nach Verwandten von Essers Fehler#

Die PHP Foundation brachte PHP selbst in das Programm „Patch the Planet“ von OpenAI. Darin begann Calif am 30. Juli 2026 eine Prüfung. Der Forscher Ryan Austin beschreibt seinen ersten Schritt auf der Seite zu PHP2Shell⁷. Um „lange verschollene Geschwister von Stefans Fehler aus 2004“ zu finden, suchte er zuerst nach Wegen, das memory_limit zu überschreiten.

Am 11. August meldete Calif eine Codeausführung aus der Ferne, ohne jede Vorbedingung. Laut Foundation hat sie „dieselbe Ursache“ wie das Speicherproblem von 2024. OpenAI meldete die Ursache unabhängig davon. Erst von da an hatte der Fix „oberste Priorität“.

Das Update vom 21. Oktober streicht den Sprung aus der unsicheren Stelle. PHP bricht jetzt an der nächsten sicheren Stelle ab. Nur wenn der Speicher eine zweite, höhere Grenze erreicht, beendet es den Prozess sofort. Funktionierende Angriffe hatte das Sicherheitsteam bis zur Veröffentlichung nicht entdeckt, schreibt die Foundation.

Die PHP Foundation nennt die Verzögerung ein Versagen#

„Wir werden nicht so tun, als wäre es anders: Die Verzögerung war ein strukturelles Versagen“, schreibt die Foundation. Verursacht hätten es der Entscheidungsweg des Sicherheitsteams und sein Mangel an Ressourcen. Inzwischen stellt das Team seine Abläufe um, damit es auch mit Mehrheit entscheiden kann.

Esser zählte 2006 gegenüber heise Security höchstens drei Leute auf der Sicherheitsliste, die sich zum Fixen genötigt fühlten. Die Foundation schreibt 2026, es gebe zu wenige Entwickler, die den ganzen PHP-Code kennen.