PHP2Shell: Patch ist da – wird es trotzdem ein Desaster? Das Lagebild

Stand: 22. Oktober 2026, 7:15 Uhr MESZ, nach dem Release. Oben steht, was seit dem Nachmittag neu ist, darunter, was seit dem Release feststeht und was ihr tun solltet. Ganz unten folgt gekürzt das Lagebild vom Vormittag.

Update 22. Oktober, 7:15 Uhr

Amazon schreibt im eigenen Security-Blog, dass seine Honeypots schon am 17. Oktober, vier Tage vor der Veröffentlichung, einen ersten Ausnutzungsversuch registriert haben. Am Release-Tag folgten Versuche mehrerer Akteure; ob einer davon auf echten Systemen funktioniert hätte, ist laut Amazon noch unklar. Trotzdem spricht das Unternehmen von breiter Ausnutzung und rät, Logs mindestens ab dem 17. Oktober zu prüfen. Ein bestätigter erfolgreicher Einbruch ist weiter nicht öffentlich bekannt, und im KEV-Katalog der CISA stehen die Lücken weiterhin nicht. Die PHP Foundation schildert in einem Blogbeitrag, dass erste Anzeichen der Speicherlücke schon 2024 bei der Arbeit an einem Audit auffielen, der Fix aber lange liegen blieb. Sie nennt das selbst ein „strukturelles Versagen“ und bestätigt, dass das Embargo vor dem Release mehrfach brach, zuletzt durch vorab veröffentlichte Chainguard-Images am Morgen des Release-Tags. Plesk hat inzwischen auch das PHP der eigenen Oberfläche gefixt, Amazon Linux und weitere RHEL-Versionen liefern ebenfalls aus. Die SimpleXML-Regression ist dagegen noch nicht behoben.

Update 22:15 Uhr

An der Lage hat sich wenig verändert: Die Lücken stehen weiterhin nicht im KEV-Katalog der CISA, und die Behörde schreibt in ihrer Warnung ausdrücklich, dass sie bislang keine Ausnutzung beobachtet hat. VulnCheck meldet weiter Scans und einen gescheiterten Webshell-Versuch, aber keinen erfolgreichen Einbruch. Plesk hat nachgezogen und bietet jetzt auch unter Windows gefixte PHP-Versionen 8.2 bis 8.5 an, nur das PHP der Plesk-Oberfläche selbst wartet noch auf seinen Hotfix. SUSE liefert für SLES 15 SP7 bereits aus, Fedora und Homebrew ebenfalls. Eine Korrektur zu unserer Aussage von vorhin: Inzwischen ist eine erste Regression in 8.4.27 und 8.5.12 bestätigt. Sie betrifft nur eine sehr spezielle Konstellation mit SimpleXML, ein Fix ist in Arbeit. In den Niederlanden sind DigiD und MijnOverheid wieder erreichbar.

Update 18:20 Uhr

Seit dem Release mehren sich Meldungen über Angriffsversuche. Die Sicherheitsfirma watchTowr führt die Lücken inzwischen als in freier Wildbahn ausgenutzt und stützt sich dabei auf ihr Netz aus Honeypots, also Server, die als Falle aufgestellt sind. Patchstack sah kurz nach dem Release nur tastende Angriffe und noch keinen harten Beleg für Einbrüche. Ein bestätigter erfolgreicher Einbruch ist bis jetzt nicht öffentlich bekannt. Die US-Behörde CISA stuft die Ausnutzung im CVE-Eintrag als „none“ ein, und der niederländische Justizminister sieht laut NOS noch keine Signale für aktiven Missbrauch.

