PHP ist die unscheinbare Technik hinter fast 70 % aller Websites: Blogs, Webshops, Kundenportale. Am 21. Oktober 2026 waren sie alle für kurze Zeit angreifbar – wer die Lücke php2shell kannte, konnte praktisch jeden PHP-Server übernehmen. Einen Tag zuvor hatte das PHP-Team nur knapp ein Release mit zwei kritischen Sicherheitslücken für 16:00 Uhr angekündigt. Keine Details, nur zweimal 9.2 von 10 möglichen Punkten – in der IT-Sicherheit ungefähr das, was ein Beben der Stärke 9.2 auf der Richterskala ist. In der Nacht auf den 21. Oktober schrieb dann @J4ck3LSyN auf X, er habe die beiden Lücken «successfully recreated & lab/field tested».
Bei insign, wo ich Mitgründer und CTO bin, hiess das: Wir erfuhren den Termin kurzfristig, die Gerüchte klangen düster, und die Hoster kündigten Abschaltungen an. Nichts bringt ein Entwicklerteam so zuverlässig auf Betriebstemperatur wie der Satz «zwei kritische Lücken, Details folgen». Mein Fazit nach diesem Tag: Ohne KI hätten wir Tage gebraucht.
Was steckt hinter php2shell (CVE-2026-109618 und CVE-2026-109619)?
In Zahlen: Laut W3Techs laufen 69,3 % aller Websites mit bekannter Serversprache auf PHP, WordPress allein steckt auf 39,6 % aller Websites. Dazu kommen Webshop-Systeme wie Magento, Shopware oder WooCommerce. Auch Nextcloud, Joomla, Drupal und die Weboberflächen vieler Router und NAS-Geräte laufen mit PHP.
Das Gemeine daran: Die Lücken stecken nicht in einem Plugin oder einer schlampig programmierten Seite, sondern im Kern von PHP. Selbst eine perfekte Website ist verwundbar, wenn darunter ein ungepatchtes PHP läuft. Betroffen sind laut Sansec alle Versionen seit PHP 5.4 (2012), und ein Angreifer braucht keinen Login.
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| Schweregrad | CVSS 9.2 (kritisch) | CVSS 9.2 (kritisch) |
| Technisch | Fehler beim Aufräumen nach einem Speicher-Überlauf | Fehler bei der Verarbeitung von Skriptfehlern |
| Was das bedeutet | Angreifer können fremden Speicher auslesen (Passwörter, Sitzungen) und Code einschleusen | Angreifer können Code einschleusen |
Das Prinzip als Bild: Geht PHP der Arbeitsspeicher aus, bricht es ab und räumt auf. Genau dieses Aufräumen lässt sich aus dem Tritt bringen – die nächste Anfrage betritt sozusagen ein Hotelzimmer, das nach dem Vorgänger nicht gereinigt wurde. Wer geschickt fragt, sieht Dinge, die längst hätten entsorgt sein müssen: Passwörter, Sitzungen, Schlüssel. Wer noch geschickter fragt, kann selbst etwas im Zimmer hinterlassen – etwa eigenen Code, den der Server ausführt. Laut heise genügen einige Tausend bis Zehntausend Anfragen, um die Kontrolle über den Server zu übernehmen. Im Demo-Video der Entdecker von Calif dauert die Übernahme eines Laravel-Servers 38 Sekunden.
Behoben sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
22 Jahre bekannt, nie ernst genommen
Spannender als die Technik ist die Vorgeschichte: Der Kern des Problems ist uralt. Es gab immer wieder Hinweise, aber nie einen funktionierenden Angriff.
| Datum | Ereignis |
|---|---|
| 2004 | Stefan Esser findet die erste PHP-Lücke dieser Art und veröffentlicht bewusst keinen Exploit |
| 2020 | Ein PHP-Bugreport (#78876) beschreibt das Problem, niemand beweist die Ausnutzbarkeit |
| 2024 | Ein Audit von OSTIF und Quarkslab findet eine verwandte Lücke, die Ausnutzbarkeit bleibt unbewiesen |
| 1.–24. Aug. 2026 | Calif und Wiz Research bauen unabhängig voneinander funktionierende Exploits und melden sie an PHP |
| 20. Okt. 2026 | PHP kündigt den Release an, Details leaken, watchTowr bestätigt die Codeausführung |
| 21. Okt., 09:43 Uhr | Cloudflare meldet erste Angriffe und rollt Schutzregeln aus |
| 21. Okt., 16:00 Uhr | PHP veröffentlicht die Updates |
Der Titel verspricht «die Stunde». Streng genommen waren es 14 Jahre verwundbarer Code und ein nervöser Tag zwischen Leak und Patch – aber «die Stunde» klingt besser.
Warum passierte so lange nichts? Weil ein funktionierender Exploit sehr aufwendig war: mehrere Fehler verketten, Speicherlayouts nachbauen, alles pro PHP-Version anpassen. Das war Spezialistenarbeit für Monate. Genau dieser Aufwand war der heimliche Schutz. Sansec bringt es auf den Punkt:
«The underlying bug sat untouched for over a decade. What changed is the cost of weaponizing it.»
KI macht Angriffe billiger
Genau diesen Aufwand senkt KI drastisch. Laut Wiz schaffte eine einzelne Person mit Frontier-Modellen in rund einer Woche, wofür früher ein Spezialistenteam Monate gebraucht hätte. Die Modelle analysierten Fehlschläge und passten den Exploit an verschiedene PHP-Versionen und Anwendungen an. Wiz folgert: Komplexität ist womöglich keine echte Hürde mehr.
Wie das konkret aussieht, beschreibt Calif erfrischend offen. Auf der Suche nach Verwandten eines Bugs von 2004 schreibt der Forscher: «I asked my LLM companion for help.» Nach dem ersten Fund liess das Team die KI das Muster verallgemeinern, denn «the first bug is usually not the best bug, but can be a good indication other juicy bugs hiding nearby». Spezialmodelle brauchte es dafür nach eigener Aussage nicht. Und «know your target» gilt weiterhin. KI ersetzt also keine Fachleute, sie macht sie dramatisch schneller. Calif, Wiz und OpenAI bauten unabhängig voneinander funktionierende Exploits – und alle drei nennen laut Sansec die KI als Grund.
KI schützt: was wir bei insign konkret gemacht haben
insign entwickelt seit 1999 Webprojekte für Schweizer Kunden, heute vermehrt E-Commerce-Lösungen für namhafte, in der Schweiz bekannte Marken. Webshops sind das Paradebeispiel für PHP-Anwendungen: viele Kunden, echtes Geld und null Toleranz für Ausfälle.
Wir waren an diesem Tag nicht allein mit der Hektik. Uberspace nahm PHP-Dienste zeitweise vom Netz, in den Niederlanden gingen unter anderem Tweakers, das Parlament und das nationale Cyber Security Centre vorsorglich offline. Auch Hoster wie Maxcluster, einer unserer grossen Infrastrukturpartner, kündigten kurzfristig an, alle Projekte und damit die Webshops unserer Kunden zu pausieren – bei Maxcluster für rund eine Stunde. PHP-Kernentwicklerin Gina Peter Banyard hielt es laut Sansec schon vor dem Release für die vernünftigste Option, PHP-Server offline zu nehmen.
Und wir? Wir haben KI als Maschinenraum-Crew eingesetzt:
| Aufgabe | Was die KI übernommen hat | Was das bedeutet |
|---|---|---|
| Inventar | Erfassen, welche Projekte auf welchem Server mit welcher PHP-Version laufen | Wir wissen schnell, wo wir stehen |
| Analyse | Prüfen, welche Massnahme zu welcher Umgebung passt | Weniger böse Überraschungen |
| Skripte | Härtung automatisiert für mehrere Server vorbereiten | Parallel statt nacheinander |
| Konfiguration | Die von PHP und Sansec empfohlenen Einstellungen umsetzen | Weniger Tippfehler um 2 Uhr nachts |
| Tests | Prüfen, ob die Shops nach den Änderungen noch funktionieren | Härten ohne Umsatzausfall |
| Kommunikation | Kundeninformationen schnell und verständlich formulieren | Ruhe statt Rätselraten |
Sobald Schwachstelle und Gegenmassnahmen bekannt waren, konnten wir dadurch mehrere Server parallel härten. Rein manuell hätte das Tage gedauert.
Ich will nichts beschönigen: Die Massnahmen laufen noch, und bei älteren Projekten ist der Wechsel auf ein gepatchtes PHP nicht trivial. Die Härtungen sind laut PHP-Team ohnehin nur eine «temporäre Krücke». KI beschleunigt das Handwerk. Entscheidungen und Verantwortung bleiben bei uns. Auch im Grossen arbeiten die Verteidiger mit KI: Calif führte den Code-Audit zusammen mit dem PHP-Team durch, gesponsert von OpenAIs Initiative «Patch the Planet». Wiz und OpenAI halfen laut heise per LLM bei der Prüfung des Patches.
KI sitzt auch auf der anderen Seite
Dieselben Werkzeuge haben auch die Angreifer, und das ist keine Zukunftsmusik: Der Exploit war schon vor dem Release nachgebaut, und Cloudflare sah erste Angriffe um 09:43 Uhr, über sechs Stunden vor der offiziellen Veröffentlichung. Der Angriff braucht Tausende Anfragen und eignet sich laut heise für automatisierte Attacken «à la Heartbleed» – so hiess 2014 die Lücke, die weltweit Millionen Server traf. Wie sich das damals anfühlte, habe ich seinerzeit bei insign beschrieben: «Heartbleed: Wenn das Herz blutet».
Das ist unsere Einschätzung, nicht die der Quellen: Wer mit KI Exploits baut, kann damit auch Patches analysieren, Ziele scannen und Angriffe steuern. Maschinen, die Tausende Anfragen schicken, gegen Menschen, die allein für ein Inventar Tage brauchen: Das ist keine faire Paarung. Das Fenster zwischen Patch und Massenangriff schrumpft von Wochen auf Stunden.
Was Sie jetzt tun sollten
- Hoster fragen: Ist PHP gepatcht, und wann?
- PHP-Version prüfen, auch in Docker-Containern, auf NAS-Geräten und Routern.
- Updaten auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. PHP 8.1 und älter bekommen keine offiziellen Updates mehr, hier helfen nur Backports oder der Umstieg.
- Gegenmassnahmen nur als Überbrückung einsetzen, etwa die Cloudflare-Schutzregeln oder
session.upload_progress.enabled=0. Ein Update ersetzen sie nicht. - Auf Warnzeichen achten: auffällige Datei-Upload-Anfragen, gehäufte Speicherfehler, unerklärliche Neustarts von PHP-Prozessen.
Wer KI im Alltag übt, ist im Ernstfall schneller
php2shell hat gezeigt: Der Aufwand, der Systeme jahrelang geschützt hat, fällt weg. Wer KI-Kompetenz aufbaut, gleicht den Vorsprung aus, den Angreifer sonst gratis bekommen.
Bei Evoya und insign setzen wir KI intensiv in unseren Arbeitsprozessen ein, in Entwicklung, Betrieb und Beratung. Dieser Tag war der Ernstfall. Wir lernen weiter und helfen gerne anderen Firmen dabei. Im 100-Tage-Einführungsprogramm begleiten wir Teams von den Grundlagen über die Vertiefung mit internen AI Champions bis zum Use Case Mining. Nach 100 Tagen arbeitet das Team sicher mit KI, und eigene Champions tragen das Thema weiter.
Mehr zum Thema: KI als Munition – warum Frontier-Modelle wie Waffen behandelt werden, und generative KI-Agenten bei Evoya AI – wie wir KI in unseren Arbeitsprozessen einsetzen.