Technik & Sicherheit · · 10 Min. Lesezeit
PHP2Shell: Kritische PHP-Lücken – ist Ihre Website schon aktualisiert?
Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Lücken veröffentlicht. Betroffen ist jede Website, deren PHP nicht aktualisiert wurde – also auch WordPress, Joomla, TYPO3 oder Shopware. Angreifer können unter bestimmten Bedingungen ohne Anmeldung Code auf dem Server ausführen; bei Apache mit mod_php sogar, bevor Ihre Website überhaupt geladen wird. Angriffsversuche laufen bereits. Klären Sie noch heute mit Ihrem Hoster, ob das Update eingespielt ist. Stand: 22. Oktober 2026.
Was ist PHP2Shell?
PHP führt Website-Code auf dem Server aus, etwa für WordPress und Joomla. An den PHP2Shell-Berichten waren unter anderem Wiz, OpenAI und Calif beteiligt. Die Kennungen lauten CVE-2026-109618 und CVE-2026-109619. Die PHP-Advisories bewerten beide mit 9,2 von 10 Punkten nach CVSS v4.0 als kritisch. Das beschreibt die Schwere, nicht die Wahrscheinlichkeit eines Einbruchs bei Ihrer Website.
Die Fehler betreffen den Umgang mit Speicher und abgebrochenen Anfragen: PHP kann unvollständig vorbereitete Daten weiterverwenden oder auf bereits freigegebenen Speicher zugreifen. Präparierte Anfragen können dadurch Codeausführung, Datenabfluss oder Abstürze auslösen. Aktuelle Plugins und starke Passwörter bleiben wichtig, beheben aber diese Fehler in PHP selbst nicht.
PHP nennt PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed als zu prüfende Betriebsarten. Bei mod_php ist ein Angriff vor Ausführung des Website-Codes demonstriert. Für FPM meldet die PHP Foundation Codeausführung über Anwendungspfade; das OOM-Advisory dokumentiert dafür noch keinen vollständigen Exploit. Beim zweiten Fehler ist ein FPM-Pfad unter bestimmten Anwendungsbedingungen bestätigt. FPM bietet daher keine pauschale Entwarnung.
Laut Wiz reichen betroffene Versionen bis PHP 5.4 zurück: Jeweils mindestens eine Schwachstelle ist relevant. Nicht jeder Angriff funktioniert in jeder Konfiguration. Entscheidend ist die Korrektur der tatsächlich eingesetzten PHP-Laufzeit.
Wie gefährlich ist das wirklich?
Ein erfolgreicher Angriff kann Code mit den Rechten des PHP-Arbeitsprozesses ausführen. Welche Dateien oder Datenbanken erreichbar sind, hängt von dessen Berechtigungen ab; vollständige Administratorrechte über den Server folgen daraus nicht automatisch. Wiz demonstrierte auch das Auslesen sensibler Prozessdaten wie Passwörter, Tokens und API-Schlüssel. Damit können beispielsweise Zugangsdaten und Kundendaten gefährdet sein.
Cloudflare berichtet von Angriffsverkehr im Zusammenhang mit dem vorzeitigen Bekanntwerden der Lücken und von veränderten Angriffsmustern. watchTowr meldet aktive Ausnutzungsversuche. CERT-EU empfiehlt sofortige Updates und, wenn das nicht möglich ist, die Isolation öffentlich erreichbarer Anwendungen zu erwägen. Entsprechende Empfehlungen veröffentlicht auch das niederländische NCSC. Das BSI hat gewarnt; bei CERT-Bund ist der Hinweis WID-SEC-2026-4055 nachgewiesen.
Angriffsversuche belegen noch keine erfolgreichen Einbrüche. Eine belastbare Gesamtzahl kompromittierter Systeme enthalten die Quellen nicht. Die gemeldeten Versuche machen das Update dringend; eine Frist bis zum Angriff auf Ihre Website lässt sich daraus nicht ableiten.
Welche PHP-Versionen beheben diese Lücken?
Für unveränderte PHP-Releases gelten je Versionszweig diese Mindeststände. Anbieter können Korrekturen in ältere Pakete einbauen: Solche Backports brauchen einen Herstellernachweis. Die Angaben betreffen diese beiden Lücken, nicht die gesamte Sicherheit Ihrer Website.
- PHP 8.5: ab 8.5.12.
- PHP 8.4: ab 8.4.27.
- PHP 8.3: ab 8.3.36.
- PHP 8.2: ab 8.2.35. Der reguläre Sicherheitssupport endet am 31. Dezember 2026; planen Sie den Wechsel auf einen unterstützten Zweig.
- PHP 8.1, 8.0 und 7.4 erhalten keine regulären PHP-Projekt-Updates mehr. Dafür gibt es ausnahmsweise Quellcode-Patches sowie Anbieterpakete. Plesk nennt unter Linux korrigierte Builds vom 21. Oktober für 8.1.34, 8.0.30 und 7.4.33. Die sichtbare PHP-Version kann gleich bleiben. Bei cPanel und Ubuntu sind die vollständigen Paketkennungen maßgeblich.
- Auch ältere Zweige erhalten einzelne Anbieter-Backports: Hetzner meldet korrigiertes PHP 5.6 und 7.3 für sein Webhosting und seine Managed-Server. Das gilt nicht für beliebige Installationen. Ohne bestätigten Fix müssen Sie ein Update, einen Versionswechsel oder eine vorübergehende Zugangssperre klären.
Wie prüfe ich, ob meine Website betroffen ist?
Bei Shared Hosting teilen sich mehrere Kunden die Server-Infrastruktur; die PHP-Pakete verwaltet der Hoster. Sie können häufig den Versionszweig auswählen, aber das Sicherheitsupdate nicht selbst installieren. Lassen Sie den Stand für jede Domain, Subdomain und zusätzliche PHP-Anwendung bestätigen. Auch eine von einer Agentur gebaute Website kann bei einem anderen Anbieter liegen.
- WordPress: Werkzeuge → Website-Zustand → Bericht → Server zeigt die PHP-Version. Eine niedrigere Nummer als oben kann durch einen Backport trotzdem korrigiert sein. Lassen Sie sich dafür die Paketkennung und die passende Sicherheitsmeldung nennen.
- Plesk: Domains → Ihre Domain → PHP-Einstellungen → „phpinfo() anzeigen“. Vergleichen Sie Version und „Build Date“ mit der Plesk-Meldung zum konkreten Paket. Ein beliebiges neues Build-Datum beweist keine Korrektur. Fehlt der Zugang, fragen Sie den Hoster.
- cPanel: Software → MultiPHP Manager zeigt die Version je Domain, sofern Ihr Hoster die Funktion freigibt. Prüfen Sie alle relevanten Domains; sie können unterschiedliche PHP-Versionen verwenden.
- Hostinger: hPanel → Websites → Dashboard → PHP Info. Nur für seine aktualisierten Pakete nennt Hostinger den 21. Oktober 2026 oder später als ausreichendes Build-Datum. Die Abschlussmeldung für Managed Hosting stammt vom 22. Oktober, 06:44 UTC, also 08:44 Uhr MESZ. VPS-Kunden verwalten PHP selbst.
- Hetzner meldet für Webhosting und Managed-Server den Abschluss für PHP 7.4 und 8.0–8.5 am 21. Oktober um 19:50 Uhr MESZ, für 5.6 und 7.3 am 22. Oktober um 06:32 Uhr MESZ. Diese Anbieterangaben bestätigen nicht automatisch den Stand selbst verwalteter Dedicated- oder Cloud-Server.
- Andere Anbieter: Bitten Sie um eine Bestätigung für Ihre Domain. Eine nicht gefundene öffentliche Meldung beweist keinen fehlenden Patch. Bei SSH-Zugang zeigt `php -v` die Kommandozeilen-Version; die Website kann einen anderen PHP-Prozess verwenden.
Was muss ich meinem Hoster schreiben?
Schreiben Sie dem Hosting-Support oder Ihrer Websitebetreuung. Bei Fremdhosting sollte die Agentur den Serverbetreiber einbeziehen. Kopieren Sie diese Anfrage:
„Sind CVE-2026-109618 und CVE-2026-109619 für alle PHP-Versionen meiner Domains [Domains] behoben? Bitte bestätigen Sie die tatsächlich genutzten Web-PHP-Versionen, vollständigen Paket-/Build-Kennungen, gegebenenfalls den Backport-Nachweis sowie Aktivierungszeit und Neustart aller PHP-Arbeitsprozesse. Sind auch Verwaltungsoberfläche und PHP-Webmail aktualisiert? Falls etwas offen ist: Wann erfolgt die Korrektur, und wie wird bis dahin der öffentliche Zugriff außerhalb von PHP gesperrt?“
Verlangen Sie einen Nachweis zum konkreten Paket. Laufende PHP-Prozesse müssen nach dem Update neu gestartet werden, damit sie den korrigierten Code verwenden. Eine allgemeine Statusmeldung ersetzt diese Bestätigung nicht.
Website-PHP und internes Panel-PHP müssen getrennt geprüft werden. Für Plesk nennt der Hersteller 18.0.81 Update 4 beziehungsweise 18.0.80 Update 11 zur Korrektur von sw-engine. Für cPanel/WHM sind 11.110.0.153, 11.134.0.66, 11.136.0.50 und 11.138.0.18 genannt. Zusätzlich benötigen die PHP-Pakete der Websites ihre Updates.
Denken Sie an E-Mail: cPanels internes PHP wird auch für Roundcube-Webmail genutzt. Eine aktualisierte Website bestätigt keinen korrigierten Webmail-Zugang. Lassen Sie die Webmail-Laufzeit separat prüfen, auch bei anderen Panels. Die PHP-Lücken beweisen weder einen Einbruch in jedes Postfach noch die Sicherheit Ihrer Mail-Dienste.
Nach dem Update: Lassen Sie PHP-Stand und Neustart bestätigen und prüfen Sie wichtige Abläufe wie Anmeldung, Kontaktformular und Bestellung. Klären Sie vorhandene Sicherungen von Dateien und Datenbank sowie deren Wiederherstellbarkeit. Ein Backup ersetzt den Patch nicht. Bei verdächtigen Veränderungen sollte die Betreuung vor einer Bereinigung Dateien und Protokolle sichern, den Vorfall untersuchen und betroffene Zugangsdaten nach der Bereinigung erneuern. Ein Patch allein entfernt keinen bereits eingeschleusten Schadcode.
Was tun, wenn das Update nicht sofort möglich ist?
Klären Sie mit dem Betreiber die vorübergehende Isolation. CERT-EU empfiehlt, öffentlich erreichbare Anwendungen bis zur angewendeten und geprüften Korrektur gegebenenfalls abzuschirmen. Eine Sperre im Webserver oder in der Firewall muss vor PHP greifen; eine WordPress-Wartungsseite reicht dafür nicht. Eine Beschränkung auf ausdrücklich zugelassene IP-Adressen kann den Zugang begrenzen, behebt die Lücken aber nicht.
Für Administratoren nennt PHP begrenzte Übergangsmaßnahmen: `memory_limit=-1` möglichst unveränderbar setzen; tatsächlicher Speichermangel bleibt gefährlich. `post_max_size=8M` ohne benötigte Uploads beziehungsweise `32M` mit Uploads setzen, `upload_max_filesize` darunter halten. Zusätzlich Anfragegröße und -komplexität am Webserver oder Proxy begrenzen, auch ohne brauchbare Content-Length. Container-/cgroup-Grenzen können die Verfügbarkeit absichern; `RLIMIT_AS` und `RLIMIT_DATA` sind dafür kein Ersatz. Das ist keine Anleitung zur ungeprüften Änderung im Kundenpanel.
Für weitere Angriffspfade: `session.upload_progress.enabled=0` vor dem Einlesen der Anfrage konfigurieren, etwa in php.ini oder im FPM-Pool; `ini_set()` und FPM-`.user.ini` reichen nicht. Auf PHP 8.5 zusätzlich `fatal_error_backtraces=0`; danach alle Arbeitsprozesse neu starten. Fehlerhafte Einstellungen, auslösbare fatale Fehler und Zeitüberschreitungen muss die Betreuung prüfen. Fehlermeldungen auszublenden hilft nicht. Diese Maßnahmen schließen nicht alle Angriffspfade.
Cloudflare bietet seit dem 21. Oktober, 03:02 UTC, also 05:02 Uhr MESZ, zusätzliche Regeln auch im Free-Tarif, sofern die Website den WAF-Schutz nutzt. Bei Bezahltarifen den Cloudflare Managed Ruleset mit „Generic Rules – Anomalous Execution“ im Block-Modus prüfen lassen. Im Free-Ruleset sind die Regeln automatisch aktiv. Das PHP-Update bleibt nötig.
Was haben wir für unsere Kunden gemacht?
Bei unserer Prüfung am 22. Oktober fanden wir auf unseren Hosting-Servern Plesk-PHP 8.0 bis 8.5 mit Builds vom 21. Oktober, passend zur Plesk-Sicherheitsmeldung. Die PHP-FPM-Prozesse wurden bis zum Morgen des 22. Oktober auf allen Servern neu gestartet. Die Verwaltungsoberfläche prüfen wir separat.
Für Websites auf unserem Hosting müssen Sie selbst nichts installieren. Das gilt ausdrücklich nicht für Websites auf Fremdhosting, auch wenn wir diese erstellt haben oder betreuen: Dort muss der jeweilige Betreiber den Patchstand bestätigen. Auffälligkeiten an Ihrer Website melden Sie uns bitte weiterhin.
Häufige Fragen zu PHP2Shell
Ich habe WordPress und alle Plugins aktuell. Reicht das?
Nein. Diese Updates beheben die Fehler in PHP nicht. Manche Angriffspfade greifen bereits vor WordPress. Lassen Sie den Hoster die tatsächlich verwendete PHP-Laufzeit aktualisieren und die Prozesse neu starten. CMS- und Plugin-Updates bleiben daneben wichtig.
Meine Website zeigt PHP 8.1.34 an. Sind die Lücken behoben?
Die Nummer allein beantwortet das nicht. Bei Plesk unter Linux ist der korrigierte Build vom 21. Oktober maßgeblich, bei cPanel beispielsweise das EasyApache-Paket 8.1.34-5 für ea-php81. Lassen Sie sich den passenden Herstellernachweis geben. Planen Sie unabhängig vom Notfall-Patch den Wechsel auf einen unterstützten PHP-Zweig.
Woher weiß ich, ob meine Website schon gehackt wurde?
Unbekannte Benutzer, veränderte Dateien, unerwartete Weiterleitungen oder Schadsoftwarewarnungen sind Gründe für eine Untersuchung, aber kein spezifischer PHP2Shell-Nachweis. Lassen Sie die Betreuung Dateien und Serverprotokolle prüfen. Fehlende Auffälligkeiten beweisen nicht, dass kein Einbruch stattgefunden hat. Das gilt auch nach dem Update.
Ist meine Website mit Cloudflare sicher?
Die eingerichtete Web Application Firewall kann bekannte Angriffsmuster abfangen. Cloudflare meldet jedoch auch veränderte Muster und verlangt weiterhin das PHP-Update. Ein Cloudflare-Konto allein bestätigt weder den Schutz Ihrer Website noch deren Patchstand.
Ich habe eine statische Website ohne PHP. Betrifft mich das?
Wenn tatsächlich kein PHP Webanfragen verarbeitet, trifft dieser Angriffsweg die Website nicht. Prüfen Sie aber PHP-Kontaktformulare, zusätzliche Blogs sowie Verwaltungsoberflächen und Webmail separat. Der Name eines Website-Systems oder die Dateiendung der Startseite genügt nicht als Nachweis.
Warum wurden so alte Fehler erst jetzt behoben?
Laut PHP Foundation gab es 2024 erste Hinweise auf das OOM-Problem. Schwierige Korrekturen und organisatorische Engpässe verzögerten die Behebung. Die Foundation beschreibt inzwischen auch Änderungen an ihrer Sicherheitsarbeit. Für Sie zählt: korrigierte Pakete einsetzen und veraltete PHP-Zweige ablösen.