PHP2Shell: Kritische PHP-Sicherheitslücke – was Hoster und Website-Betreiber jetzt tun

Zwei kritische Schwachstellen in PHP zwingen Hostinganbieter seit dem 21. Oktober 2026 zu Notfallmaßnahmen. Die unter dem Namen PHP2Shell bekannten Sicherheitslücken können im schlimmsten Fall die Ausführung fremden Codes auf einem Server ermöglichen – ohne Anmeldung am betroffenen System. Das trifft nicht nur veraltete WordPress-Installationen, sondern auch aktuelle Websites, Shops und selbst entwickelte PHP-Anwendungen. Die guten Nachrichten: Seit heute sind offizielle Sicherheitsupdates verfügbar. Die weniger guten: Bis sie auf jedem Server installiert sind, können Betreiber mit Ausfällen, deaktivierten Uploads und blockierten Formularen konfrontiert werden.

Die beiden Kennungen lauten CVE-2026-109618 und CVE-2026-109619, beide haben einen Schweregrad von 9,2 nach CVSS 4.0. Die Warnung betrifft die PHP-Laufzeitumgebung selbst, nicht etwa eine einzelne Erweiterung. Genau das unterscheidet den Vorfall von vielen üblichen WordPress-Sicherheitslücken. Das PHP-Projekt und europäische Sicherheitsbehörden fordern dringende Aktualisierungen.

Die wichtigste Information: Diese PHP-Versionen schließen die Lücken

PHP-Zweig	Erforderliche korrigierte Version	Hinweis
PHP 8.5	8.5.12 oder neuer	Offizielles Sicherheitsrelease vom 21.10.2026
PHP 8.4	8.4.27 oder neuer	Offizielles Sicherheitsrelease vom 21.10.2026
PHP 8.3	8.3.36 oder neuer	Offizielles Sicherheitsrelease vom 21.10.2026
PHP 8.2	8.2.35 oder neuer	Supportende bereits am 31.12.2026
PHP 8.1 und älter	Kein Patch direkt vom PHP-Projekt	Nur mit bestätigtem Hersteller-/LTS-Backport oder Migration absicherbar

Die Entwickler betonen ausdrücklich: Es gibt keine vollständige Ersatzmaßnahme für den Patch. Ein korrekt konfigurierter Webfilter, ein deaktivierter Upload-Fortschritt oder ein gehärteter Server können die Angriffsfläche verringern. Sie reparieren aber den zugrunde liegenden Speicherfehler nicht. Wer einen eigenen Server betreibt, muss aktualisieren; bei klassischem Webhosting ist in erster Linie der Hoster zuständig. Auch alle parallel installierten PHP-Versionen und noch laufende PHP-Prozesse müssen berücksichtigt werden.

Was hinter PHP2Shell steckt – und warum WordPress-Updates nicht reichen

PHP verarbeitet Anfragen, bevor ein CMS überhaupt seine eigentliche Arbeit erledigen kann. Die beiden Fehler betreffen den Umgang mit Arbeitsspeicher, insbesondere bei ungewöhnlichen Fehlerzuständen: Bei CVE-2026-109618 können unvollständig initialisierte Daten nach einem Speichermangel fehlerhaft weiterverarbeitet werden. Bei CVE-2026-109619 kann ein PHP-Worker noch auf Daten aus einer vorherigen Anfrage zugreifen, obwohl deren Speicher bereits freigegeben wurde. Solche Zustände können zu Abstürzen, der Offenlegung von Informationen oder der Ausführung eingeschleusten Codes führen. Google Cloud und Cloudflare beschreiben die Ursachen anhand der Speicher- und Request-Verarbeitung.

Besonders heikel ist laut offizieller PHP-Warnung ein nachgewiesener Angriffsweg bei Apache mit mod_php, bei dem eine präparierte Anfrage den Fehler bereits vor dem Start des Anwendungscodes auslösen kann. Auch PHP-FPM, CGI, LiteSpeed und eingebettete PHP-Laufzeiten werden als gefährdet eingestuft; der konkrete Angriffsweg und das praktische Risiko unterscheiden sich je nach Betriebsart und Konfiguration. Eine Aussage wie „Meine WordPress-Version ist aktuell, also bin ich sicher“ greift deshalb zu kurz. Ein Sicherheitsplugin kann einen Fehler im PHP-Interpreter nicht wegpatchen.

Wie Hoster reagieren: Abschalten, Uploads sperren oder schnell patchen

