Skizze einer Ziegelmauer mit Tür, an der viele graue Pfeile abprallen, ein roter Pfeil gelangt hindurch, dahinter eine Lupe auf einem Blatt Papier

Wurde PHP2Shell erfolgreich ausgenutzt? Was bisher bekannt ist

25. Oktober 2026

11 Min. Lesezeit

Seit dem 21.10.2026 greifen Unbekannte PHP-Server über PHP2Shell an, die ersten schon vier Tage vorher. Die meisten Versuche scheitern. Einen erfolgreichen Einbruch hat bisher nur ein Sicherheitsanbieter öffentlich beschrieben, und dabei fehlen viele Details. Dieser Ratgeber trennt, was über Angriffsversuche und echte Einbrüche bekannt ist, und welche Meldungen sich nicht bestätigt haben.

Stand: 25.10.2026, 10:16 MEZ. Die Lage ändert sich noch. Wir aktualisieren den Artikel, die Quellen sind jeweils verlinkt.

Wurde PHP2Shell schon erfolgreich ausgenutzt?

Ja, nach Angaben von Palo Alto Networks in mindestens einem Fall. Die Sicherheitsforscher von Unit 42 haben am 23.10.2026 gegen 21:30 MESZ ihren Bericht zu PHP2Shell ergänzt. Darin beschreiben sie einen Angriff auf eine Regierungsstelle in Europa, bei dem die Angreifer bis ins interne Netz vorgedrungen sind.

Alle anderen Quellen, die wir geprüft haben, melden Versuche, aber keinen Erfolg. Dazu gehören Amazon, CrowdStrike, Sophos, VulnCheck und das BSI. Eine Welle erfolgreicher Einbrüche ist bis heute nicht belegt. Das heißt aber nicht, dass es keine gab. Viele Betroffene melden einen Einbruch nicht öffentlich, und Spuren tauchen oft erst Wochen später auf.

PHP2Shell steht für zwei kritische Lücken in PHP selbst, CVE-2026-109618 und CVE-2026-109619. Was dahintersteckt, erklärt der Ratgeber PHP2Shell einfach erklärt.

Was Unit 42 über den ersten Einbruch berichtet

Unit 42 schreibt, die Angreifer hätten zwei Stunden nach der ersten Ausnutzung Passwort-Hashes und Geheimnisse für die Zwei-Faktor-Anmeldung abgegriffen. Danach bauten sie einen NTLM-Relay-Tunnel ins Active Directory auf und versuchten, Rechte als Domain-Administrator zu bekommen. Das Active Directory verwaltet in vielen Organisationen alle Benutzerkonten und Rechner. Aus dem angegriffenen Server wurde so in kurzer Zeit ein Zugang zum internen Netz.

Im selben Bericht beschreibt Unit 42 Angreifer, die nach dem Einbruch Plattformen mit KI-Agenten einsetzten. Die Agenten schickten Befehle über eine Webshell und erkundeten so den übernommenen Server. Welche Rolle KI bei PHP2Shell sonst spielt, steht im Beitrag KI und Sicherheitslücken am Beispiel PHP2Shell.

Vieles lässt der Bericht offen. Unit 42 nennt weder das Land noch die Behörde, kein Datum des Vorfalls und keine Tätergruppe. Indicators of Compromise, also technische Merkmale zum Abgleich, fehlen. Ob der Fall aus einem eigenen Einsatz von Palo Alto Networks stammt, steht nicht im Text. Auch die beiden CVE-Nummern nennt der Bericht an dieser Stelle nicht ausdrücklich als Einstieg. Er spricht von der „initial exploitation“, und der ganze Bericht handelt von PHP2Shell.

Eine zweite, unabhängige Quelle zu diesem Fall haben wir nicht gefunden. Artikel, die ihn erwähnen, fassen den Bericht von Unit 42 zusammen.

Wie viele Angriffsversuche gab es?

Sehr viele, und sie begannen früh. Amazon Threat Intelligence sah den ersten Versuch am 17.10.2026 in seinen Honeypots, vier Tage bevor PHP die Lücken veröffentlichte. In der Nacht und am Morgen des 21.10. folgten weitere Versuche über anonymisierte Infrastruktur. Nach dem Release am Nachmittag tauchten innerhalb von Stunden neue Exploits auf. Amazon spricht von breiten Ausnutzungsversuchen, nennt aber keinen erfolgreichen Angriff.

