PHP2Shell: KI findet kritische PHP-Sicherheitslücken

PHP2Shell: Kritische PHP-Lücken treffen zahlreiche Webserver -Bild: © TelefonTarifrechner.de

Wie wurde die PHP-Sicherheitslücke entdeckt?

Die Geschichte beginnt nicht mit einem einzelnen Hackerangriff. Im Jahr 2024 ließ die PHP Foundation den PHP-Code durch Quarkslab extern untersuchen. Bei der Bearbeitung eines dabei gemeldeten Problems bemerkte ein PHP-Core-Entwickler erste Anzeichen des später für CVE-2026-109618 relevanten Out-of-Memory-Problems. Ein möglicher Angriff wurde zwar theoretisch diskutiert, ein belastbarer Weg bis zur Code-Ausführung fehlte jedoch.

2026 kamen weitere Werkzeuge und Forscher hinzu. Die PHP Foundation ließ PHP unter anderem mit spezialisierten KI-Systemen untersuchen. Im Rahmen des Programms "Patch the Planet" begann das Sicherheitsunternehmen Calif am 30. Juli 2026 mit einem gezielten Audit.

Am 11. August meldete Calif schließlich eine vollständige Remote-Code-Execution mit derselben technischen Grundursache, die bereits 2024 aufgefallen war. Nach Angaben von OpenAI setzte Calif bei seiner Untersuchung GPT-5.6 Sol ein. OpenAI meldete am selben Tag unabhängig ebenfalls dieselbe Root Cause. Weitere Angriffspfade kamen anschließend unter anderem von Wiz hinzu.

Damit wäre die Aussage, eine KI habe vollkommen selbstständig den gesamten PHP-Code geprüft und anschließend ohne menschliche Beteiligung die Fehler behoben, zu weitgehend. KI-Systeme waren ein wichtiges Werkzeug bei Analyse, Validierung und Exploit-Forschung. Bewertung, Koordination, Patch-Entwicklung und Freigabe lagen weiterhin bei Sicherheitsforschern und den PHP-Entwicklern.

Wer sich grundsätzlich dafür interessiert, wie spezialisierte KI-Systeme inzwischen bei der Suche nach Softwarefehlern eingesetzt werden, findet dazu auch unseren Hintergrundbericht über Cyber-KI und automatisierte Sicherheitsanalysen.

Gab es bereits Hackerangriffe auf PHP-Webseiten?

Hier müssen Entdeckung und tatsächliche Angriffe voneinander getrennt werden. Die beiden PHP-Fehler wurden nicht erst deshalb bekannt, weil Betreiber zuvor einen großen Angriff auf ihre Webseiten festgestellt hatten. Die Entdeckungsgeschichte führt vielmehr über Sicherheitsaudits, Codeanalyse, Forschung und KI-gestützte Werkzeuge.

Die Lage bei der realen Ausnutzung ist inzwischen jedoch komplexer. Die PHP Foundation erklärte für den Zeitpunkt der koordinierten Veröffentlichung, dass bei der eigenen Prüfung der damals kursierenden Proof-of-Concepts noch kein funktionierender Exploit identifiziert worden sei. Nach der Veröffentlichung tauchten schnell weitere Angriffswerkzeuge auf.

Am 22. Oktober berichtete zudem das US-Magazin Wired unter Berufung auf Amazon Web Services, dass AWS in Honeypots verdächtige Aktivitäten bereits ab dem 17. Oktober beobachtet habe. Sollte sich diese Einordnung weiter bestätigen, wären Angriffsversuche damit schon mehrere Tage vor der offiziellen PHP-Veröffentlichung erfolgt. Für Webseiten-Betreiber ändert sich die praktische Empfehlung dadurch nicht: ungepatchte Installationen sollten schnellstmöglich aktualisiert werden.

Was steckt technisch hinter CVE-2026-109618?