Die Reaktion der Hoster fällt unterschiedlich aus. Einige nehmen ganze Systeme vorsorglich vom Netz. Andere lassen Kundenseiten erreichbar, schränken aber bestimmte Anfragetypen ein. Wieder andere aktualisieren im Hintergrund und kündigen nur kurze Neustarts an. Diese Entscheidungen erklären, warum am selben Tag eine Website normal lädt, während auf einer anderen keine Bilder oder Plugins mehr hochgeladen werden können.

Anbieter	Öffentlich dokumentierte Reaktion am 21.10.2026	Praktische Folgen
netcup	Vorsorgliches Trennen potenziell betroffener Webhosting- und Managed-Systeme vom Internet; anschließender Patch-Rollout. Eigenverwaltete Server nicht von der Abschaltung erfasst.	Vorübergehende Nichterreichbarkeit; bei Root-Servern/VPS eigene Updatepflicht.
Mittwald	Temporäre Schutzbeschränkungen, darunter Blockierung von Upload-Anfragen; später automatisierter Patch-Rollout. Um 21:54 Uhr noch nicht alle Systeme abschließend freigegeben.	Formulare und Uploads können ausfallen; Verwaltungsoberflächen zeitweise eingeschränkt.
Hetzner	Patch-Rollout für Webhosting und Managed-Server; laut Meldung von 19:50 Uhr PHP 7.4 sowie 8.0–8.5 dort aktualisiert. Backports für noch ältere Versionen in Arbeit.	Je nach Produkt eigener Handlungsbedarf; ein allgemeiner Freigabestatus für jede Einzelinstallation lässt sich daraus nicht ableiten.
Alfahosting	Dringende Installation angekündigt; einzelne Hosting-Systeme können ungeplant neu starten.	Websites möglicherweise minutenweise nicht erreichbar; Shared-Hosting-Kunden müssen nicht selbst patchen.
1blu	Umfangreiche PHP2Shell-FAQ mit betroffenen Betriebsarten, möglichen Zwischenmaßnahmen und Einschränkungen.	Ein allgemeiner aktueller Abschluss aller 1blu-Patches geht aus der öffentlich auffindbaren FAQ nicht hervor. Konkreten Webspace-Status beim Anbieter erfragen.
Namecheap	Schutzmaßnahmen auf mehreren Plattformen; seit 13:40 UTC laut Anbieter Installation der korrigierten PHP-Versionen.	Beim Shared Hosting übernimmt der Anbieter, VPS- und Dedicated-Kunden sollen selbst handeln.

Zu IONOS, STRATO und ALL-INKL ließ sich für diesen Vorfall zum Recherchezeitpunkt kein gleichwertig eindeutiger, aktueller Abschlussbericht für sämtliche Hostingpakete verifizieren. Das bedeutet weder, dass die Anbieter untätig sind, noch, dass ihre Kunden geschützt wären. Für IONOS und STRATO gibt es reguläre Informationen zum Extended PHP Support alter Versionen; eine solche Produktbeschreibung belegt aber nicht automatisch, dass der spezielle PHP2Shell-Fix bereits auf dem eigenen Webspace eingespielt ist. Die konkrete PHP-Version und ein gegebenenfalls eingesetzter Backport müssen bestätigt sein.

Warum jetzt plötzlich WordPress-Uploads und Kontaktformulare scheitern

Viele Datei-Uploads verwenden sogenannte multipart/form-data-Anfragen. Darüber gelangen beispielsweise Bilder in die WordPress-Mediathek, ZIP-Dateien in die Pluginverwaltung oder Anhänge über ein Kontaktformular auf den Server. Um verdächtige Anfragen vorübergehend abzufangen, können Hoster oder Web Application Firewalls genau solche Zugriffe beschränken.

• Plugins oder Themes lassen sich nicht hochladen: Die ZIP-Datei wird möglicherweise blockiert, noch bevor WordPress sie auswerten kann.
• Bilder erscheinen nicht in der Mediathek: Ein Upload kann mit HTTP 403, einer allgemeinen Fehlermeldung oder einem Abbruch enden.
• Formulare funktionieren nur teilweise: Besonders betroffen sind Formulare mit Dateianhang, unter Umständen auch gewöhnliche multipart-Formulare.
• Verwaltungsbereiche bleiben gesperrt: Manche Hoster schützen auch ihre eigenen Kundenportale, Webmailer oder Verwaltungstools.
• Die Startseite ist weiterhin erreichbar: Normale Seitenabrufe und bestimmte API-Anfragen können funktionieren, obwohl Uploads und Verwaltung eingeschränkt sind.

