D Lücke isch im PHP gsi, nöd im Plugin
Zwei kritische Lücken im PHP-Interpreter haben am 21. Oktober weltweit Websites offline geschickt, auch in der Schweiz. Was wirklich passiert ist, was belegt ist und was ein KMU jetzt prüfen muss
Am Abend des 21. Oktober waren die Websites der Universität Genf, der EPFL und des Kantons Basel-Stadt nicht erreichbar. Jobs.ch war weg. Der grösste Schweizer Webhoster cyon schaltete um 15:45 Uhr über 100’000 Kundenwebsites ab und brachte sie erst am nächsten Morgen um vier Uhr zurück.
Niemand war angegriffen worden. Alle hatten dasselbe gelesen.
Was ist php2shell genau?
Es sind zwei Lücken im PHP-Interpreter selbst, CVE-2026-109618 und CVE-2026-109619, beide mit dem Schweregrad 9.2 von 10. Ein Angreifer kann ohne Anmeldung eigenen Code auf dem Server ausführen. Betroffen ist nicht ein Plugin, ein CMS oder ein Framework, sondern die Schicht darunter, auf der all das läuft.
Das ist der Grund, warum die Reaktion so breit ausfiel. Das PHP-Projekt schreibt in seiner Mitteilung, betroffen seien alle PHP-Installationen, die Webanfragen beantworten, und stuft Apache mit mod_php als höchstes Risiko ein, weil der Angriff ausgelöst werden kann, bevor überhaupt Anwendungscode läuft. Nach Zahlen von W3Techs laufen rund 69 Prozent aller Websites mit bekannter Serversprache auf PHP.
Gefunden hat die Lücken Calif Research. Der Entdecker beschreibt in seiner Analyse selbst, dass er dabei ein Sprachmodell und einen Coding-Agenten eingesetzt hat, hält aber ausdrücklich fest, es sei kein besonderer Aufbau und kein nicht-öffentliches Modell im Spiel gewesen. Die kursierende Schlagzeile, KI habe die Lücke gefunden, die 70 Prozent des Internets lahmlegen könne, mischt zwei Dinge: Die 70 Prozent sind der Marktanteil von PHP, nicht der Anteil verwundbarer Systeme.
Wie schlimm ist es wirklich geworden?
Es gab sehr viele Versuche und sehr wenige belegte Erfolge. GreyNoise zählte bis zum 1. November 213’337 Ausnutzungsversuche von 509 verschiedenen Angreifer-Adressen, und 1’177 bestätigte erfolgreiche Übernahmen, die von gerade einmal fünf Adressen ausgingen und sich gegen absichtlich verwundbare Messsysteme richteten.
Das ist der Unterschied, der in den Schlagzeilen regelmässig verlorengeht. Massenhafte Angriffsversuche heisst nicht massenhafte Kompromittierung. Wordfence hielt am 28. Oktober fest, man kenne keine über php2shell kompromittierte WordPress-Seite.
Belegt ist bisher dreierlei an tatsächlichem Missbrauch: ein Botnetz namens Potassium, eine Mirai-Variante, die übernommene Server für Überlastungsangriffe einspannt. Eine gezielte Kampagne, bei der ein Angreifer die PHP-Lücke mit einer Linux-Kernel-Lücke verkettete und 24 Firewalls eines Herstellers übernahm, in 22 Fällen nur, um eine Hintertür für später zu hinterlegen. Und eine Forschungsdemonstration, die zeigt, dass die Lücke Passwörter und Schlüssel aus fremden Anfragen sichtbar machen kann.
Die Zeitachse
| Datum | Was passierte |
|---|---|
| 11. August 2026 | Calif meldet die erste Lücke an das PHP-Projekt |
| 17. Oktober | Erster Angriffsversuch gegen einen Amazon-Honeypot, vier Tage vor der Veröffentlichung |
| 20. Oktober | Vorankündigung durch php.net, die CVE-Nummern sickern vorab durch |
| 21. Oktober, 14:00 UTC | Patches und Advisory, vorgezogen wegen des Lecks |
| 21. Oktober | Warnung des Bundesamts für Cybersicherheit, erste Abschaltungen in der Schweiz |
| 24. Oktober | Erste technisch dokumentierte erfolgreiche Ausnutzung, auf Honeypots |
| 26. Oktober | Die US-Behörde CISA nimmt beide Lücken in den Katalog aktiv ausgenutzter Schwachstellen auf |
Bemerkenswert ist der 17. Oktober. Jemand hat die Lücke vier Tage vor der Veröffentlichung angegriffen. Amazon schreibt dazu, es sei unklar, wie der Akteur an die Informationen kam.
Was ist in der Schweiz passiert?
Offiziell: nichts Bestätigtes. Das Bundesamt für Cybersicherheit publizierte am 21. Oktober eine Warnung und sagte der Nachrichtenagentur Keystone-SDA am Folgetag, es seien keine Angriffe in der Schweiz bekannt, man schliesse unerkannte oder nicht gemeldete Vorfälle aber nicht aus. Es gebe keine verlässlichen Zahlen zu betroffenen Websites, Onlineshops oder internen Anwendungen.
Ein Detail daraus ist untergegangen: PHP-basierte Anwendungen in der Bundesverwaltung waren betroffen. Das Bundesamt konnte nicht sagen, welche, und hatte keinen vollständigen Überblick über den Patchstand.
Der ehrlichste Fall ist der von cyon. Der Hoster hat öffentlich aufgeschrieben, warum er abgeschaltet hat: Zehntausende der betroffenen Websites liefen auf PHP 7.4, 8.0 oder 8.1, also auf Versionen, für die es gar kein reguläres Update gab, sondern nur Quelltext-Korrekturen. cyon musste auf getestete Pakete eines Drittanbieters warten, die später kamen als angekündigt. Teillösungen wie Konfigurationsänderungen oder Firewall-Regeln verwarf cyon ausdrücklich, weil sie nur einzelne Angriffspfade schliessen.
Vorsicht bei den Schweizer Zahlen
In den Medien kursierten vier verschiedene Zahlen betroffener Schweizer Server: 31’386, rund 23’000, 54’229 und 54’246. Alle stammen von derselben Quelle, einem österreichischen Monitoring-Dienst, und sie widersprechen sich.
Der Grund steht auf der Seite des Anbieters selbst. Gemessen wird passiv, über die Versionsangabe im Antwort-Header beim Aufruf der Startseite. Wer seine Version nicht anzeigt, wird nicht gezählt. Und, das ist der entscheidende Punkt: Linux-Distributionen pflegen Sicherheitskorrekturen in alte Versionsnummern zurück. Ein Server, der sich als PHP 8.1 meldet, kann längst korrigiert sein. Das Bundesamt weist in seiner Warnung ausdrücklich darauf hin, dass die Paketversion zählt und nicht die PHP-Hauptversion.
Für die Schweiz gibt es also keine belastbare Zahl. Das ist kein Versäumnis der Medien, das sagt das Bundesamt selbst.
Was heisst das für Ihr KMU?
Das Bundesamt für Cybersicherheit nennt sieben Schritte. Hier in der Reihenfolge, in der sie für einen kleinen Betrieb Sinn ergeben.
- Fragen Sie Ihren Hoster schriftlich nach einer Bestätigung. Nicht ob gepatcht wurde, sondern wann, und für welche PHP-Versionen. Wer wie cyon öffentlich Rechenschaft abgelegt hat, hat die Frage schon beantwortet.
- Machen Sie ein Inventar. PHP steckt nicht nur in der Website. Es steckt in Administrationsoberflächen, in internen Werkzeugen, in Hosting-Plattformen, in Containern und in Geräten mit Weboberfläche. Das Bundesamt nennt ausdrücklich auch eingebettete Komponenten und extern betriebene Anwendungen.
- Priorisieren Sie nach Exponierung. Zuerst alles, was aus dem Internet erreichbar ist und sensible Daten verarbeitet.
- Fragen Sie Ihre Softwarelieferanten. Wer eine Branchenlösung einsetzt, muss wissen, ob sie PHP enthält. Das weiss der Betrieb meistens nicht, der Lieferant schon.
- Starten Sie die Dienste nach dem Update neu. Ein aktualisiertes Paket korrigiert keinen laufenden Prozess. Container müssen neu gebaut und ausgerollt werden.
- Prüfen Sie, welche Version wirklich läuft. Nicht welche installiert ist.
- Schauen Sie in die Protokolle. Ein Update entfernt eine bereits bestehende Kompromittierung nicht. Amazon empfiehlt, Untersuchungen mindestens bis zum 17. Oktober zurückzuführen.
Wer nicht sofort aktualisieren kann: Das Bundesamt nennt Zwischenmassnahmen, betont aber, dass diese nur einzelne Angriffspfade schliessen und eine Firewall vor der Anwendung allein nicht genügt.
Was dieser Vorfall eigentlich zeigt
Die Angriffswelle ist nicht die Geschichte. Die Geschichte ist der Versionsstand.
Qualys fand bei einer Erhebung am 22. Oktober rund 167 Millionen PHP-Installationen, 73 Prozent davon auf Systemen, die aus dem Internet erreichbar sind. 71 Prozent liefen auf Versionszweigen zwischen 5.4 und 8.1, für die es vom PHP-Projekt gar kein Update mehr gibt. Das heisst: Die Mehrheit der betroffenen Systeme hätte auch bei perfekter Reaktion kein reguläres Update bekommen.
Dazu kommt ein Eingeständnis, das in der Aufregung unterging. Das PHP-Projekt schreibt in seinem eigenen Blog, es habe bereits 2024 Hinweise auf das Problem gehabt, man habe sich nicht auf eine Lösung einigen können, die Arbeit sei liegengeblieben. Das Projekt nennt das selbst ein strukturelles Versagen und führt Ressourcenmangel als Ursache an.
PHP wird von Freiwilligen und einer kleinen Stiftung gepflegt und trägt zwei von drei Websites der Welt. Wer über Abhängigkeiten im eigenen Betrieb nachdenkt, findet hier ein konkreteres Beispiel als in jeder Risikomatrix. Wie wenig Schweizer KMU organisatorisch für solche Fälle aufgestellt sind, zeigte kürzlich die Studie zur KMU-Cybersicherheit: Technisch ordentlich, organisatorisch dünn.
Der Satz zum Mitnehmen
Die Frage ist nicht, ob Sie angegriffen wurden. Die Frage ist, ob Sie wissen, wo überall PHP in Ihrem Betrieb läuft und wer es aktualisiert.
Quellen
- PHP-Projekt, Security Advisory vom 21. Oktober 2026: php.net
- Bundesamt für Cybersicherheit, Warnung vom 21. Oktober 2026: bacs.admin.ch
- Calif Research, technische Analyse php2shell: calif.io
- GreyNoise, laufender Zähler der Angriffsaktivität: php.events.greynoise.io
- Qualys, Risikoeinschätzung vom 22. Oktober 2026: qualys.com
- Amazon Threat Intelligence, Ausnutzung vor der Veröffentlichung: aws.amazon.com
- cyon, «php2shell: Warum wir vom Netz gingen», 23. Oktober 2026: cyon.ch
- Rapid7, technische Einordnung: rapid7.com
- SRF zur Lage in der Schweiz, 21. Oktober 2026: srf.ch
- Keystone-SDA über die Auskunft des Bundesamts, 22. Oktober 2026: watson.ch
- inside-it.ch zu den bestätigten Angriffen, 26. Oktober 2026: inside-it.ch
