Was passiert ist
Am 21. Oktober veröffentlichte das PHP-Team Notfall-Patches für zwei kritische Lücken in PHP selbst (CVE-2026-109618 und CVE-2026-109619). Über sie lässt sich aus der Ferne und ohne Anmeldung Code auf dem Server ausführen. Angreifer können außerdem Speicher aus PHP-Prozessen auslesen, in dem Passwörter, Tokens und API-Keys liegen können. Die Lücken stecken im Runtime, nicht im Anwendungscode, deshalb waren auch sauber programmierte Anwendungen angreifbar. Betroffen sind fast alle PHP-Versionen zurück bis 5.4.²
„Mit einem einfachen Befehl und einer bestimmten Payload konnte man eine ganze Maschine übernehmen, in dem Fall einen Server.“¹
Die Rolle von KI
Gefunden haben die Lücken Forscher:innen von Calif und Wiz, unterstützt von KI von OpenAI. Wiz bezeichnete sie als die schwersten Lücken, die bisher mit dieser Technologie gefunden wurden.³ Auch beim Ausnutzen half KI: Mit ihr wurden aus den Lücken funktionierende Exploits, und ein Forscher schaffte so in etwa einer Woche, wofür ein Team sonst Monate gebraucht hätte.²
Ein Detail macht nachdenklich: Erste Anzeichen für das zugrunde liegende Speicherproblem tauchten schon bei einem Audit im Jahr 2024 auf, damals ohne erkennbaren Angriffsweg.⁴ Der Fehler war also bekannt, nur nicht als Gefahr. Mit KI wurde aus einem Verdacht in kurzer Zeit ein funktionierender Angriff.
„Mit den neuesten Durchbrüchen in der KI kommen wir Menschen einfach nicht mehr hinterher. KI findet diese Probleme viel besser als wir.“¹
Das Embargo hielt nicht
Eigentlich sollte alles koordiniert ablaufen, doch es kam anders. Amazon registrierte schon am 17. Oktober, also vier Tage vor der Veröffentlichung, einen Angriffsversuch in seinem Honeypot-Netz. Am 20. Oktober veröffentlichte Calif versehentlich ein Video seines Proof of Concept. Am Morgen des 21. Oktober stellte Chainguard gepatchte Images online, mehr als sechs Stunden vor dem offiziellen Termin. Angreifer konnten so aus dem geänderten Code ablesen, wo die Lücke lag.⁴
Viele Organisationen zogen den Stecker
Sicherheitsbehörden wie NSA, CISA, CERT-EU und das britische NCSC rieten, Seiten vom Netz zu nehmen oder in den Wartungsmodus zu schalten, wenn sie nicht sofort gepatcht werden konnten.⁴ Viele Organisationen folgten dem Rat:
- Österreich: Die Universität Wien, die TU Wien, die Niederösterreichischen Nachrichten (NÖN), der OTS-Dienst der APA und die Caritas nahmen ihre Websites vorsorglich offline oder schränkten sie ein.³,⁵ CERT.at gab eine Warnung heraus.³
- Deutschland: Das BSI stufte das Risiko als sehr hoch ein.³ In Niedersachsen und Bremen waren unter anderem das Landesportal niedersachsen.de, die Polizei Niedersachsen, die Medizinische Hochschule Hannover, die Universität Göttingen, bremen.de und die Polizei Bremen nicht wie gewohnt erreichbar. Laut dem Bericht ist allerdings nicht in jedem Fall bestätigt, dass die Ausfälle mit der PHP-Lücke zusammenhängen.⁶
- Belgien: Betroffen waren Websites der flämischen Regierung und des flämischen Parlaments, das belgische Außenministerium, das Centre for Cybersecurity Belgium, die Schulplattform Smartschool, das Spital AZ Monica sowie Seiten der Medienhäuser DPG Media und Roularta.⁷
- Weitere Regierungen: Hunderte Regierungsseiten gingen vom Netz, unter anderem in den Niederlanden, Frankreich, Finnland, Tschechien und Kanada.⁴ In Kanada waren auch die Websites der Montrealer Verkehrsbetriebe STM und der Quebecer Alkoholbehörde SAQ offline.⁸ In Nepal traf es tausende Regierungsseiten, die Nationalbank und mehrere Banken.⁹
- Große Plattformen: Wikimedia, das Internet Archive, die BBC, OpenStreetMap, Duolingo, 4chan und Pinboard schränkten ihren Zugang ein, bis der Patch eingespielt war.⁴
Marketing Cookies erforderlich
Um dieses Video anzusehen, musst du Marketing-Cookies akzeptieren.
Die Tage danach
Mit dem Patch war die Sache nicht erledigt. Laut Cloudflare-CEO Matthew Prince stiegen die Angriffsversuche von Zehntausenden in den ersten 45 Minuten nach der Veröffentlichung auf Millionen. Imperva zählte in den ersten 24 Stunden Angriffe auf knapp 22.000 Websites in 103 Ländern.⁴ Angreifer versuchten unter anderem, eine Variante des Mirai-Botnetzes zu installieren, bisher ohne Erfolg. Einen bestätigten Einbruch gab es bis dahin nicht.¹⁰
Zwei Tage nach den Notfall-Patches meldete PHP eine dritte Lücke (CVE-2026-115560). Sie betrifft nur eine seltene Konfiguration, war aber am 27. Oktober noch nicht behoben.⁴
Das eigentliche Problem: Altlasten
Laut Censys liefen am 26. Oktober noch über 32 Millionen Dienste mit einer betroffenen PHP-Version. Censys merkt an, dass die Zahl eine Obergrenze ist, weil Linux-Distributionen Fixes oft unter alten Versionsnummern nachliefern.⁴ In Nepal konnten mehrere Systeme nicht einfach gepatcht werden, weil sie auf PHP 8.1 oder älter laufen und diese Versionen keine offiziellen Updates mehr bekommen.⁹
„Wenn ich lange nicht aktualisiert habe, bekomme ich vielleicht gar keine Security-Updates mehr. Dann muss ich zuerst funktional aufholen, bevor ich meine Security-Updates überhaupt installieren kann.“¹
Was ihr jetzt tun solltet
- Version prüfen und patchen. Die abgesicherten Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35.² Wer PHP über eine Linux-Distribution bezieht, prüft im Changelog des Pakets, ob die CVEs behoben sind. Die Versionsnummer allein sagt dort wenig aus.
- PHP-Prozesse neu starten. Ein Update wirkt erst, wenn PHP-FPM, Apache und Co. mit der neuen Version laufen.
- Alte Versionen ernst nehmen. Für PHP 7.4, 8.0 und 8.1 gibt es nur Quellcode-Backports, aber keine offiziellen Updates mehr.² Wer dort feststeckt, braucht einen Plan für das Upgrade, nicht nur für diesen Patch.
- Workarounds nur als Überbrückung. Es gibt Konfigurationsänderungen, die das Risiko senken, etwa session.upload_progress.enabled=0. Laut PHP schützt aber nur das Update vollständig.²
- WAF als zusätzliche Schicht. Cloudflare hat schnell Regeln ausgerollt, Angreifer haben ihre Payloads aber angepasst, um sie zu umgehen.² Eine WAF ersetzt kein Update.
- Zugangsdaten prüfen. Weil die Lücken Speicher auslesen können, lohnt es sich bei ungepatcht exponierten Systemen, Passwörter, Tokens und Keys zu rotieren.
Wie wir das bei LEAN-CODERS handhaben
Als PHP2Shell bekannt wurde, haben wir unsere Kund:innen informiert, Updates auf unseren Servern eingespielt und Docker-Images aktualisiert. Für Systeme, die wir nicht selbst betreiben, haben wir Pull Requests vorbereitet, damit die Fixes schnell in Produktion gehen konnten.
Einen Überblick über die anderen Sicherheitslücken der letzten Wochen, von Brotli über Linux bis VS Code, findet ihr in unserem Artikel Neue Qualität, neue Quantität: Wie KI Sicherheitslücken im Wochentakt hervorbringt.
Quellen
¹ Christoph Ott, CEO LEAN-CODERS, im Video-Interview zum Brotli-Bug, Oktober 2026
² The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge, Oktober 2026
³ ORF: Gravierende Sicherheitslücken in PHP, 21.10.2026
⁴ TechTarget: PHP2Shell explained: Timeline of the global vulnerability crisis, Oktober 2026
⁵ MeinBezirk.at: NÖN, OTS und weitere Websites offline, 21.10.2026
⁶ leinetal24: Nach Internetwarnung: Webseiten in Niedersachsen und Bremen offline, 21.10.2026
⁷ The Brussels Times: Major websites go offline as critical PHP vulnerability triggers security fears, Oktober 2026
⁸ CP24: Canadian apps and government websites go offline to ward off online danger, 21.10.2026
⁹ The Kathmandu Post: PHP2Shell security flaw forces thousands of Nepali websites offline, 25.10.2026
¹⁰ The Hacker News: PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches, Oktober 2026
Läuft bei euch noch PHP 8.1 oder älter, oder ihr seid nicht sicher, welche Version im Einsatz ist?