Aktuelles

PHP2Shell: Gepatcht ist noch lange nicht erledigt

Mittwoch, 21. Oktober 2026. Ein Datum, das sich viele Admins nicht rot, sondern dunkelschwarz im Kalender angestrichen haben dürften. An diesem Tag wurde „PHP2Shell“ öffentlich: zwei kritische Lücken im Kern von PHP, registriert als CVE-2026-109618 und CVE-2026-109619, beide mit einem CVSS-Wert von 9.2. Wir haben berichtet. Mehrmals. Übersetzt heißt das: Ein Angreifer braucht keinen Login, kein Passwort, keine Einladung. Er schickt eine passende Anfrage und führt danach eigenen Code auf dem Server aus.

Eine Woche später ist die Lage ruhiger. Die meisten Hoster haben nachgezogen, die Wartungsseiten verschwinden, Behördenportale sind wieder online, und in den Agentur-Slacks kehrt so etwas wie Normalität ein. Schön. Nur leider ist „gepatcht“ nicht dasselbe wie „erledigt“. Und der eigentlich spannende Teil dieser Geschichte fängt dank KI gerade erst an.

Was eigentlich passiert ist

PHP läuft nach Schätzungen hinter rund 70 Prozent aller Websites weltweit. WordPress, Joomla!, Drupal, TYPO3, Moodle, dazu unzählige Eigenentwicklungen, Shops und Verwaltungsoberflächen. Das Fatale an PHP2Shell: Die Lücken stecken nicht in einem Plugin oder einem schlampig gebauten Theme, sondern in der Laufzeitumgebung selbst. Die Forscher von Wiz haben das an frischen Standardinstallationen von WordPress, Drupal und Joomla demonstriert und sogar an einer simplen „Hello, World!“-Seite. Wer PHP ausführt, war potenziell dran. Punkt.

Technisch geht es ganz simpel um Speicherfehler: Eine Lücke betrifft die Fehlerbehandlung, wenn PHP das Speicherlimit reißt, die andere einen klassischen Zugriff auf bereits freigegebenen Speicher. Neben der Codeausführung lässt sich darüber auch Arbeitsspeicher auslesen, inklusive Passwörtern, Session-Tokens, API-Schlüsseln und Zertifikaten, das volle Programm. Merken Sie sich diesen Punkt, wir kommen darauf zurück.

Das BSI stufte die Lage mit Warnstufe „3 / Orange“ ein, die US-Behörden CISA und FBI riefen zum sofortigen Patchen auf, und die CISA empfahl ganz unverblümt: Wer nicht patchen kann, nimmt die Systeme vom Netz. Genau das haben zahlreiche Institutionen in Europa dann auch getan.

Über zehn Jahre blind und ungefährlich, dann kam die KI

Jetzt wird es interessant. Die Lücken stecken laut Wiz in jeder PHP-Version seit 2012!. Mehr als ein Jahrzehnt lang haben Tausende Entwickler, Auditoren und Sicherheitsforscher diesen Code gelesen, getestet, gefuzzt. Die PHP-Kernentwickler hatten das Speicherproblem hinter einer der beiden Lücken sogar schon bei einem Audit 2024 auf dem Schirm und vermuteten, dass es ausnutzbar sein könnte. Nur einen konkreten Angriffsweg fand niemand.

Den fanden erst Maschinen. Im August bestätigten die Sicherheitsfirma Calif und Wiz mithilfe von KI-Modellen – genannt werden OpenAIs GPT-5.6 Sol und Googles Gemini 4 Argon, bei Wiz zusätzlich ein eigener Agent –, dass sich aus dem Fehler tatsächlich eine Remote Code Execution bauen lässt. Die Modelle halfen beim Aufspüren, beim Nachbauen der Angriffe und beim Prüfen der Korrekturen. Was nicht gefunden wird, kann nicht behoben werden. Diesmal wurde gefunden. Das ist die gute Nachricht, und sie ist wirklich gut.

