PHP2Shell: Das Rennen gegen die Zeit – was die PHP-Lücke für Websites, Geräte und Deine Daten bedeutet

Zwei kritische Fehler in PHP, ein vorzeitig gebrochenes Embargo und Angriffsversuche noch vor der offiziellen Veröffentlichung: PHP2Shell betrifft nicht nur klassische Websites. Die verwundbare Laufzeit kann auch in Firewalls, Hosting-Panels und anderen Geräten stecken. Wir erklären verständlich, was passiert ist, wer handeln muss und was Du als Privatperson wirklich tun solltest.

Am 20. Oktober tauchten zwei zunächst unscheinbare Nummern im Netz auf: CVE-2026-109618 und CVE-2026-109619. Dahinter standen zwei noch nicht vollständig veröffentlichte Schwachstellen in PHP – der Technik, die auf unzähligen Webservern Formulare verarbeitet, Datenbanken abfragt und Seiten erzeugt.

Eigentlich sollte die Offenlegung geordnet ablaufen: erst Updates und vorbereitete Schutzregeln, dann technische Details. Doch die Kennungen wurden vorzeitig bekannt, ein falscher Höchstwert von 10,0 kursierte, und am Abend erschien versehentlich ein Video mit einem funktionierenden Angriff. PHP zog das Release um einen Tag vor.

Zu spät für einen ruhigen Start: Amazon fand später einen Ausnutzungsversuch vom 17. Oktober – vier Tage vor dem Patch. Nach der Veröffentlichung registrierten Anbieter eine rasch wachsende Angriffswelle; Reuters berichtete unter Berufung auf Cloudflare von Millionen Versuchen in wenigen Stunden. Das sind nicht Millionen erfolgreiche Einbrüche, zeigen aber, wie schnell kritische Lücken heute automatisiert getestet werden.

Als Privatperson sitzt die Lücke nicht auf Deinem Smartphone. Sie kann Dich dennoch treffen: über Daten bei einem Anbieter, manipulierte Webseiten, glaubwürdigeres Phishing oder Dienste, die vorsorglich abgeschaltet werden. Dein Gerät kann sauber sein, während Deine Daten auf einem fremden Server gefährdet sind.

Das Wichtigste zuerst

PHP2Shell bezeichnet zwei Speicherfehler im PHP-Kern. Unter geeigneten Bedingungen können Angreifer ohne Anmeldung Code auf einem Server ausführen; eine Lücke kann zusätzlich Speicherinhalte mit Sitzungstokens, Passwörtern, API-Schlüsseln oder Datenbankzugängen offenlegen. Beide CVEs sind mit 9,2 nach CVSS 4.0 bewertet.

Korrigiert sind die Upstream-Zweige ab PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere Zweige erhalten teils Backports von Distributionen, Hostern oder LTS-Anbietern. Ein CMS- oder Plugin-Update allein genügt nicht: Entscheidend ist die PHP-Laufzeit, die Webanfragen tatsächlich verarbeitet.

Privatnutzer installieren nichts auf dem Handy. Betreiber müssen Websites, Container, Verwaltungsoberflächen und Geräte mit PHP inventarisieren, patchen und auf mögliche frühere Angriffe prüfen.

1. Wie aus einem alten Speicherproblem ein weltweiter Wettlauf wurde

2024: Ein Warnsignal ohne nachgewiesenen Angriff

Die Geschichte begann bereits 2024. Bei einem externen PHP-Sicherheitsaudit fielen erste Anzeichen des späteren Out-of-Memory-Problems auf. Ein zuverlässiger Weg von einer Webanfrage zur Codeausführung fehlte jedoch, und mögliche Reparaturen drohten Kompatibilität oder Stabilität zu beeinträchtigen. Das kleine Sicherheitsteam fand keinen schnellen Konsens. Die PHP Foundation bezeichnete die Verzögerung später offen als strukturelles Versagen: Entscheidungswege waren zu schwerfällig, Ressourcen zu knapp.