Die Entdecker, die Forschungsteams von Calif und Wiz, haben ihre Analysen veröffentlicht. Laut Wiz lässt sich über die Lücken nicht nur Code ausführen, sondern auch Speicher des PHP-Prozesses auslesen, in dem Passwörter, Tokens und API-Schlüssel stecken können. Auf GitHub tauchen inzwischen Dutzende angebliche Exploits auf. Nach Einschätzung von VulnCheck setzen nur sehr wenige davon den richtigen Mechanismus um, und keiner überwindet auf gängigen x86-Servern von sich aus die üblichen Schutzmechanismen. Rapid7 erwartet allerdings, dass bald ein brauchbarer Exploit öffentlich wird. Darauf solltet ihr nicht warten.

Die Pakete kommen an: Debian und Ubuntu haben Updates veröffentlicht, Ubuntu auch für die alten PHP-7-Pakete im erweiterten Support. Die offiziellen Docker-Images sind aktualisiert, Alpine zieht nach, cPanel liefert Fixes von PHP 7.4 bis 8.5, und Plesk hat die Linux-Pakete für 8.2 bis 8.5. Noch offen sind bei Plesk die Windows-Pakete und die alten Zweige, bei SUSE sind die Pakete noch in der Prüfung. Probleme mit den Updates selbst sind bisher nicht bekannt. In den Niederlanden sind die ersten vorsorglich abgeschalteten Seiten wie RTL und Tweakers wieder online, DigiD.nl war kurz nach 18 Uhr noch nicht erreichbar.

Die Botschaft bleibt dieselbe: Patcht heute.

Was seit dem Release feststeht

Das PHP-Team hat am Nachmittag die angekündigten Updates für die beiden kritischen Lücken CVE-2026-109618 und CVE-2026-109619 veröffentlicht. Die Sicherheitsmeldung auf php.net ist deutlicher als vieles, was am Vormittag zu lesen war: Beide Lücken können es Angreifern ohne Anmeldung erlauben, Code auf dem Server auszuführen, und PHP fordert alle Nutzer auf, sofort zu aktualisieren.

Behoben sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Betroffen sind laut den CVE-Einträgen alle Versionen der unterstützten Zweige davor, laut Wiz ist sogar jede Version ab PHP 5.4 von mindestens einer der beiden betroffen. PHP, das die CVE-Nummern selbst vergibt, bewertet beide Lücken mit 9,2 von 10 Punkten nach CVSS 4.0. Das BSI führt sie als kritisch und hält eine großflächige Ausnutzung innerhalb weniger Stunden für wahrscheinlich.

Gefährdet ist laut PHP jede Installation, die Webanfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt PHP das Risiko bei mod_php ein. Dort gibt es einen nachgewiesenen Exploit, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, bevor überhaupt Code der Anwendung läuft. Sauberer Anwendungscode schützt also nicht. Beide Fehler stecken darin, wie PHP nach einem abgebrochenen Request aufräumt: Bei der einen Lücke geht es um Speicherdaten, die nach einem Out-of-Memory-Abbruch nur halb initialisiert sind, bei der anderen um internen Zustand, der eine Anfrage überlebt und von der nächsten im selben Worker benutzt wird.

Red Hat stuft die Lücken für die eigenen Pakete nur als „Important“ ein, weil RHEL standardmäßig PHP-FPM nutzt und ein Angriff dort in der Praxis schwieriger sei. Das ist eine Einschätzung für eine bestimmte Konfiguration, kein Grund zum Abwarten. Auch Red Hat nennt das Update die einzige vollständige Lösung.

PHP 8.1 und älter bekommen vom PHP-Projekt eigentlich nichts mehr. Wegen der Schwere hat das Sicherheitsteam diesmal trotzdem minimale Backports im Quelltext für 7.4, 8.0 und 8.1 bereitgestellt, gedacht für alle, die selbst kompilieren. Wer PHP aus dem verbreiteten Remi-Repository bezieht, bekommt dort heute laut PHP keine Updates und sollte auf die Pakete der Distribution wechseln oder selbst bauen.

Was hilft, wenn ihr nicht sofort patchen könnt