Bei CVE-2026-109618 geht es um die Behandlung von Out-of-Memory-Situationen. Erreicht eine PHP-Anfrage das konfigurierte Speicherlimit in einem ungünstigen Moment, können interne Daten unvollständig initialisiert zurückbleiben. Werden diese Daten später dennoch verarbeitet, kann Speicher beschädigt werden.

Besonders relevant ist laut PHP der Einsatz von Apache mit mod_php. Dort wurde ein Angriff demonstriert, bei dem eine nicht authentifizierte Anfrage die Schwachstelle auslösen kann, noch bevor eigener Anwendungscode abgearbeitet wird. Auch bei PHP-FPM wurden Code-Ausführungspfade bestätigt.

Was passiert bei CVE-2026-109619?

Die zweite Schwachstelle betrifft veralteten globalen Zustand. Nach einem fatalen Fehler kann interner PHP-Zustand unter bestimmten Umständen weiterhin auf Speicher zeigen, der bereits freigegeben wurde. Eine spätere Anfrage desselben Workers kann anschließend auf diesen Speicher zugreifen.

Dabei handelt es sich um eine sogenannte Use-after-free-Konstellation. Auch daraus konnten Sicherheitsforscher eine Remote-Code-Execution entwickeln. Das Problem sitzt damit ebenfalls tief in PHP selbst und nicht lediglich in einem einzelnen Plugin oder Content-Management-System.

Welche PHP-Versionen schließen PHP2Shell?

PHP fordert Betreiber ausdrücklich zum Update auf. Nach Angaben des Projekts existiert keine vollständige Konfigurationslösung, die das Aktualisieren zuverlässig ersetzen könnte.

Die offizielle PHP-Webseite nennt PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 ausdrücklich als Versionen, die die beiden kritischen Fehler beheben. Ältere, nicht mehr unterstützte PHP-Zweige benötigen gegebenenfalls einen Wechsel auf eine noch gepflegte Version.

Warum können auch WordPress, Drupal und Joomla betroffen sein?

PHP2Shell ist nicht mit einer klassischen Schwachstelle in WordPress, Drupal oder Joomla gleichzusetzen. Der Fehler befindet sich im PHP-Kern. Deshalb kann eine Anwendung betroffen sein, obwohl ihr eigener PHP-Code sauber geschrieben wurde.

Das ist für Betreiber ein entscheidender Unterschied. Ein Update des WordPress-Core oder eines einzelnen Plugins beseitigt die zugrunde liegende PHP-Schwachstelle nicht automatisch. Maßgeblich ist die PHP-Version, die der Webserver tatsächlich verwendet.

Hosting-Kunden sollten deshalb im Verwaltungsbereich ihres Anbieters prüfen, welcher PHP-Zweig aktiv ist. Bei Managed-Hosting-Angeboten sollte zusätzlich kontrolliert werden, ob der Anbieter die Sicherheitsupdates bereits serverseitig eingespielt hat.

Warum spielte KI bei PHP2Shell eine so große Rolle?

PHP2Shell zeigt, wie sich die Suche nach komplexen Sicherheitsfehlern verändert. Moderne KI-Systeme können große Codebasen analysieren, Hypothesen entwickeln, Fehlerberichte vergleichen und Sicherheitsforscher beim Aufbau reproduzierbarer Testfälle unterstützen.

Die PHP Foundation beschreibt zugleich eine klare Grenze. KI kann bei der Validierung und Gruppierung von Berichten helfen, die eigentlichen Entscheidungen über Sicherheitsrelevanz und Patches werden weiterhin von Menschen getroffen. Gerade bei einem Projekt wie PHP müssen Änderungen zudem mit Kompatibilität, Performance und zahlreichen Erweiterungen vereinbar bleiben.

Der Fall macht deutlich, dass alte und bislang schwer ausnutzbare Fehler durch neue Analysewerkzeuge wieder relevant werden können. Die gleiche Entwicklung hilft Verteidigern bei der Suche nach Schwachstellen, kann aber langfristig auch Angreifern die Entwicklung von Exploits erleichtern.