Wichtig: Ein solcher Fehler beweist noch nicht, dass der Hoster die PHP-Sicherheitslücke als Ursache hat. Fehlende Dateirechte, ausgeschöpfter Speicherplatz, ModSecurity-Regeln und WordPress-Berechtigungen können dieselben Symptome auslösen. Fallen Uploads jedoch gleichzeitig auf mehreren unabhängigen Websites eines Hosters aus, während das Lesen funktioniert, sollte man zuerst dessen aktuelle Sicherheits- und Statusmeldungen prüfen – und nicht übereilt Dateirechte auf 777 setzen oder Sicherheitsplugins deaktivieren.

Auch das vorübergehende Deaktivieren von session.upload_progress.enabled ist als Schutzmaßnahme diskutiert worden. Es unterbricht normalerweise keine Datei-Uploads an sich, kann aber bestimmte Fortschrittsanzeigen beeinflussen. Ein vollständiges Blockieren von Multipart-Anfragen hat dagegen deutlich spürbarere Folgen. Beide Maßnahmen sind lediglich Übergangslösungen.

Welche Website-Betreiber können selbst eingreifen?

Hostingmodell	Wer installiert den PHP-Fix?	Was kannst du selbst tun?
Shared Hosting / klassischer Webspace	In der Regel der Hostinganbieter	PHP-Version im Hostingmenü prüfen, Anbieterstatus kontrollieren, Website und Formulare testen.
Managed Hosting / Managed Server	Gemäß Leistungsumfang der Dienstleister	Patchstand bestätigen lassen; mögliche Kompatibilitätsprobleme dokumentieren.
Root-Server / selbst verwalteter VPS	Du oder dein beauftragter Administrator	Pakete aktualisieren, PHP-FPM/Apache neu starten, alle aktiven Versionen und Logs prüfen.
Container / Docker / eigene PHP-Bundles	Betreiber des Images bzw. der Anwendung	Gepatchtes Image/Runtime beziehen, Container neu bauen und ausrollen.

Bei einem selbst verwalteten Linux-Server sind die Paketquellen der Distribution maßgeblich. Ubuntu hat beispielsweise eigene Sicherheitspakete veröffentlicht. Auch cPanel liefert aktualisierte Pakete für aktuelle und bestimmte ältere PHP-Zweige. Gerade hier zeigt sich, warum die angezeigte Versionsnummer allein täuschen kann: Ein nachträglich zurückportierter Fix kann in einem Paket mit älterem Hauptversionszweig stecken. Entscheidend ist die nachprüfbare Bestätigung des Paket- oder Hostinganbieters.

Was du als WordPress-Betreiber jetzt konkret prüfen solltest

1. PHP-Version nachsehen: In WordPress unter Werkzeuge → Website-Zustand → Bericht → Server oder im Hostingpanel. Beachte, dass PHP-Versionen je Domain unterschiedlich sein können.
2. Patchstand abgleichen: Die neuen Versionen aus der Tabelle prüfen. Bei älteren/LTS-Paketen den Backport ausdrücklich beim Anbieter bestätigen lassen.
3. Backup sichern: Datenbank und Dateien sichern, bevor du eine neue Hauptversion aktivierst. Das ist besonders wichtig für ältere Themes, Plugins und eigene PHP-Anpassungen.
4. Nach Aktualisierung testen: Startseite, Login, Editor, Medienupload, Kontaktformular, Shop-Warenkorb, Checkout und geplante Hintergrundaufgaben prüfen.
5. Störungen korrekt zuordnen: Datum, Uhrzeit, HTTP-Status und betroffene Funktion notieren; Hostingstatus und Server-Logs prüfen.
6. Verdächtige Aktivitäten untersuchen: Unbekannte Administratoren, neue PHP-Dateien, Weiterleitungen, auffällige Prozesse oder ungewöhnliche ausgehende Verbindungen können auf eine Kompromittierung hindeuten.

Wer auf PHP 8.2 bleibt, muss zudem das Supportende am 31. Dezember 2026 berücksichtigen. Ein heute korrekt gepatchter PHP-8.2-Webspace kann zum Jahreswechsel schon wieder auf einem abgekündigten Zweig stehen. Ein Umstieg auf 8.4 oder 8.5 ist deshalb sinnvoll, sobald die Anwendung kompatibel ist – idealerweise zuerst in einer Testumgebung.