PHP nennt Maßnahmen für die Zwischenzeit, betont aber, dass sie nur einzelne Angriffswege verbauen. Sicher wird die Installation erst durch das Update. Gegen CVE-2026-109618 rät PHP, memory_limit=-1 so zu setzen, dass Anwendungen es nicht überschreiben können, etwa per php_admin_value, außerdem post_max_size niedrig zu halten und Größenlimits schon am Webserver oder Proxy durchzusetzen. Gegen CVE-2026-109619 hilft session.upload_progress.enabled=0 in der php.ini oder der Pool-Konfiguration, gefolgt von einem Neustart aller Worker, auf PHP 8.5 zusätzlich fatal_error_backtraces=0. Per ini_set() oder .user.ini wirkt das nicht.

Der vielgeteilte Schalter vom Vormittag hilft also gegen eine der beiden Lücken teilweise und gegen die andere gar nicht.

Cloudflare schreibt im eigenen Blog, seine WAF-Regeln seien seit 5:02 Uhr MESZ für alle Kunden aktiv, auch im Gratis-Tarif. Schon vor dem Release habe Cloudflare Angriffsverkehr gesehen, bei dem Angreifer ihre Anfragen umbauten, um die Regeln zu umgehen. Auch Cloudflare rät deshalb, trotzdem zu patchen. Wer einen exponierten Dienst weder patchen noch absichern kann, nimmt ihn vom Netz, so wie es CERT-EU und das FBI empfehlen.

Was vom Vormittag stimmt

Bestätigt: 9,2 nach CVSS 4.0 für beide Lücken. Die am Vormittag gestreuten CVSS 10 waren falsch.
Bestätigt: Die kursierenden Versionsnummern 8.5.12, 8.4.27, 8.3.36 und 8.2.35 stimmen. Ich hatte sie am Vormittag als unbelegt geführt.
Teilweise bestätigt: Session Upload Progress spielt eine Rolle, aber nur bei einer der beiden Lücken und nur auf einem von mehreren Wegen. Der Schalter allein reicht nicht, wie heise und Patchstack schon am Vormittag schrieben.
Bestätigt: Angriffsversuche schon vor dem Patch, Cloudflare beschreibt sie im eigenen Blog. Erfolgreiche Einbrüche sind weiter nicht öffentlich belegt, und im KEV-Katalog der CISA stehen die Lücken noch nicht.
Überholt: Dass nur LiteSpeed-Server im Visier stünden. PHP nennt alle Web-Varianten und sieht das höchste Risiko bei mod_php.
Weitgehend bestätigt: „Ab PHP 5“. PHP selbst nennt keine Untergrenze, Wiz als Mitentdecker spricht von allen Versionen ab PHP 5.4.
Weiter unbelegt: dass der Patch „kompromittiert“ sei.

Wird das ein Desaster?

Seit dem Release ist die erste Frage vom Vormittag im Grunde beantwortet. Die technischen Details stehen offen in den Advisories und den Analysen der Entdecker, und Angreifer probieren bereits. Dass die meisten öffentlichen Exploits noch unausgereift sind, verschafft euch vielleicht Stunden, aber keine Tage. Die Forscher haben Codeausführung ohne Anmeldung unter anderem gegen WordPress, Drupal, Joomla und Magento gezeigt.

Damit hängt alles an der zweiten Frage: wie schnell Hoster, Plattformteams und Distributionen ausrollen. Viele große Anbieter liefern seit dem Nachmittag. Wer eine unterstützte Version und einen aufmerksamen Hoster hat, ist heute Abend durch. Das Risiko bleiben die alten Server mit PHP 7 oder 8.1, um die sich niemand kümmert, und Geräte, in denen PHP mitläuft, etwa Firewalls, NAS-Systeme oder Weboberflächen von Appliances. Für die alten Zweige gibt es jetzt zwar Backports, aber die muss jemand bauen und einspielen. Bei Appliances hängt ihr am Hersteller.