Sommer 2026: KI-gestützte Forschung macht aus Theorie Praxis

Im Juli und August 2026 untersuchten Calif, OpenAI und Wiz den PHP-Kern mit klassischen Methoden und leistungsfähigen KI-Modellen. Am 11. August wurde ein konkreter Weg zur Remote Code Execution gemeldet; Wiz fand unabhängig weitere Varianten und demonstrierte Angriffsketten gegen reale PHP-Anwendungen. Menschen mussten die Ergebnisse weiterhin reproduzieren, Fehlalarme aussortieren und Patches prüfen. KI verkürzte jedoch die Suche – und damit auch die Zeit, die Verteidigern nach einer Veröffentlichung bleibt.

17. Oktober: Der früheste bekannte Versuch

Amazon Threat Intelligence fand in der MadPot-Telemetrie rückblickend einen Exploitversuch vom 17. Oktober. Ein Honeypot-Treffer beweist keine erfolgreiche Übernahme realer Systeme, verschiebt aber das forensische Suchfenster. Wie der Akteur so früh an ausreichende Informationen kam, ist offen; eine belastbare Zuordnung gibt es nicht.

20. und 21. Oktober: Das Embargo bricht, der Patch erscheint

Am 20. Oktober kursierten die CVE-Kennungen öffentlich, zusammen mit dem falschen CVSS-Wert 10,0 und einem versehentlich veröffentlichten Angriffsvideo. PHP zog das Release auf den 21. Oktober, 14:00 Uhr UTC, vor. Hoster, Distributionen und Sicherheitsanbieter bereiteten parallel Pakete und Filter vor. Cloudflare aktivierte Schutzregeln schon vor dem Release und kombinierte dafür Signale aus Anfrage und Antwort. Dennoch bleibt eine WAF nur eine zusätzliche Barriere: Sie repariert den fehlerhaften PHP-Code nicht.

Am 21. Oktober erschienen die korrigierten Versionen; kurz darauf folgten öffentliche Angriffswerkzeuge und massenhafte Scans. Behörden, Kliniken, Hochschulen und Unternehmen nahmen Angebote vorsorglich vom Netz, darunter zeitweise Polizeidienste in Berlin und Brandenburg. Das ist kein Beweis für einen Einbruch, sondern kann einen funktionierenden Notfallprozess zeigen: lieber kontrolliert offline als unkontrolliert kompromittiert. PHP2Shell macht zugleich deutlich, dass öffentlich erreichbare Systeme bei kritischen RCE-Lücken in Stunden, nicht in Tagen, reagieren müssen.

Gesichert sind zwei kritische PHP-Lücken, aktive Ausnutzungsversuche und eine sehr große potenzielle Angriffsfläche. Unbekannt bleibt, wie viele Systeme tatsächlich kompromittiert wurden oder Daten verloren haben.

2. Was technisch schiefläuft – ohne unnötiges Fachchinesisch

PHP arbeitet im Maschinenraum einer Website: Es führt den Code von WordPress, Shops oder Portalen aus, verarbeitet Eingaben und spricht mit Datenbanken. Die Fehler liegen unterhalb des CMS. Deshalb kann eine vollständig aktuelle Anwendung trotzdem auf einer verwundbaren PHP-Laufzeit stehen.

CVE-2026-109618: Aufräumen mit unvollständigen Daten

Erreicht PHP in einem ungünstigen Moment sein memory_limit, kann die Verarbeitung abbrechen, während interne Datenstrukturen nur teilweise vorbereitet sind. Beim Aufräumen behandelt PHP solche Bereiche unter Umständen wie gültige Daten. Ein Angreifer versucht, diesen Zustand gezielt herbeizuführen und den Speicher so zu beeinflussen, dass daraus Codeausführung entsteht.