Hilft Cloudflare – und sind Angriffe bereits nachgewiesen?

Cloudflare hat zum 21. Oktober neue WAF-Schutzregeln aktiviert, auch für Nutzer des kostenlosen Tarifs, sofern dessen WAF eingesetzt wird. Der Anbieter berichtet zudem von beobachtetem Angriffsdatenverkehr und veränderten Angriffsmustern. Das belegt Versuche gegen betroffene Systeme; daraus folgt aber nicht, dass jede beobachtete Anfrage erfolgreich war. Auch die Gefahr einer bereits erfolgten Kompromittierung einer konkreten Website lässt sich daraus nicht ableiten.

Eine WAF ist ein nützlicher zusätzlicher Filter. Sie ist aber keine Garantie: Regeln können Lücken haben, legitime Anfragen fälschlich blockieren oder durch einen direkt erreichbaren Ursprungsserver umgangen werden. Auch hier gilt der Rat des PHP-Projekts: patchen statt dauerhaft auf Zwischenmaßnahmen verlassen.

Warum die Lücke so lange unbemerkt blieb – und die Rolle von KI

Die Schwachstellen betreffen grundlegende Speicher- und Fehlerpfade der PHP-Laufzeit. Solche Probleme können lange unentdeckt bleiben, weil sie nur unter bestimmten Bedingungen auftreten. Bemerkenswert ist diesmal, wie sie aufgespürt wurden: Sicherheitsforscher setzten leistungsfähige KI-Modelle ein.

Nach Angaben von OpenAI entdeckte die Sicherheitsfirma Calif im Rahmen der Initiative „Patch the Planet“ eine kritische Schwachstelle mit Hilfe von GPT-5.6 Sol. Unabhängig davon identifizierte die Sicherheitsfirma Wiz beide PHP-Lücken. Dabei setzte Wiz seine eigene Analyseplattform Wiz Atlas ein und nutzte unter anderem Googles Gemini 4 Argon sowie GPT-5.6 Sol. Google Cloud hebt besonders den Beitrag von Gemini 4 Argon hervor: Das Modell unterstützte bei der Suche nach den Fehlern, beim Entwickeln von Test-Exploits, beim Erkennen von Angriffen und bei der Überprüfung der Korrekturen. Nicht die KI-Modelle allein haben PHP aktualisiert – die PHP-Entwickler verantworteten die Fehlerbehebung und die Veröffentlichung der Sicherheitsupdates.

Der deutschsprachige Fachbeitrag von The Decoder über GPT-5.6 Sol und Gemini 4 Argon beschreibt die unabhängigen Entdeckungen und ordnet ein, weshalb der Einsatz solcher Modelle für die IT-Sicherheit einen Wendepunkt markieren könnte. Wichtig ist die Unterscheidung: Millionen potenziell gefährdeter Websites sind nicht gleichbedeutend mit Millionen tatsächlich gehackten Websites.

Dieselbe KI kann Verteidigern und Angreifern helfen

Die Kehrseite ist erheblich: Laut Wiz können KI-Modelle helfen, Angriffsmethoden rasch an unterschiedliche PHP-Versionen, Konfigurationen und Speicherlayouts anzupassen. Diese Einschätzung beschreibt ein Risiko der Automatisierung – nicht den Nachweis, dass bereits jede betroffene Website angegriffen oder übernommen wurde. Gerade deshalb sind funktionierende Patches und zügige Aktualisierungen so entscheidend.

Die koordinierte Vorbereitung lief nach OpenAI-Angaben rund zwei Monate. Beteiligt waren unter anderem PHP-Maintainer, Sicherheitsforscher, Infrastrukturunternehmen und Behörden. In fünf Phasen sollten Fehler bestätigt, Fixes geprüft, Schutzmaßnahmen vorbereitet und Updates breit ausgerollt werden. Die eigentlichen Korrekturen wurden vom PHP-Projekt verantwortet; Modelle und Sicherheitsfirmen lieferten wichtige Analysen und Tests.

Der Vorfall zeigt zugleich ein strukturelles Problem: Ein Sicherheitsupdate ist nur der Anfang. Linux-Distributionen, Anbieter mit alten PHP-Versionen, Serverpanels, Container-Images, Shared-Hosting-Plattformen und einzelne Anwendungen müssen den Fix tatsächlich übernehmen. Dazwischen können Stunden oder Tage vergehen. Manche Anbieter entscheiden sich in dieser Zeit bewusst für Einschränkungen, die ihre Kunden deutlich spüren.