Was sollten Webseiten-Betreiber jetzt prüfen?

Für Administratoren steht zunächst die tatsächlich eingesetzte PHP-Version im Mittelpunkt. Außerdem sollten Server- und Webserver-Protokolle auf auffällige Fehler, Abstürze oder ungewöhnliche HTTP-Anfragen kontrolliert werden.

• PHP-Version des Webservers kontrollieren
• PHP 8.5 auf mindestens 8.5.12 aktualisieren
• PHP 8.4 auf mindestens 8.4.27 aktualisieren
• PHP 8.3 auf mindestens 8.3.36 aktualisieren
• PHP 8.2 auf mindestens 8.2.35 aktualisieren
• Nicht mehr unterstützte PHP-Versionen möglichst ablösen
• Server- und WAF-Protokolle auf ungewöhnliche Aktivitäten prüfen
• Nach dem Update PHP-Worker beziehungsweise Webserver neu starten

Eine Web Application Firewall kann zusätzliche Schutzmechanismen liefern. Sie sollte hier aber nicht als Ersatz für das Sicherheitsupdate verstanden werden. PHP selbst bezeichnet das Aktualisieren als den sicheren Weg, die beiden Schwachstellen vollständig zu schließen.

Wer seine Systeme zusätzlich gegen Schadsoftware absichern möchte, kann auch die aktuellen Viren-Schutz-Angebote im Vergleich prüfen. Ein Virenscanner ersetzt allerdings weder PHP-Updates noch eine ordnungsgemäße Serverwartung.

FAQ zu PHP2Shell und den PHP-Sicherheitslücken

Was ist PHP2Shell?

PHP2Shell ist eine Bezeichnung für zwei kritische PHP-Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Unter bestimmten Bedingungen können sie eine nicht authentifizierte Remote-Code-Execution auf betroffenen Webservern ermöglichen.

Wurden die PHP-Sicherheitslücken durch Hacker entdeckt?

Nach den veröffentlichten Informationen wurden die Fehler durch Sicherheitsforschung, Audits und KI-gestützte Codeanalyse aufgedeckt. Später wurden jedoch auch Angriffsversuche gemeldet. Entdeckung und tatsächliche Ausnutzung sind deshalb getrennt zu betrachten.

Hat eine KI den PHP-Fehler gefunden?

KI war an der Sicherheitsforschung wesentlich beteiligt. OpenAI zufolge setzte Calif GPT-5.6 Sol bei der Untersuchung ein. Mehrere Forschergruppen arbeiteten parallel. Validierung, Sicherheitsbewertung, Patch-Entwicklung und Veröffentlichung blieben Aufgaben menschlicher Experten.

Welche PHP-Versionen schließen die Sicherheitslücken?

Die korrigierten Versionen sind PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 und PHP 8.2.35. PHP empfiehlt ein sofortiges Update, da keine vollständige Konfigurations-Mitigation existiert.

Sind WordPress-Webseiten automatisch von PHP2Shell betroffen?

Die Schwachstellen befinden sich in PHP und nicht direkt in WordPress. Entscheidend ist deshalb die auf dem Webserver eingesetzte PHP-Version. Läuft eine WordPress-Seite auf einer verwundbaren PHP-Version, kann die zugrunde liegende Serverumgebung betroffen sein.

Weitere Infos zu den derzeitigen Angeboten erhalten Sie beim Viren-Schutz-Tarifrechner.

Damit Ihnen in Zukunft kein Spar-Angebot entgeht, können Sie sich auch bei unserem kostenlosen Newsletter anmelden. Einmal in der Woche bekommen Sie dann eine Übersicht an Aktionen und wichtigen Änderungen im Telefonmarkt. Noch schneller sind Sie aber via X (ehemals Twitter) und Facebook informiert.