Auf Apache mit mod_php wurde ein unauthentifizierter Angriff gezeigt, der vor dem eigentlichen Anwendungscode greifen kann. Login, Zwei-Faktor-Authentifizierung oder ein WordPress-Sicherheitsplugin schützen dann nicht. Auch andere PHP-Betriebsarten können betroffen sein; Voraussetzungen und Zuverlässigkeit unterscheiden sich je nach SAPI, Anwendung und Konfiguration.

CVE-2026-109619: Ein alter Verweis überlebt die nächste Anfrage

Bei der zweiten Lücke bleibt nach einem schweren Fehler ein Verweis auf bereits freigegebenen Speicher bestehen. Bearbeitet derselbe PHP-Worker eine spätere Anfrage, greift er auf diesen alten Zustand zurück – ein Use-after-free beziehungsweise veralteter globaler Zustand.

Folgen können Codeausführung, Abstürze oder Speicherpreisgabe sein. Letztere ist besonders tückisch: Ein Angreifer muss keine sichtbare Webshell hinterlassen, um Sitzungstokens, Datenbankpasswörter, API-Schlüssel oder Zertifikate zu erlangen. Nach dem Patch nur nach veränderten Dateien zu suchen, reicht daher nicht.

Remote Code Execution bedeutet zunächst Codeausführung mit den Rechten des PHP- oder Webserver-Kontos, nicht automatisch Root-Zugriff. Dieses Konto kann jedoch Konfigurationen lesen, Datenbanken erreichen oder interne Dienste ansprechen. Dateirechte, Netzsegmentierung und minimale Privilegien bestimmen daher, wie weit ein Einbruch führt.

3. Sind wirklich fast 70 Prozent des Internets betroffen?

W3Techs weist am 23. Oktober 2026 aus, dass PHP von 69,3 Prozent der Websites verwendet wird, deren serverseitige Programmiersprache der Dienst erkennen kann. Innerhalb dieser PHP-Websites entfallen 65,3 Prozent auf PHP 8, 26,9 Prozent auf PHP 7 und 7,7 Prozent auf PHP 5.

Das beschreibt Verbreitung, nicht den Patchstand oder erfolgreiche Angriffe. Viele Systeme wurden binnen Stunden aktualisiert, Distributionen liefern Backports mit älteren Versionsnummern, und bei Geräten kann der verwundbare Pfad nicht öffentlich erreichbar sein. Die faire Aussage lautet deshalb: Rund sieben von zehn Websites mit identifizierbarer serverseitiger Sprache nutzen PHP und mussten ihren Schutz prüfen. Wie viele heute noch verwundbar oder kompromittiert sind, lässt sich seriös nicht beziffern.

4. Was PHP2Shell für Dich als Privatperson bedeutet

Dein Gerät wird nicht direkt durch PHP infiziert

PHP2Shell läuft auf Servern. Du musst Dein Smartphone nicht zurücksetzen oder eine Spezial-App installieren. Ein Risiko für Dein Gerät entsteht erst, wenn eine manipulierte Website Dich zu einem schädlichen Download verleitet. Halte System, Browser und Apps aktuell und nutze nur vertrauenswürdige Quellen. Ein angebliches „PHP2Shell-Update“ für Dein Gerät ist sehr wahrscheinlich ein Köder.

Deine Daten können trotzdem betroffen sein

Bestellst Du in einem Shop, können dort Name, Adresse und Bestellhistorie lange gespeichert bleiben. Wird der Server kompromittiert, können diese Daten betroffen sein, auch wenn Du die Seite seit Monaten nicht besucht hast. Über die Speicherpreisgabe können zusätzlich Tokens und Zugangsschlüssel sichtbar werden, die nicht als Datei auf dem Server liegen.

Auch eine bekannte Website kann manipuliert werden: Domain und Schloss-Symbol bleiben gleich, während ein eingeschleustes Skript Login- oder Zahlungsdaten abgreift. HTTPS schützt den Weg zum Server, nicht dessen Integrität. Brich bei ungewohnten Zahlungsfenstern, Weiterleitungen oder Downloads ab und kontaktiere den Anbieter über einen bekannten Weg.

Nach dem technischen Angriff kommt oft der Betrug

