Stand: 24. Oktober 2026. Dieser Beitrag ordnet die Vorgeschichte der PHP2Shell-Lücken ein und stützt sich vor allem auf die Analyse von Mihail Kirov (Tolmo) vom 22. Oktober 2026. Alle Zahlen sind mit ihrer Quelle angegeben.
Kurz gesagt
Der Fehler hinter PHP2Shell war schon 2024 in einem professionellen Audit aufgefallen, wurde aber als harmloser Absturz eingestuft und blieb 26 Monate ungelöst. Im August 2026 machten drei Teams unabhängig voneinander innerhalb weniger Wochen einen funktionierenden Angriff daraus.
Der Code hatte sich nicht verändert, nur die Kosten der Suche. Für Unternehmen heißt das: Jede bekannte, aber aufgeschobene Schwachstelle in Ihren Systemen altert schneller als früher. Der Engpass ist nicht mehr das Finden, sondern das Beheben, und genau dafür fehlen in den meisten Firmen Budget, Zuständigkeit und Fristen.
Über die technische Seite von PHP2Shell haben wir in den letzten Tagen ausführlich geschrieben: welche Versionen betroffen sind, welche Workarounds helfen und wie Sie Angriffsspuren erkennen (PHP2Shell: Was Unternehmen jetzt tun sollten) und wie Sie belegen, dass das Update wirklich wirkt (PHP-Sicherheitsupdate prüfen und nachweisen).
Dieser Beitrag beantwortet eine andere Frage, die sich Geschäftsführer und IT-Leiter stellen sollten: Was lernen wir daraus für unser eigenes Unternehmen? Die Vorgeschichte der Lücke ist dafür lehrreicher als die Lücke selbst. Sie zeigt eine Verschiebung, die nicht nur PHP betrifft, sondern jede Software, die Sie betreiben, und sie stellt Annahmen in Frage, auf denen viele Sicherheitsprozesse im Mittelstand noch beruhen.
Was vor PHP2Shell passiert ist
Mihail Kirov, Sicherheitsforscher bei Tolmo, hat die Vorgeschichte am 22. Oktober 2026 rekonstruiert. Er war früher bei Quarkslab, dem Unternehmen, das 2024 den PHP-Kern auditiert hat. Die wichtigsten Stationen:
- 2024: Im Auftrag des Open Source Technology Improvement Fund (OSTIF), finanziert von der Sovereign Tech Agency, prüft Quarkslab den PHP-Kern. Fünf Personen arbeiten 57 Tage daran. Das Team findet einen Absturz und stuft ihn als Denial of Service ein, also als Fehler, der einen Dienst lahmlegen, aber nicht übernehmen kann. Getestet wird nur unter PHP-FPM. Diese Betriebsart beendet einen abgestürzten Prozess sofort und verdeckt damit, was im Speicher eigentlich passiert. Eine CVE-Nummer wird vergeben, aber nie veröffentlicht. Die Seiten zu den Funden bleiben im Bericht leer, bis eine Korrektur vorliegt. Auf die damals veröffentlichten Ergebnisse sind wir im Beitrag PHP-Sicherheits-Audit 2025 eingegangen. Dieser Fund war naturgemäß nicht darunter.
- 2024 bis 2026: Ein PHP-Kernentwickler sieht laut PHP Foundation früh Anzeichen für ein größeres Problem, kann aber keinen Angriff konstruieren. Jeder Korrekturvorschlag macht etwas anderes kaputt, und das auf Konsens ausgelegte Team trifft keine Entscheidung. Die PHP Foundation nennt die Verzögerung selbst ein "strukturelles Versagen".
- August 2026: Eine Firma meldet einen vollständig funktionierenden Angriff. Am selben Tag meldet eine zweite Organisation unabhängig dieselbe Ursache, zwei Wochen später eine dritte, im September folgen weitere.
- 20. und 21. Oktober 2026: Details gelangen einen Tag vor dem geplanten Termin an die Öffentlichkeit. PHP veröffentlicht außerhalb des regulären Zeitplans ein Notfall-Update. Die beiden Lücken werden mit 9.2 von 10 bewertet und betreffen laut Tolmo jede seit 2012 veröffentlichte PHP-Version.
Besonders aufschlussreich ist, wie klein der Abstand zwischen "harmloser Absturz" und "Server übernehmen" war. Laut Kirov trennten drei Dinge den Fund von 2024 vom späteren Angriff: eine Änderung von drei Zeichen an der Eingabe, 923 Zeichen zusätzliches Füllmaterial und die andere gängige Server-Konfiguration, die nicht Teil des Audits war und den abgestürzten Prozess am Leben hält. Das ist kein Versäumnis der Prüfer, sondern eine Frage des Blickwinkels. Kirov beschreibt es als den Reflex eines Exploit-Entwicklers, den ein Audit mit festem Umfang nicht zwingend hat.
Kein Fall von Nachlässigkeit
Man kann diese Geschichte als Versagen einzelner Personen erzählen. Das wäre bequem, aber falsch. Kirov nennt die Einstufung von 2024 eine vertretbare Triage-Entscheidung, und wir sehen das genauso: Ein Absturz unter PHP-FPM, ohne erkennbaren Weg zur Codeausführung, mit Korrekturen, die Nebenwirkungen haben, landet in jedem Team ehrlicherweise auf der Liste "später". Die PHP Foundation spricht deshalb von einem strukturellen Problem, nicht von einem persönlichen.
Genau das macht den Fall für Unternehmen relevant. Dieselbe Entscheidung wird jeden Tag in Firmen getroffen, nur mit anderen Namen: Der Penetrationstest meldet eine mittlere Schwachstelle, die Korrektur würde ein Release verschieben, also wird sie auf das nächste Quartal gelegt. Daran ist für sich genommen nichts falsch. Problematisch wird es, wenn die Entscheidung kein Ablaufdatum hat und niemand dafür verantwortlich ist, sie erneut zu prüfen.
Die eigentliche Verschiebung: Finden ist billig geworden
Der Kern von Kirovs Analyse ist ein Satz, den wir für die wichtigste Erkenntnis aus PHP2Shell halten: Zwei Jahre nach dem Audit machten drei Teams unabhängig voneinander innerhalb von sechs Wochen aus demselben Fehler einen funktionierenden Angriff. Der Code war derselbe. Verändert hatten sich die Kosten, ihn zu untersuchen.
Die Belege, die Kirov dafür anführt:
- Googles KI-System Big Sleep fand Ende 2024 eine ausnutzbare Lücke in verbreiteter Open-Source-Software und Mitte 2025 eine Lücke, deren Ausnutzung Angreifer bereits vorbereiteten.
- OpenAI stellte Ende 2025 mit Aardvark einen autonomen Agenten für Sicherheitsforschung vor.
- Die Zahl gemeldeter Schwachstellen stieg zwischen 2020 und 2025 um 263 Prozent.
- Die US-amerikanische National Vulnerability Database (NVD) baute einen Rückstau von mehr als 20.000 unbearbeiteten Einträgen auf. Im April 2026 stellte das NIST auf eine risikobasierte Bearbeitung um, bei der die meisten Meldungen nicht mehr mit Zusatzinformationen angereichert werden.
- Kirov selbst brauchte für die Nachanalyse des Fundes 2024 etwa eine Woche, mit heutigen KI-Werkzeugen etwa einen Tag.
Für ein Unternehmen lässt sich das so zusammenfassen: Die Zeit, die ein Angreifer braucht, um aus einem bekannten Fehler einen Angriff zu bauen, schrumpft. Die Zeit, die Ihre Organisation braucht, um einen Fehler zu beheben, schrumpft nicht von allein. Sie hängt an Entwicklerkapazität, Testaufwand, Freigabeprozessen und Wartungsfenstern. Diese Schere öffnet sich, und sie öffnet sich auf der Seite, die Sie selbst steuern können.
Kirov bringt es auf eine Formel, die man sich merken sollte: Ein Fund, der in einer Warteschlange liegt, steht nicht still.
Fünf Annahmen, die auch in Ihrem Unternehmen nicht mehr tragen
Kirov beschreibt fünf Annahmen, auf denen der Umgang mit Schwachstellen bisher beruhte und die PHP2Shell widerlegt hat. Er schreibt sie für Open-Source-Projekte und Sicherheitsforscher. Wir übersetzen sie in den Alltag eines mittelständischen Unternehmens mit eigener Webanwendung, Onlineshop oder Kundenportal.
01"Solange nur wir davon wissen, ist es unser Problem"
Vertraulichkeit setzt voraus, dass niemand sonst denselben Fehler findet. Bei PHP2Shell fanden ihn drei Teams fast gleichzeitig. Im Unternehmen entspricht das dem Pentest-Bericht in der Schublade: Was ein beauftragter Prüfer in Ihrer Anwendung gefunden hat, kann ein automatisiertes Werkzeug heute ebenfalls finden, und zwar mit jedem Jahr günstiger. Ein vertraulicher Bericht schützt Ihren Ruf, nicht Ihre Systeme.
02"Es gibt keinen bekannten Exploit"
Dieser Satz beschreibt laut Kirov nicht den Fehler, sondern den Aufwand, den bisher jemand investiert hat. Und dieser Aufwand wird billiger. Wenn in Ihrer Risikobewertung steht "nicht ausnutzbar, deshalb niedrige Priorität", dann ist das eine Momentaufnahme. Sie gilt für den Tag der Bewertung, nicht für das nächste Jahr.
03"Wir bestimmen, wann es öffentlich wird"
PHP hatte einen Termin. Ein Leak hat ihn um einen Tag vorgezogen, und Hoster und CDN-Anbieter mussten kurzfristig Filterregeln ausrollen. Für Ihr Unternehmen heißt das: Ihr Patch-Zeitplan gehört nicht Ihnen. Wer Sicherheitsupdates nur im monatlichen Wartungsfenster einspielen kann, hat bei einer Lage wie PHP2Shell kein Werkzeug für den Notfall.
04"Eine CVE-Nummer heißt, dass alle Bescheid wissen"
Die CVE von 2024 existierte, war aber nie veröffentlicht und hat damit niemanden gewarnt. Gleichzeitig reichert die NVD die meisten Meldungen inzwischen nicht mehr an. Wer sich darauf verlässt, dass ein Scanner oder eine Datenbank ihn rechtzeitig informiert, hat eine Lücke im eigenen Prozess. Im Unternehmen kommt eine zweite Variante hinzu: Die Warnung ist angekommen, aber im Postfach einer Person, die gerade im Urlaub ist oder das Unternehmen verlassen hat.
05"Das Problem ist, Schwachstellen zu finden"
Viele Sicherheitsbudgets im Mittelstand sind auf das Finden ausgelegt: ein jährlicher Penetrationstest, ein Scanner, ein Audit für den Kunden. Für das Beheben der Ergebnisse gibt es oft keine eigene Position. Die Korrekturen sollen "nebenher" im Tagesgeschäft passieren und konkurrieren dort mit Features, die Umsatz versprechen. Kirov nennt die eigentlichen Engpässe klar: Zeit der Entwickler, finanzierte Behebung und Entscheidungsprozesse, die tatsächlich zu einem Ende kommen.
Liegen bei Ihnen Funde, die nie behoben wurden?
Wir sichten Ihre vorhandenen Pentest-Berichte, Scanner-Ergebnisse und Ticket-Rückstände, bewerten die offenen Punkte nach heutigem Stand neu und sagen Ihnen, was sofort behoben werden sollte und was mit gutem Grund warten kann. Die Korrekturen setzen wir auf Wunsch direkt um.
Security Review anfragenWas das für Budget und Risiko bedeutet
Übersetzt in die Sprache der Geschäftsführung ergeben sich drei Konsequenzen.
Ein Audit ohne Budget für die Behebung ist eine Liste von Risiken mit Datum. Der Bericht dokumentiert, dass Sie von einem Problem wussten. Das ist für die eigene Planung wertvoll, im Schadensfall aber auch ein Beleg dafür, dass ein bekanntes Risiko offen geblieben ist. Wer ein Audit beauftragt, sollte im selben Zug Entwicklerzeit für die Korrekturen einplanen. Kirovs erste Empfehlung lautet entsprechend: für die Behebung bezahlen, nicht nur für den Fund.
Aufgeschobene Funde verlieren ihre Bewertung schneller als früher. Eine Einstufung als "mittel" oder "nicht ausnutzbar" war früher oft über Jahre stabil, weil sich niemand die Mühe machte, das Gegenteil zu beweisen. Diese Mühe ist heute deutlich kleiner. Eine Risikoakzeptanz ohne Ablaufdatum ist deshalb keine Entscheidung mehr, sondern ein Vergessen mit Unterschrift.
Geschwindigkeit beim Patchen ist eine Fähigkeit, keine Reaktion. Ob Ihr Unternehmen ein kritisches Update in Stunden oder in Wochen einspielt, entscheidet sich nicht im Notfall, sondern vorher: an aktuellen PHP-Versionen, automatisierten Tests, einem geübten Ablauf und klaren Zuständigkeiten. Wer auf einer PHP-Version ohne Support läuft, hat diesen Spielraum gar nicht. Für PHP 5.x und 7.0 bis 7.3 gab es bei PHP2Shell keinen Fix.
Für Unternehmen, die unter die NIS2-Richtlinie fallen, kommt eine regulatorische Ebene hinzu. Die Richtlinie zählt das Management und die Offenlegung von Schwachstellen ausdrücklich zu den Risikomanagementmaßnahmen, die umzusetzen sind (Art. 21 Abs. 2 lit. e), und verpflichtet die Leitungsorgane, diese Maßnahmen zu billigen und ihre Umsetzung zu überwachen (Art. 20). Ein Rückstau bekannter, nicht behobener Schwachstellen ohne dokumentierte Entscheidung ist damit auch eine Frage der Leitungsverantwortung. Ob und wie Ihr Unternehmen betroffen ist, beschreiben wir im Beitrag NIS2-Richtlinie: Was Ihr Unternehmen umsetzen muss. Eine Rechtsberatung ersetzt das nicht.
Der Aktionsplan: sieben Maßnahmen für die nächsten 90 Tage
Kirovs Empfehlungen richten sich an Open-Source-Projekte und ihre Geldgeber. Die folgenden Maßnahmen sind unsere Übertragung auf ein Unternehmen, das PHP-Anwendungen betreibt oder betreiben lässt. Keine davon erfordert ein großes Projekt, aber jede braucht einen Namen und ein Datum.
01Inventar aller PHP-Systeme anlegen
Eine Liste aller Systeme mit Zweck, Betriebssystem, PHP-Version, Betriebsart (PHP-FPM, mod_php, Container), Hosting und verantwortlicher Person. Ohne dieses Inventar ist jede weitere Maßnahme Schätzung. Bei PHP2Shell war es der Unterschied zwischen einer Stunde und mehreren Tagen.
02Eine Patch-SLA festlegen
Schriftlich vereinbaren, wie schnell Sicherheitsupdates eingespielt werden, abhängig von Schwere und Erreichbarkeit des Systems. Als Ausgangspunkt empfehlen wir:
| Lage | Unsere Empfehlung |
|---|---|
| Kritisch, aus dem Internet erreichbar, Angriffe bekannt | Innerhalb von 24 Stunden, sonst Übergangsmaßnahme und Isolierung |
| Kritisch, aus dem Internet erreichbar | Innerhalb von 72 Stunden |
| Hoch oder nur intern erreichbar | Innerhalb von 14 Tagen |
| Mittel und niedrig | Im nächsten regulären Wartungsfenster, spätestens nach 90 Tagen neu bewerten |
Die Werte sind ein Vorschlag, keine Norm. Wichtiger als die genaue Zahl ist, dass es überhaupt eine gibt und dass sie auch für Ihren Hoster und Ihre Agentur gilt. Steht sie nicht im Vertrag, existiert sie nicht.
03Jeder aufgeschobene Fund bekommt Ablaufdatum und Verantwortlichen
Das ist Kirovs zweite Empfehlung und aus unserer Sicht die wirksamste. Wenn eine Schwachstelle bewusst nicht sofort behoben wird, wird festgehalten: warum, wer die Entscheidung getroffen hat, wer zuständig ist und bis wann sie erneut bewertet wird. Läuft das Datum ab, geht die Entscheidung automatisch eine Ebene höher. Ein einfaches Ticket mit Fälligkeitsdatum reicht dafür.
04Das Notfall-Update einmal proben
Spielen Sie den Ablauf einmal ohne Not durch: Wer wird informiert, wer darf außerhalb des Wartungsfensters ein Update einspielen, wie wird getestet, wie wird zurückgerollt, wer bestätigt den Erfolg? Eine Probe zeigt fehlende Zugänge, veraltete Kontaktdaten und ungetestete Backups, solange es noch nicht darauf ankommt. Wie Sie den Erfolg eines Updates belegen, beschreibt unser Beitrag PHP-Sicherheitsupdate prüfen und nachweisen.
05Übergangslösungen prüfen statt glauben
Bei PHP2Shell haben viele Hoster und CDN-Anbieter Filterregeln in ihrer Web Application Firewall (WAF) ausgerollt. Laut Tolmo haben diese Regeln funktioniert, aber Kirov betont: Die Aussage eines Anbieters ist kein Nachweis. Tolmo verweist auf das von Matt Suiche veröffentlichte Prüfwerkzeug php2shell_waf_check, mit dem sich von außen prüfen lässt, ob die Regeln Angriffe blockieren. Testen Sie damit nur Systeme, für die Sie berechtigt sind. Und auch eine wirksame WAF ersetzt das Update nicht, sie kauft Zeit.
06Budget für die Behebung reservieren
Planen Sie zu jedem Audit und jedem Penetrationstest ein festes Kontingent an Entwicklerzeit für die Korrekturen ein, bevor der Bericht vorliegt. So muss das Ergebnis nicht erst mit der Produktplanung verhandelt werden. Was eine Prüfung typischerweise kostet, zeigt der Beitrag IT-Sicherheitsprüfung: Kosten und Umfang. Rechnen Sie die Behebung als eigenen Posten dazu.
07Dieselben Werkzeuge für die Verteidigung nutzen
Was Angreifern die Suche erleichtert, beschleunigt auch die Abwehr. Kirov nennt Triage, Patch-Review und Regressionstests. Aus unserer Erfahrung in PHP-Projekten ist der größte Hebel die Testabdeckung: Wer automatisierte Tests für die geschäftskritischen Abläufe hat, kann ein Update in Stunden freigeben, statt tagelang manuell zu prüfen. Werkzeuge helfen beim Finden und Prüfen. Die Entscheidung, was eingespielt wird, bleibt bei Menschen mit Verantwortung.
Vom Fund zur Behebung, mit festen Fristen
Wir prüfen PHP-Anwendungen auf Schwachstellen und beheben sie anschließend auch, statt nur einen Bericht zu übergeben. Im Rahmen von Hosting und Betreuung übernehmen wir Sicherheitsupdates mit vereinbarten Reaktionszeiten. Schreiben Sie uns, welche Systeme Sie betreiben, und wir melden uns innerhalb von 24 Stunden.
Kostenloses Erstgespräch buchenHäufige Fragen
Fazit
PHP2Shell ist weniger eine Geschichte über einen Fehler im Code als über einen Fehler im Prozess. Der Fund war da, die Einstufung war vertretbar, und trotzdem lag er 26 Monate, bis drei Teams ihn innerhalb weniger Wochen in einen Angriff verwandelten. Für Unternehmen ist die Lehre nüchtern: Sicherheit scheitert seltener am Finden als am Beheben. Wer Budget für Korrekturen einplant, aufgeschobene Funde mit Datum und Namen versieht, eine Patch-SLA vereinbart und den Notfall einmal geprobt hat, ist beim nächsten Mal nicht schneller in Panik, sondern schneller fertig.
Sie möchten wissen, wie Ihr Unternehmen dabei aufgestellt ist? Schreiben Sie uns oder buchen Sie ein kostenloses Erstgespräch. Für die akute Lage gibt es unsere PHP2Shell-Checkliste als PDF.
Quellen (Stand 24. Oktober 2026): Mihail Kirov, Tolmo: "We can now find flaws faster than anyone can fix them" (22. Oktober 2026), Release-Ankündigung auf php.net, php2shell_waf_check auf GitHub, Richtlinie (EU) 2022/2555 (NIS2).