Die Kehrseite: Aus Monaten werden Tage

Die schlechte Nachricht hat Wiz gleich mitgeliefert, wenn auch eher als Werbebotschaft gemeint: Ein einzelner Forscher habe in einer Woche geschafft, wofür früher ein Spezialistenteam Monate brauchte. Eine Methodik zu dieser Schätzung gibt es nicht. Aber man muss kein Prophet sein, um den Satz einmal umzudrehen: Was für die Verteidiger gilt, gilt für die Gegenseite ganz genauso. Die Werkzeuge, die gestern eine Lücke gefunden haben, bauen morgen aus einem frisch veröffentlichten Patch einen funktionierenden Exploit. Patch-Diffing, früher wochenlange Handarbeit für Spezialisten, wird zur Fingerübung für Script-Kiddies.

Wie schnell das inzwischen geht, hat PHP2Shell gleich live vorgeführt. Die koordinierte Offenlegung geriet zur Slapstick-Nummer: Die CVE-Nummern machten bereits am 20. Oktober in sozialen Netzwerken die Runde, das PHP-Team zog das Release daraufhin einen Tag vor, und Calif veröffentlichte versehentlich ein Video mit einem Proof of Concept. Das wurde zwar umgehend wieder gelöscht, aber bis dahin hatte es in einschlägigen Kreisen schon die Runde gemacht.

Das Ergebnis: Die Sicherheitsfirma Hadrian beobachtete massenhafte Angriffsversuche rund zweieinhalb Stunden bevor die gepatchten Versionen überhaupt verfügbar waren. Amazon und Cloudflare berichten ebenfalls von Angriffsverkehr vor der offiziellen Bekanntgabe, und die Angreifer passten ihre Anfragen laufend an, um Web Application Firewalls auszutricksen. Palo Altos Unit 42 schätzt die Zahl der aus dem Netz erreichbaren, potenziell betroffenen Instanzen auf über 22,6 Millionen. Von „wir haben ja noch bis zum nächsten Wartungsfenster“ kann also keine Rede mehr sein.

Warum „gepatcht“ nicht „erledigt“ heißt

Selbst wer am 21. Oktober brav aktualisiert hat, sollte sich nicht zu früh auf die Schulter klopfen. Die Konsequenzen sind heftig, immer noch:

• Ein WordPress-Update hilft nicht. Die Lücke sitzt in PHP, nicht im CMS. Wer stolz auf „alle Plugins aktuell“ verweist, hat am Problem vorbei aktualisiert.
• Altversionen bleiben offen. PHP 8.1 und älter bekommt keine offiziellen Updates mehr. Für 7.4, 8.0 und 8.1 gibt es nur minimale Quellcode-Patches für Leute, die PHP selbst kompilieren. Wer noch irgendwo ein PHP-7.4-Paket bei einem Billighoster laufen hat - und davon gibt es erschreckend viele -, sitzt auf einer offenen Tür.
• PHP steckt auch dort, wo man es nicht vermutet. In Weboberflächen von NAS-Systemen, Routern, Monitoring-Tools, Docker-Images, gebündelt in Fremdsoftware. Die britische NCSC fordert ausdrücklich, auch solche eingebetteten Installationen zu inventarisieren.
• Der Speicher hat geplaudert. Wenn ein Server vor dem Patch angreifbar und erreichbar war, könnten Passwörter, Tokens und API-Schlüssel abgeflossen sein. Der Patch macht sie nicht wieder geheim. Rotieren.
• Der Name ist Programm. PHP2Shell heißt nicht umsonst so. Wer schon drin war, hat sich womöglich eine Webshell oder einen Cronjob hinterlassen. Ein Patch schließt die Tür, er wirft aber niemanden raus, der schon in der guten Stube sitzt.
• Runde zwei kommt bestimmt. Hadrian erwartet weitere Angriffswege. Und mit KI-Unterstützung wird die nächste Variante ganz sicher nicht wieder zehn Jahre auf sich warten lassen.

