PHP2Shell: Die Lücke sitzt unter jeder Webseite
Zwei kritische PHP-Lücken erlauben Codeausführung ohne Anmeldung. Das BSI warnt, die Updates sind da. Was Betreiber von WordPress, Shops und eigenen Servern jetzt prüfen müssen.
Seit dem 21. Oktober gibt es Sicherheitsupdates für PHP — und das BSI hat eine Cybersicherheitswarnung dazu veröffentlicht. Zwei Schwachstellen erlauben es, ohne Anmeldung fremden Code auf einem Webserver auszuführen. Weil das an Log4Shell erinnert, hat die Sache den Namen PHP2Shell bekommen.
Der entscheidende Unterschied zu den üblichen Meldungen: Es geht nicht um ein Plugin, nicht um ein Theme und nicht um WordPress. Die Lücke steckt in PHP selbst — also in der Software, die auf dem Server läuft und Ihre Webseite überhaupt erst ausliefert. Betroffen ist damit potenziell alles, was auf PHP aufsetzt: WordPress, Joomla, TYPO3, Shopware, Nextcloud, selbstgebaute Anwendungen und sogar PHP-Oberflächen in Netzwerkgeräten.
Die Kurzfassung
| Merkmal | Angabe |
|---|---|
| CVEs | CVE-2026-109618, CVE-2026-109619 |
| Bewertung | CVSS 4.0: 9.2 (kritisch) |
| Behoben in | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Veröffentlicht | 21. Oktober 2026 |
| Ohne offizielles Update | PHP 8.1 und älter |
| Folge | Codeausführung aus der Ferne, ohne Anmeldung |
| Status | Dem BSI ist keine Ausnutzung in der Breite bekannt, es gibt Berichte über Angriffsversuche |
Wenn Sie einen eigenen Server betreiben und noch nicht aktualisiert haben: Das ist der Punkt, an dem Sie den Artikel unterbrechen sollten. Der Rest lässt sich danach in Ruhe lesen.
Was technisch passiert
Beide Lücken drehen sich um denselben Kern: PHP räumt nach einem Seitenaufruf nicht sauber hinter sich auf.
CVE-2026-109618 betrifft den Fall, dass PHP während eines Aufrufs an die Speichergrenze stößt. PHP bricht den Vorgang dann hart ab — und zwar so, dass interne Daten des Aufrufs nur teilweise angelegt sind. Beim anschließenden Aufräumen behandelt PHP diese halbfertigen Daten als gültig und arbeitet mit ihnen weiter.
CVE-2026-109619 geht in dieselbe Richtung: Zustandsdaten eines Aufrufs können den Speicher überleben, auf den sie zeigen. Ein späterer Aufruf im selben Arbeitsprozess greift dann auf diese veralteten Verweise zu.
In beiden Fällen entsteht daraus ein Zustand, über den ein Angreifer eigenen Code auf dem Server ausführen kann. Weder Zugangsdaten noch ein Klick eines Administrators sind dafür nötig.
Nicht jede Betriebsart ist gleich gefährdet
Das ist der Teil, der in vielen Meldungen untergeht. Wie riskant die Lücke ist, hängt davon ab, wie PHP auf Ihrem Server eingebunden ist:
- Apache mod_php — am gefährlichsten. Hier wurde die vollständige Codeausführung über einen einfachen HTTP-Aufruf nachgewiesen, mit Standardeinstellungen und bevor überhaupt Anwendungscode läuft.
- PHP-FPM — nach Analyse des Quellcodes angreifbar, ein vollständiger Angriff wurde öffentlich aber nicht demonstriert. Das ist die heute verbreitetste Variante.
- FrankenPHP und LiteSpeed/LSAPI — nach Einschätzung der Entwickler ebenfalls angreifbar, nicht abschließend nachgewiesen.
Die Entwarnung daraus ist dünn: „Nicht demonstriert” heißt nicht „nicht möglich”. Es heißt, dass es niemand veröffentlicht hat.
Sind Sie betroffen?
Schritt 1: PHP-Version herausfinden
- WordPress: Werkzeuge → Website-Zustand → Bericht → Server
- Beim Hoster: Kundenbereich, meist unter „PHP-Einstellungen” oder „PHP-Version”
- Shopsysteme: Systeminformation im Backend
- Eigener Server:
php -vauf der Kommandozeile — und zusätzlich die Version des Webserver-Moduls prüfen, die davon abweichen kann
Abgesichert sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie alles darüber.
Schritt 2: Die Versionsnummer allein reicht nicht
Linux-Distributionen und Hoster spielen Sicherheitskorrekturen häufig ein, ohne die Versionsnummer zu ändern. Ein „PHP 8.2.20” bei Ihrem Anbieter kann also längst abgesichert sein — oder eben nicht. Verlässlich ist nur die Aussage des Anbieters.
Fragen Sie im Zweifel schriftlich nach: Ist die bei uns eingesetzte PHP-Version gegen CVE-2026-109618 und CVE-2026-109619 abgesichert? Ohne klare Antwort gehen Sie besser davon aus, dass die Seite offen ist.
Schritt 3: Zuständigkeit klären
| Ihre Situation | Wer aktualisiert |
|---|---|
| Webhosting-Paket, Managed WordPress | Der Hoster |
| Managed Server | In der Regel der Hoster |
| Eigener Server, VPS, Root-Server | Sie |
| Docker-Container mit PHP-Image | Sie — Image neu bauen, nicht nur neu starten |
Die großen deutschen Anbieter — IONOS, STRATO, Hetzner, netcup, all-inkl, mittwald, DomainFactory und andere — haben ihre Plattformen nach eigenen Angaben in den Tagen nach dem 21. Oktober abgesichert. Prüfen Sie die Statusseite Ihres Anbieters, die Lage änderte sich im Tagesrhythmus.
Ein Sonderfall verdient Aufmerksamkeit: PHP 8.1 und älter erhält vom PHP-Projekt keine Updates mehr. Manche Hoster pflegen trotzdem eigene Korrekturen ein, teils auch für sehr alte Versionen, teils nur im kostenpflichtigen Extended Support. Wenn Ihre Seite noch auf PHP 8.1, 7.4 oder älter läuft, ist das jetzt die dringlichere Baustelle — und zwar unabhängig von diesen beiden CVEs.
Was jetzt zu tun ist
1. Aktualisieren — und die Prozesse neu starten
Das ist der Schritt, der am häufigsten vergessen wird. Nach dem Einspielen der neuen PHP-Pakete laufen die alten Arbeitsprozesse unter Umständen weiter. Starten Sie PHP-FPM beziehungsweise den Webserver neu, sonst arbeitet der Server unverändert mit dem verwundbaren Code.
Das PHP-Projekt ist in diesem Punkt eindeutig: Das Update ist die einzige vollständige Maßnahme. Alles andere senkt nur das Risiko.
2. Wenn Sie nicht sofort aktualisieren können
Für die Übergangszeit nennen das Advisory und die Praxis mehrere Teilmaßnahmen:
memory_limit=-1administrativ erzwingen — die wichtigste Konfigurationsmaßnahme, da der Angriff über das Erreichen der Speichergrenze läuftRLIMIT_ASundRLIMIT_DATAnicht verwenden — sie lösen genau den verwundbaren Pfad auspost_max_sizeknapp setzen und die Größe der Anfragen schon am Webserver begrenzenmax_input_nesting_levelsenken, die Anzahl der Eingabevariablen, Multipart-Teile und Uploads begrenzen- Multipart-Anfragen blockieren, wenn Ihre Seite keine Formulare mit Dateiupload braucht
session.upload_progress.enabled=0setzen — schließt einen der beschriebenen Angriffswege, danach PHP-Prozesse neu starten- Eine WAF hilft nur, wenn sie bereits Regeln für dieses Muster mitbringt
Und falls Sie eine Seite vorübergehend vom Netz nehmen wollen: Die Wartungsseite muss der Webserver ausliefern, nicht PHP. Der WordPress-Wartungsmodus nützt hier nichts, weil er selbst über PHP läuft.
3. Nach Spuren suchen
Ein Update schließt die Lücke — es entfernt keine Hintertür, die vorher installiert wurde. Berichte über Angriffsversuche gibt es bereits ab dem Zeitraum um die Veröffentlichung. Öffentliche Erkennungsmerkmale wurden bisher nicht veröffentlicht, deshalb bleibt die klassische Prüfung:
- Unbekannte Administratorkonten
- Neue oder veränderte PHP-Dateien — besonders im Upload-Ordner und im aktiven Theme
- Weiterleitungen oder fremde Inhalte in den Suchergebnissen
- Hinweise des Hosters auf Spam-Versand oder auffällige Last
- Ungewöhnliche Prozesse und ausgehende Verbindungen auf dem Server
Bei bestätigter Codeausführung ist ein Neuaufbau aus einem geprüften Backup verlässlicher als die Suche nach einzelnen Hintertüren.
Noch nicht ganz ausgestanden
Zur Ehrlichkeit gehört: Mit den Updates vom 21. Oktober ist das Thema PHP-Speicherverwaltung nicht abgeschlossen.
Es gibt Berichte über einen weiteren Fehler in unserialize(), der auch die gepatchten Versionen betreffen soll und noch keine CVE-Nummer hat. Er setzt allerdings voraus, dass eine Anwendung fremde Daten an unserialize() übergibt — was ohnehin als schlechte Praxis gilt. Außerdem wurde ein Folgefehler in 8.4.27 und 8.5.12 gemeldet, der Arbeitsprozesse abstürzen lassen kann; eine Korrektur ist angekündigt.
Für die Praxis ändert das nichts an der Reihenfolge: erst auf die abgesicherten Versionen, dann weiterbeobachten.
Was wir daraus mitnehmen
Die Schicht unter Ihrer Webseite braucht auch Pflege. Wer in den letzten Jahren diszipliniert WordPress und Plugins aktualisiert hat, hat viel richtig gemacht — bei dieser Lücke hilft es nur nicht. Betriebssystem, Webserver und PHP gehören genauso auf die Wartungsliste.
Wissen, wer wofür zuständig ist. Der häufigste Fehler in solchen Lagen ist nicht fehlende Technik, sondern die Annahme, „das macht bestimmt der Hoster”. Bei einem Webhosting-Paket stimmt das meistens. Bei einem Root-Server, den jemand vor drei Jahren eingerichtet hat, fast nie.
Alte PHP-Versionen sind eine Zeitbombe mit Zündschnur. Diese Lücke betrifft PHP sehr breit, Updates gibt es offiziell nur für 8.2 und neuer. Wenn Ihre Seite auf einer älteren Version läuft, ist das der Anlass, das endlich zu ändern. PHP 8.2 selbst erreicht übrigens am 31. Dezember 2026 sein Lebensende.
Ein Vergleich zur WordPress-Lücke wp2shell aus dem Juli zeigt das Muster: Zwischen „Lücke bekannt” und „Lücke wird ausgenutzt” liegen heute Stunden, nicht Wochen. Der Vorsprung entsteht vorher — durch eine Umgebung, die aktualisiert werden kann, ohne dass vorher jemand wochenlang testen muss.
Unsicher, ob Ihre Seite abgesichert ist?
Wir prüfen Ihre PHP-Version, klären mit dem Hoster den Patch-Stand und sehen nach, ob Ihre Seite im offenen Zeitfenster Spuren abbekommen hat. Für Kunden mit Wartungsvertrag ist das bereits erledigt.
Schreiben Sie uns — im Zweifel lieber einmal zu viel nachgesehen.
Quellen: BSI-Cybersicherheitswarnung zu CVE-2026-109618 und CVE-2026-109619, Version 1.2 vom 22.10.2026. Technische Angaben aus den GitHub-Security-Advisories des PHP-Projekts (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp) und den Release-Ankündigungen auf php.net vom 21.10.2026. Angaben zu Hostern und Folgefehlern nach öffentlichen Berichten, Stand 23.10.2026.