Gestohlene Details machen Phishing glaubwürdiger. Selbst eine Nachricht mit echtem Namen und korrekter Bestellnummer kann gefälscht sein. Öffne wichtige Dienste über die offizielle App, ein Lesezeichen oder eine selbst eingegebene Adresse. Warnzeichen für eine Kontoübernahme sind unerwartete Login- oder Passwort-Reset-Meldungen, unbekannte Sitzungen, geänderte Wiederherstellungsdaten sowie Push-, TAN- oder Zwei-Faktor-Anfragen, die Du nicht ausgelöst hast. Bestätige nichts „zur Sicherheit“, sondern prüfe das Konto direkt und entferne unbekannte Geräte.

Beim Online-Banking reicht Passwort oder PIN dank starker Kundenauthentifizierung meist nicht allein. Phishing kann Dich aber dazu bringen, eine echte Freigabe für eine fremde Anmeldung oder Zahlung zu bestätigen. Prüfe Empfänger, IBAN und Betrag; bei unbekannten Vorgängen kontaktierst Du die Bank über die offizielle App oder bekannte Nummer.

Was Du jetzt sinnvoll tun kannst

Meldet ein Dienst nur Wartung oder eine vorsorgliche Abschaltung, musst Du weder wahllos Passwörter ändern noch Karten sperren. Nutze einen offiziellen Ersatzweg und beobachte die Mitteilungen des Anbieters.

Meldet ein Anbieter einen möglichen Abfluss von Zugangsdaten, ändere das Passwort dort und überall, wo Du es wiederverwendet hast. Beende aktive Sitzungen, aktiviere Zwei-Faktor-Anmeldung oder Passkeys und sichere besonders Dein E-Mail-Konto.

Hast Du auf einer verdächtigen Seite Daten eingegeben oder eine angebliche Sicherheits-App installiert, sichere Deine Konten von einem anderen Gerät aus, kontaktiere bei Zahlungsdaten die Bank und lasse das betroffene Gerät prüfen.

Keine Sicherheits-App und kein VPN repariert die PHP-Laufzeit eines fremden Shops. Schutzsoftware hilft bei der zweiten Angriffswelle gegen schädliche Downloads, gefälschte Apps und bekannte bösartige Seiten – sie ist aber keine Entwarnung für Daten auf einem fremden Server.

5. PHP steckt auch in Firewalls, NAS-Systemen und anderen Geräten

PHP steckt nicht nur in Websites, sondern auch in Verwaltungsoberflächen und Zusatzdiensten von Firewalls, Routern, NAS-Systemen, Hosting-Panels, VoIP-Anlagen, Kamera-Rekordern oder industriellen Appliances. Betroffen ist ein Produkt aber nur, wenn es eine verwundbare PHP-Version für erreichbare Webanfragen verwendet. Zusätzlich zählen Exposition und Herstellerpatch.

pfSense: Netgate bestätigte die PHP-basierte GUI und das Captive Portal als betroffen. Die Standard-GUI ist meist nur im LAN erreichbar; ein Captive Portal bedient bewusst nicht vertrauenswürdige Clients. Derselbe Fehler hat daher je nach Exposition ein anderes Risiko.

Palo Alto Networks: Bestimmte PAN-OS- und Panorama-Versionen sind betroffen. Laut Hersteller betrifft dies die Management-Weboberfläche einschließlich XML-API, nicht pauschal den Datenpfad oder GlobalProtect. Bis zum Fix sollte die Verwaltung nur aus vertrauenswürdigen Netzen oder über einen kontrollierten Jump Host erreichbar sein.

Plesk: Kunden-Websites nutzen eigene PHP-Handler, die Plesk-Oberfläche eine separate Engine. Wer nur eine Ebene aktualisiert, übersieht möglicherweise die andere. Plesk veröffentlichte daher für beide Komponenten Updates.