Was jetzt zu tun ist

Spielt heute noch 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 ein, oder das gepatchte Paket eurer Distribution. Startet danach PHP-FPM oder Apache neu, Container müsst ihr neu bauen und ausrollen.
Fangt mit Apache und mod_php an, dort ist das Risiko am höchsten.
Prüft die Version der Website, nicht die der Shell. php -v zeigt nur die Version auf der Kommandozeile. Was die Website wirklich nutzt, zeigen das Hoster-Panel, das Container-Image oder kurz phpinfo(), das ihr danach gleich wieder löscht.
Klärt, wer patcht: wem die PHP-Laufzeit gehört, also Hoster, Plattformteam oder wer das Container-Basisimage pflegt. Bei Shared Hosting fragt ihr beim Hoster nach, bei Appliances beim Hersteller.
Wer auf PHP 8.1 oder älter sitzt, holt sich den Backport von Distribution oder LTS-Anbieter, baut die Quelltext-Backports von PHP selbst oder nimmt die Anwendung vom Netz, bis sie migriert ist.
Wer nicht sofort patchen kann, setzt die Zwischenlösungen von PHP in der Server- oder Pool-Konfiguration um und lässt eine WAF davor. Das überbrückt nur Stunden.
Achtet in den nächsten Tagen auf neue Dateien im Webroot, auf Programme, die PHP plötzlich startet, und auf auffällig viele Fehlerseiten. Wer Spuren findet, behandelt den Server als kompromittiert und tauscht die Zugangsdaten, die darauf liegen.

Ob PHP2Shell ein Desaster wird, entscheidet sich nicht auf X, sondern daran, ob das Update heute Abend auf unseren Servern läuft.

Das Lagebild vom Vormittag (Stand 13:30 Uhr) steht gekürzt darunter, damit nachvollziehbar bleibt, was vor dem Release bekannt war. Was davon inzwischen überholt ist, steht oben unter „Was vom Vormittag stimmt“.

Vormittag: Was feststand

Das PHP-Sicherheitsteam hatte zwei kritische Lücken angekündigt, beide mit 9,2 von 10 Punkten nach CVSS 4.0 bewertet, das Update sollte um 16:00 Uhr MESZ kommen. Welche Versionen und welcher Teil von PHP betroffen sind, wollte PHP erst mit dem Release sagen. Die Sicherheitsfirma watchTowr hatte auf X bestätigt, dass die geleakten Informationen echt sind. CERT-EU riet in seinem Advisory 2026-018, das Patchen vorzubereiten und Anwendungen am Internet notfalls bis zum Fix vom öffentlichen Netz zu isolieren.

Vormittag: Was nur behauptet wurde

Der gelöschte Beitrag, der das Leak auslöste, sprach laut The Hacker News von CVSS 10 und von betroffenen Versionen ab PHP 5. Ein kursierender Proof of Concept ließ sich laut heise security im Labor nicht nachstellen und zielte nur auf den LiteSpeed-Server. Cloudflare-Technikchef Dane Knecht schrieb auf X, seine Firma sehe erste Angriffe, Patchstack meldete, Hosting-Partner hätten aktive Ausnutzung beobachtet. Erfolgreiche Einbrüche waren damit nicht belegt.

Seit dem Mittag nahmen mehrere große Dienste ihre Seiten vorsorglich vom Netz, darunter die Behördenportale DigiD und MijnOverheid, die Website der Tweede Kamer und RTL.nl (NOS). Das zeigte, wie ernst Betreiber die Lücke nehmen, war aber kein Beleg für Einbrüche: Das niederländische NCSC sah keine aktive Ausnutzung.

Wie viele Server betroffen sind, weiß niemand. Mallory zählte laut The Hacker News rund 884.000 Hosts im Netz, deren Banner PHP 8.1 oder älter meldet. Das sind Angaben aus Server-Bannern, keine bestätigt verwundbaren Systeme.