Zwischen C-Archäologie, Behörden-Panik und der Frage: Where do we land?

Die Server laufen, die Caches kühlen langsam wieder ab, und in den DevOps-Slacks weicht das Adrenalin der gepflegten Nachbetrachtung. 24 Stunden nach dem wohl lautesten PHP-Drama der letzten Jahre ist der Rauch verzogen.

Was bleibt von PHP2Shell übrig, wenn man das grelle ASCII-Blinken, die hysterischen CERT-Sirenen und die voreilig gezogenen Not-Aus-Schalter wegrechnet? Ein faszinierender, fast schon absurder Blick in die Eingeweide des Webs – und ein paar unbequeme Wahrheiten darüber, wer im Ernstfall die Nerven behält und wer lieber das Licht ausknipst.

Zeit für eine Bestandsaufnahme: Where do we land?

Der Mythos Rasmus: Stoizismus schlägt Social-Media-Theater

Während auf X (ehemals Twitter) und Mastodon die Apokalypse ausgerufen wurde, war es an einer Stelle verdächtig still: bei Rasmus Lerdorf.

Kein Drama-Thread, kein philosophischer Rundumschlag. Wer Rasmus kennt, weiß: Der Erfinder von PHP hat das Ganze wohl mit dem für ihn typischen, lakonischen Grinsen zur Kenntnis genommen. 1994 wollte der Mann doch eigentlich nur seine persönliche Homepage mit ein paar Perl-Skripten und C-Snippets verwalten. Dass sich die Menschheit dreißig Jahre später kollektiv in die Hose macht, weil zwei C-Pointer in der Zend Engine bei Out-of-Memory-Zuständen nicht sauber aufgeräumt werden, ist der ultimative Treppenwitz der Softwaregeschichte.

Ich hatte Rasmus Lerdorf im Interview für den goneo Podcast, lange her (ab Minute 12, 31 Sekunden) im August 2018 in einer Welt vor KI.

Während die Szene rotierte, wussten die Veteranen: PHP stirbt nicht an zwei CVEs. Es überlebt seit drei Jahrzehnten das Internet – und wird auch die nächsten zehn RCE-Kandidaten überstehen.

Das Beichten der PHP Foundation: Bürokratie-Deadlock statt Hacker-Zauber

Die eigentliche Sensation lieferte die PHP Foundation in ihrem bemerkenswert ehrlichen Post-Mortem: Hinter den Kulissen war nicht etwa ein genialer Zero-Day-Superschurke am Werk, sondern das älteste Übel der Open-Source-Welt – Paralyse durch Konsenszwang.

Die OOM-Problematik (Out of Memory) war dem Core-Team nämlich schon seit 2024 bekannt (entdeckt im Rahmen eines durch die Sovereign Tech Agency und OSTIF geförderten Audits von Quarkslab). Warum hat es dann bis Ende 2026 gedauert? Weil sich das Security-Team intern im Kreis drehte:

• Jeder Fix-Entwurf hatte Haken: bricht man Extensions? Riskeirt man neue DoS-Lücken?
• Weil man zwingend Einstimmigkeit suchte und Angst vor der falschen Entscheidung hatte, blieb der Patch monatelang in der Schublade liegen – bis im August gleich mehrere Researcher (unter anderem von Wiz und OpenAI) unabhängig voneinander den Finger exakt in diese Wunde legten.

Die Foundation bezeichnete das völlig ungeschminkt als „strukturelles Versagen“. Die Konsequenz für die Zukunft? Das Einstimmigkeitsprinzip wird beerdigt. Künftig gilt im Security-Team: Mehrheitsentscheid. Man riskiert lieber eine unpopuläre Entscheidung, als das Web wegen interner Deadlocks monatelang auf einer offenen Flanke sitzen zu lassen.

Und Zend (Perforce)? Die nutzten das Chaos eher gewohnt geschäftsmäßig: Während die Open-Source-Gemeinde schwitzte, flatterten die Sales-Pitches für ZendPHP Enterprise LTS-Support in die Postfächer. Business as usual.

Die C-Archäologie: Warum PHP 8.5 jetzt den großen Besen braucht

Die Notfall-Patches (8.2.35, 8.3.36, 8.4.27) waren chirurgische Pflaster. Aber der Schock sitzt tief genug, dass die Engine-Entwickler für PHP 8.5 jetzt an die Fundamente müssen:

1. Weg mit longjmp(): In modernem C hat rabiates Stack-Zurückspringen wie in den 80ern nichts mehr zu suchen. Wer mitten im Multipart-Stream ein Out-of-Memory wirft, muss saubere Return-Codes liefern, statt den globalen Speicherzustand als brennende Ruine zu hinterlassen.
2. Kapselung des Request-Parsers: Eingehende Datenströme gehören in eine isolierte Sandbox. Erst wenn der Request valide im RAM liegt, darf er an die Zend-Globals übergeben werden.
3. Alte Zöpfe abschneiden: Features wie session.upload_progress stammen aus einer Zeit, in der Browser noch keinen nativen Upload-Fortschritt kannten. Wer braucht das heute noch im PHP-Core? Richtig: fast niemand mehr. Es wird Zeit für radikales Ausmisten.

The Big Picture: Der feine Unterschied zwischen Panik und Handwerk

Und wo landen wir operativ?

Wenn der Staub sich legt, sieht man die Reifegrade der Branche schonungslos offenliegen:

• Auf der einen Seite die Behörden-Bürokratie, die wie ein hyperaktiver Wetterdienst schon bei der ersten Kumuluswolke empfiehlt, den Keller nicht mehr zu verlassen („Isolieren Sie Webserver vom Internet!“).
• Dazwischen jene Hoster, die den Not-Aus-Schalter drückten und zehntausende Kunden-Websites, Agenturprojekte und Onlineshops eigenmächtig in den Wartungsmodus kickten. Man kann es drehen und wenden, wie man will: Den Kunden abzuschalten, um das eigene theoretische Risiko auf null zu setzen, ist kein guter Service.
• Und auf der anderen Seite die Pragmatiker: Hyperscaler, Masshoster– und wir bei goneo. Wo andere Stecker zogen, haben Admins WAF-Filter justiert, Parser-Angriffsflächen minimiert und im laufenden Betrieb sauber die Pakete ausgerollt.

Where do we land?

Wir landen bei einer alten Weisheit, die im Cloud-Zeitalter gern vergessen wird: Echte Resilienz beweist sich nicht darin, wer im Panikfall am schnellsten den Raum verlässt und das Licht ausschaltet. Echte Resilienz beweist sich darin, Systeme so zu bauen, dass sie auch dann erreichbar bleiben, wenn im C-Code der Keller brennt.

PHP ist nicht tot. Die Community hat aufgeräumt. Und die Webseiten unserer Kunden waren die ganze Zeit genau da, wo sie hingehören: online.