Cisco und Sophos zeigen, warum Produkt, Cloud-Dienst und Kundeninstallation getrennt bewertet werden müssen. Cisco bestätigte einzelne Produktfamilien, stufte andere als nicht betroffen ein und untersuchte weitere. Sophos erklärte seine Produkte für nicht betroffen, nahm aber das separat gehostete ältere MyUTM-Portal wegen einer verwundbaren PHP-Version zeitweise offline.

Das niederländische NCSC führt eine laufend aktualisierte Statusliste. Sie ist ein wertvolles Inventar, ersetzt aber nicht das aktuelle Hersteller-Advisory: Eine PHP-Abhängigkeit beweist noch keine Ausnutzbarkeit, eine fehlende Meldung noch keine Entwarnung.

Was Du bei einem Gerät zu Hause oder im Unternehmen prüfen solltest

Notiere Hersteller, Modell, Firmware und Zusatzpakete. Suche auf der offiziellen Supportseite nach beiden CVEs und nach „PHP2Shell“ und installiere Updates nur über die vorgesehene Firmware- oder Paketfunktion. Tausche eingebettetes PHP nie eigenmächtig aus; Appliances enthalten oft Herstelleranpassungen und signierte Komponenten.

Deaktiviere WAN-Fernverwaltung, unnötige Port- und UPnP-Freigaben und prüfe Cloud-Fernzugriffe. Benötigst Du externen Zugriff, nutze möglichst ein VPN und öffne erst danach die lokale Oberfläche.

Trenne Gäste-, IoT- und Managementnetze, damit kompromittierte Geräte keine lokalen Verwaltungsdienste erreichen. Erhält eine Firewall, ein NAS oder ein Kamera-Rekorder keine Sicherheitsupdates mehr, ist Austausch oft die einzige nachhaltige Lösung.

6. Was Betreiber jetzt konkret tun müssen

Schritt 1: Verantwortung und Bestand klären

Bei Managed Hosting aktualisiert meist der Anbieter; bei VPS, Root-Servern, Containern und Appliances bist Du oder Dein Dienstleister verantwortlich. Verlange eine prüfbare Antwort zu beiden CVEs, zur Paket- oder Firmwareversion und zum Neustart aller PHP-Prozesse. Erfasse zugleich Domains, Subdomains, Staging, alte Projekte, Webmail, Container und Geräte mit eingebettetem PHP.

Schritt 2: Den richtigen Patchstand prüfen

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35. Für PHP 7.4, 8.0 und 8.1 stehen Quell-Backports bereit; maßgeblich ist das Advisory des Distributors oder LTS-Anbieters.

Distributionen können Fixes in ältere Paketstände zurückportieren. Ubuntu 24.04 LTS nennt etwa 8.3.6-0ubuntu0.24.04.13 als korrigiert; cPanel lieferte ebenfalls Backports. Vergleiche daher die vollständige Paketversion mit dem Advisory des Distributors oder Plattformanbieters, nicht nur die nackte Upstream-Nummer.

Schritt 3: Die tatsächlich aktive Laufzeit verifizieren

php -v zeigt meist nur die Kommandozeilenversion. Der Webserver kann über PHP-FPM, mod_php oder einen Container eine andere Installation nutzen. Prüfe deshalb FPM-Pools, Webservermodule, virtuelle Hosts und Images:

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

Nach dem Update müssen alte Worker ersetzt werden: bei mod_php typischerweise durch einen Webserver-Neustart, bei PHP-FPM durch den Neustart der Pools. Ein Container-Neustart mit demselben Image hilft nicht; das Image muss aktualisiert und neu ausgerollt werden.

Schritt 4: Unpatchbare Systeme vor PHP stoppen

Kannst Du nicht sofort patchen, beschränke den Zugriff auf vertrauenswürdige Netze oder VPN – oder nimm den Dienst vom Netz. Ein WordPress-Wartungsplugin schützt nicht, wenn der Angriff vor dem Anwendungscode greift. Nutze eine statische Wartungsseite oder sperre am Reverse Proxy, Load Balancer beziehungsweise Webserver.