Häufige Fragen zu PHP2Shell

Ist jedes WordPress automatisch gehackt?

Nein. Dass eine PHP-Version verwundbar ist, bedeutet nicht, dass ein Angreifer sie erfolgreich ausgenutzt hat. Öffentlich erreichbare ungepatchte Server sind jedoch dringend zu aktualisieren und bei verdächtigen Hinweisen zu untersuchen.

Muss ich WordPress, Plugins oder Themes aktualisieren?

Die üblichen Updates bleiben wichtig, schließen aber diese beiden PHP-Schwachstellen nicht. Entscheidend ist das Update der PHP-Laufzeit auf Server- oder Hostingebene.

Soll ich die Website bis dahin abschalten?

Bei einer öffentlich erreichbaren, nachweislich ungepatchten Installation ohne geeignete Abwehrmaßnahmen kann eine zeitweise Sperre des öffentlichen Zugangs die sicherste Übergangslösung sein. Ein PHP-basierter Wartungsmodus allein schützt nicht unbedingt, wenn ein Fehler bereits vor dessen Ausführung ausgelöst werden kann. Bei Managed Hosting zuerst den Anbieterstatus und dessen Vorgaben prüfen.

Warum kann ich gerade keine ZIP-Dateien in WordPress hochladen?

Hoster oder Firewalls können Multipart-Uploads vorübergehend sperren. Möglich sind aber auch gewöhnliche WordPress-, Speicher- oder Rechteprobleme. Entscheidend sind HTTP-Fehlercode, Serverprotokoll und die Statusmeldung des Hosters – nicht eine Vermutung über ein bestimmtes Plugin.

Einordnung: Sicherheit vor kurzfristigem Komfort

Wenn ein Hoster Uploads für einige Stunden blockiert oder Anwendungen zeitweise abschaltet, ist das für Betreiber ärgerlich – erst recht bei Shops, Buchungen oder laufenden Redaktionsarbeiten. Angesichts zweier kritischer Fehler im PHP-Kern kann eine zeitlich begrenzte Einschränkung aber sinnvoller sein, als ungepatchte Systeme ungehindert erreichbar zu lassen. Entscheidend sind transparente Kommunikation, zügige Patches und eine klare Meldung, wann welche Dienste wieder freigegeben wurden.

Die wichtigste praktische Regel bleibt: Prüfe nicht nur, ob deine Website wieder lädt, sondern ob tatsächlich eine korrigierte PHP-Version läuft. Ein Update beseitigt außerdem keine Hintertür, die ein Angreifer möglicherweise zuvor eingerichtet hat. Bei konkretem Verdacht braucht es eine getrennte Sicherheitsprüfung und gegebenenfalls Wiederherstellung aus einem sauberen Backup.

Bereits vor der Veröffentlichung der Details gab es dazu eine erste PHP-Sicherheitswarnung auf computer4you.de. Dieser Ratgeber ergänzt sie um die offiziellen Korrekturversionen, dokumentierte Hoster-Maßnahmen und die Folgen für den Website-Alltag.

Quellen und laufend relevante Statusmeldungen

• PHP Security Advisory und Releases vom 21. Oktober 2026
• Gemeinsame Warnung von ENISA, CERT-EU und EU-Partnern
• Hetzner: Vorfall und Updatefortschritt
• Mittwald: Live-Status
• netcup: Kundeninformation zur PHP-Lücke
• Alfahosting: PHP-Sicherheitsmeldung
• 1blu: FAQ zu PHP2Shell
• Cloudflare: WAF-Schutz und technische Analyse
• cPanel: Informationen zu den korrigierten Paketen
• OpenAI: Koordinierte Offenlegung und Hintergründe
• The Decoder: GPT-5.6 Sol, Gemini 4 Argon und PHP2Shell
• Wiz: Technische Analyse zur KI-gestützten Entdeckung
• Google Cloud: Gemini 4 Argon und PHP-Schwachstellen

Recherche- und Versionsstand: 21. Oktober 2026, spätabends (MESZ). Die Statusmeldungen der Hoster können sich kurzfristig ändern. Entscheidend ist immer der aktuelle Stand für den konkreten Hostingvertrag.