Zum Umfang zitiert The Hacker News mehrere Anbieter. Cloudflare zählte 45 Minuten nach der Veröffentlichung Zehntausende Versuche, nach zwei Stunden Hunderttausende und am frühen Morgen des 22.10. Millionen. Der Anbieter Previdian sah Hunderte Versuche von Dutzenden IP-Adressen, aber keine erfolgreiche Codeausführung und keine abgelegten PHP-Dateien. Hunt.io zählte 123 angegriffene Server, keiner davon wurde übernommen.

Ein großer Teil der Anfragen ist reines Abtasten. Mehrere Anbieter sahen den User-Agent php2shell-scan, also Werkzeuge, die verwundbare Server suchen. Rechnen Sie damit, dass auch Ihre Website solche Anfragen bekommen hat, wenn sie vor dem Update erreichbar war.

Welche Meldungen haben sich nicht bestätigt?

Sophos meldete am 22.10.2026 um 18:18 MESZ einen erfolgreichen Angriff und nahm die Meldung um 23:21 MESZ zurück. Nach erneuter Prüfung zeigte die Telemetrie nur Scans und wenige gescheiterte Versuche. Der einzige Schadcode, den Angreifer laut Sophos ausliefern wollten, war eine Variante des Botnetzes Mirai mit dem Namen Potassium. Die Schutzregeln von Sophos haben sie blockiert, bevor sie auf ein System kam.

Auch VulnCheck beschreibt einen gescheiterten Versuch. Eine IP-Adresse aus China wollte über den Weg Session Upload Progress eine Webshell ablegen. Alle zehn folgenden Aufrufe der Webshell liefen ins Leere, der Server antwortete mit 404.

Ein Artikel von TechCrunch vom 24.10.2026 nennt neben Palo Alto Networks auch Trail of Bits als Quelle für bestätigte Einbrüche. Eine Veröffentlichung von Trail of Bits zu einem echten Einbruch haben wir nicht gefunden. Berichtet wird nur über einen Exploit, den das Team im Labor gegen MediaWiki gebaut hat.

Viele Behörden haben ihre Websites abgeschaltet, unter anderem in Deutschland, Frankreich, Belgien, Finnland und den Niederlanden. Laut The Register waren in Großbritannien am 22.10.2026 32 Dienste der Regierung nicht erreichbar und vier eingeschränkt. Das war Vorsicht, kein Hinweis auf einen Einbruch. Die britische Regierung wusste an diesem Tag nach eigener Aussage von keiner bestätigten Kompromittierung.

Warum gelingen so wenige Angriffe?

Weil ein zuverlässiger Exploit schwer zu bauen ist. Die Lücken führen zu Speicherfehlern. Damit daraus Codeausführung wird, muss der Angreifer das Speicherlayout genau des Servers treffen, den er angreift. Das hängt von PHP-Version, Erweiterungen, Build und Konfiguration ab. Viele Exploits aus dem Netz bringen den Server nur zum Absturz.

CrowdStrike hält einen universellen Exploit für alle Installationen deshalb für unwahrscheinlich. Gegen bekannte Standard-Setups, etwa ein festes Docker-Image, sei ein Angriff aber machbar. Erscheint ein öffentlicher Exploit, der diese Hürden nimmt, würden ihn laut CrowdStrike sofort viele weitere Angreifer nutzen.

Solche Exploits gibt es inzwischen, aber nicht öffentlich. VulnCheck meldet mit Stand 23.10.2026 einen Exploit, der unter mod_php mit Standard-Einstellungen auf PHP 8.4.10 bis 8.4.26 sowie 8.5.10 und 8.5.11 funktioniert, auch gegen WordPress im Standard-Docker-Image. VulnCheck gibt ihn nur an eigene Kunden heraus. Von den Hunderten Repositorys mit angeblichen Exploits auf GitHub hält VulnCheck nur sehr wenige für echt. Das Werkzeug, das SOCRadar laut The Hacker News auf einem Server von Angreifern fand, zielt ebenfalls nur auf PHP 8.4.26 mit mod_php.

Wie der Speicherfehler technisch zur Codeausführung wird, zeigt der Ratgeber PHP2Shell technisch erklärt.

Was sagen BSI und CISA?

Das BSI schreibt in Version 1.2 seiner Warnung vom 22.10.2026, ihm sei keine erfolgreiche Ausnutzung in der Breite bekannt. Es spricht von unbestätigten Berichten über existierende Exploits und fordert, die Updates sofort einzuspielen. Eine neuere Version der Warnung gab es am Morgen des 25.10.2026 nicht.

Die US-Behörde CISA führt einen Katalog von Lücken, deren Ausnutzung belegt ist, den Known Exploited Vulnerabilities Catalog. PHP2Shell steht mit Stand 25.10.2026 nicht darin. Unabhängig davon hat CISA laut SC Media am 21.10.2026 allen Betreibern von PHP-Websites empfohlen, die Patches sofort einzuspielen.