WAF- und CDN-Regeln können Zeit kaufen, sind aber kein Patch. Cloudflare beobachtete veränderte Angriffsmuster und musste Anfrage und Antwort gemeinsam auswerten. Stelle außerdem sicher, dass der Ursprungsserver nicht über eine zweite IP oder einen alternativen Hostnamen direkt erreichbar ist.

PHP-Konfigurationsmaßnahmen wie das Abschalten des Session-Upload-Progress oder strengere Speicher- und Upload-Grenzen reduzieren nur einzelne Angriffspfade und können Nebenwirkungen haben.

Schritt 5: Mindestens bis zum 17. Oktober zurückblicken

Sichere Webserver-, PHP-, Proxy-, WAF-, System- und Container-Logs, bevor sie rotieren. Suche nach auffälligen Formularanfragen, PHP_SESSION_UPLOAD_PROGRESS, Speicherfehlern, unerwarteten Shell-Prozessen, neuen Dateien, Konten, Cronjobs und ausgehenden Verbindungen. Ein erfolgreicher Angriff muss den Worker nicht abstürzen lassen; umgekehrt beweist ein einzelner Fehler noch keinen Einbruch. Entscheidend ist das Gesamtbild.

Schritt 6: Erreichbare Geheimnisse rotieren

Weil Speicherinhalte offengelegt werden können, solltest Du bei öffentlich erreichbaren, ungepatchten Systemen alle Geheimnisse rotieren, die der PHP-Prozess lesen konnte – etwa Datenbankpasswörter, API-, Cloud- und Deployment-Tokens, SMTP- oder OAuth-Zugänge und Sitzungsschlüssel. Schließe oder isoliere zuerst die Lücke und erzeuge neue Zugangsdaten danach aus einer vertrauenswürdigen Umgebung.

Schritt 7: Bei Einbruchshinweisen nicht nur „aufräumen“

Bei Einbruchshinweisen: System kontrolliert isolieren, Logs und gegebenenfalls flüchtige Daten sichern und kritische Hosts aus vertrauenswürdigen Artefakten neu aufbauen, statt nur sichtbare Dateien zu löschen. Prüfe auch Administrator- und Datenbankkonten, Deployment-Pipelines und verbundene Systeme. Könnten personenbezogene Daten betroffen sein, binde Datenschutzverantwortliche früh ein; eine meldepflichtige Verletzung muss nach DSGVO grundsätzlich binnen 72 Stunden gemeldet werden.

7. Die größere Lehre: Finden wird schneller, Reparieren muss mithalten

PHP2Shell zeigt, wie KI die Grenze zwischen „theoretisch denkbar“ und „praktisch ausnutzbar“ verschiebt. Modelle können Quellcode, Absturzspuren und Patch-Unterschiede in großer Breite analysieren; dadurch wird auch die Zeit zwischen Veröffentlichung und funktionierendem Angriffscode kürzer.

Die Antwort ist nicht allein mehr KI. Maintainer brauchen Ressourcen und klare Entscheidungswege; Betreiber vollständige Inventare, kurze Patchwege, Isolation und geübte Wiederherstellung. Bei Protectstar nutzen wir KI ergänzend zu Code-Reviews und menschlicher Validierung. Sie beschleunigt die Suche, ersetzt aber keine Verantwortung.

Fazit

PHP2Shell trifft Server, kann bei Dir aber als Datenrisiko, Betrugsversuch oder Ausfall ankommen. Handle aufmerksam, nicht panisch: Nutze offizielle Kontaktwege, bestätige keine unerwarteten Freigaben und reagiere gezielt auf Hinweise betroffener Anbieter.

Für Betreiber zählen die aktive PHP-Laufzeit, jede vergessene Instanz, eingebettete Komponenten, der Neustart alter Prozesse und der Blick zurück bis mindestens 17. Oktober. Fehlt ein Patch, ist Isolation verantwortungsvoller als Weiterbetrieb. Eine erreichbare Website ist noch kein Sicherheitsbeweis.