PHP-Zweig	Abgesicherte Version	Status
8.5	8.5.12	Offizielles Sicherheitsupdate
8.4	8.4.27	Offizielles Sicherheitsupdate
8.3	8.3.36	Offizielles Sicherheitsupdate
8.2	8.2.35	Offizielles Sicherheitsupdate
8.1 / 8.0 / 7.4	keine	Nur minimaler Quellcode-Patch zum Selbstkompilieren – Upgrade dringend empfohlen
7.3 und älter	keine	Kein Patch – Upgrade oder vom Netz nehmen

Was jetzt zu tun ist

1. PHP-Version auf jedem System prüfen – nicht im CMS-Dashboard, sondern auf dem Server selbst (php -v bzw. die tatsächlich vom Webserver genutzte Version).
2. Auf eine der oben genannten Versionen aktualisieren oder beim Hoster nachhaken. Bei Managed Hosting erledigt das der Anbieter, bei vielen Control-Panels muss man die Version selbst umstellen.
3. Eingebettete PHP-Installationen in Geräten und Fremdsoftware inventarisieren.
4. Zugangsdaten, Datenbankpasswörter, API-Keys und Tokens rotieren, wenn das System vor dem Update erreichbar war.
5. Nach Webshells, unbekannten Dateien, neuen Admin-Konten und verdächtigen Cronjobs suchen. Logs ab dem 20. Oktober prüfen.
6. Patch-Prozesse überdenken. „Nächste Woche“ ist das neue „zu spät“.

Wer hat eigentlich den Schlüssel in der Hand?

Bleibt eine Frage, die über PHP hinausgeht. Gefunden haben die Lücken US-Firmen mit den Modellen von US-Konzernen. Nach Angaben des Weißen Hauses war die US-Regierung bereits am Freitag vor der Veröffentlichung informiert. Europäische Betreiber durften sich ihre Informationen derweil zum Teil aus geleakten Social-Media-Posts zusammensuchen. Man muss das nicht dramatisieren, aber man sollte es zur Kenntnis nehmen: Wenn die stärksten Werkzeuge zum Finden von Schwachstellen bei einer Handvoll Konzernen liegen, wird Cybersicherheit zur Frage, wer wann von wem informiert wird. Vertrauen ist schön. Unabhängigkeit wäre schöner.

Und dann ist da noch das PHP-Projekt selbst, dessen Sicherheitsteam nach eigenen Angaben unter strukturellen Problemen und Ressourcenmangel leidet. Ein Fundament, auf dem ein Großteil des Webs steht, wird von wenigen Leuten gepflegt, die jetzt auch noch mit KI-generierten Fehlermeldungen in neuer Taktung zurechtkommen müssen. Wer Milliarden mit Websites verdient, die auf PHP laufen, könnte da ja mal über eine Spende nachdenken. Nur so ein Gedanke.

Kein Heilsbringer, kein Teufelszeug, aber ein Beschleuniger

PHP2Shell taugt weder als KI-Märchen noch als Horrorgeschichte. Die Technik hat eine Lücke gefunden, an der Menschen über zehn Jahre gescheitert sind. Und sie hat gleichzeitig dafür gesorgt, dass zwischen Veröffentlichung und Massenangriff keine Wochen mehr liegen, sondern Stunden oder, wie diesmal, sogar negative Stunden. Wer nur die eine Hälfte sieht, hat das Thema nicht verstanden.

Die Konsequenz für alle, die Websites betreiben oder betreuen, ist unbequem, aber simpel: Updates sind kein Pflegethema mehr, das man irgendwann zwischen zwei Kundenterminen erledigt. Sie sind Brandschutz. Die Server sind gepatcht? Prima. Dann jetzt bitte die Schlüssel tauschen, die Logs lesen und die alte PHP-7.4-Kiste im Keller abschalten. Die nächste Lücke findet nämlich auch wieder eine Maschine. Die Frage ist nur, welche.

27.10.2026