Was heißt das für Ihre Website?

Dass bisher wenige Einbrüche bekannt sind, ist kein Grund zur Entwarnung. Der Fall bei Unit 42 zeigt, wie schnell aus einer Lücke im Webserver ein Problem für die ganze Organisation wird. Und die Exploits werden besser. Prüfen Sie deshalb drei Dinge:

Läuft auf Ihrem Server eine PHP-Version mit den Korrekturen vom 21.10.2026, also 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder ein Backport Ihrer Distribution? Wie Sie das herausfinden, zeigt die Anleitung zum Prüfen der PHP-Version.
Wurden nach dem Update alle PHP-Prozesse neu gestartet? Ohne Neustart läuft der alte Code weiter.
Gibt es Spuren aus der Zeit vor dem Update? Suchen Sie ab dem 17.10.2026, nicht erst ab dem 21.10. Achten Sie auf unbekannte PHP-Dateien, neue Benutzerkonten und gehäufte Fehler 500 nach Uploads.

Die Befehle für Logs, Prozesse und Dateien stehen auf unserer Seite mit allen Prüfschritten zur PHP2Shell-Sicherheitslücke. Hat der Server Zugriff auf interne Systeme oder ein Active Directory, beziehen Sie Ihre IT-Abteilung ein und ändern Sie die Zugangsdaten, die auf dem Server lagen. Sind personenbezogene Daten betroffen, binden Sie Ihren Datenschutzbeauftragten ein.

Unabhängig von PHP2Shell gibt es seit dem 23.10.2026 eine weitere PHP-Lücke, gegen die noch kein Update existiert. Sie betrifft nur seltene Konfigurationen. Ob Ihre Anwendung dazugehört, zeigt der Ratgeber CVE-2026-115560 prüfen und abstellen.

Wenn Sie Unterstützung brauchen

Wir betreuen als Digitalagentur PHP-Anwendungen, von WordPress und Shopware bis zu eigenen Laravel-Projekten. Bei PHP2Shell prüfen wir den Patch-Stand, starten alle Worker neu und suchen auf dem Server nach Spuren ab dem 17.10.2026. Den Ablauf und die Konditionen finden Sie auf der Seite zur PHP2Shell-Bestandsaufnahme.

Quellen

Häufige Fragen zur Ausnutzung von PHP2Shell

Gibt es bestätigte Einbrüche über PHP2Shell?

Einen öffentlich beschriebenen. Palo Alto Networks Unit 42 hat am 23.10.2026 einen Angriff auf eine Regierungsstelle in Europa beschrieben. Die Angreifer erbeuteten dort Passwort-Hashes und Zwei-Faktor-Geheimnisse. Eine zweite, unabhängige Quelle zu diesem Fall gibt es bisher nicht. Andere Anbieter und das BSI melden nur Versuche.

Seit wann wird PHP2Shell angegriffen?

Seit dem 17.10.2026. An diesem Tag zeichnete ein Honeypot von Amazon den ersten Versuch auf, vier Tage vor der Veröffentlichung der Lücken. Suchen Sie deshalb ab diesem Datum nach Spuren, nicht erst ab dem 21.10.2026.

Gibt es einen öffentlichen Exploit für PHP2Shell?

Es gibt Hunderte angebliche Exploits auf GitHub, aber laut VulnCheck sind nur sehr wenige echt, und die funktionieren nur unter engen Bedingungen. VulnCheck selbst hat einen funktionierenden Exploit für PHP 8.4 und 8.5, gibt ihn aber nur an Kunden heraus. Führen Sie keine Exploit-Skripte aus dem Netz aus, um Ihren Server zu testen.

Warum waren so viele Behördenwebsites offline?

Aus Vorsicht. Viele Behörden in Europa und Großbritannien haben ihre Websites ab dem 21.10.2026 abgeschaltet, bis die Patches eingespielt waren. Ein Einbruch war nach den bisherigen Aussagen der Regierungen nicht der Grund.

Reicht das Update, wenn meine Website angegriffen wurde?

Nein. Ein Update schließt die Lücke, entfernt aber nichts, was ein Angreifer vorher hinterlassen hat. War Ihre Website vor dem Patch erreichbar, prüfen Sie Dateien, Benutzerkonten und Logs ab dem 17.10.2026 und ändern Sie bei Verdacht alle Zugangsdaten.

PHP2Shell: Prüfung & PatchPrüfung, Patch, PHP-Update