Website prüfen

Alle Artikel

php2shell: Zwei kritische PHP-Lücken sind geschlossen. Aktualisieren Sie das PHP Ihrer Website noch heute

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 beheben CVE-2026-109618 und CVE-2026-109619, zwei Lücken für Remotecodeausführung ohne Anmeldung. Wer betroffen ist, wie Sie Ihre PHP-Version prüfen und was jetzt zu tun ist.

Radek, ENSOMEDIAVeröffentlicht 8 Min. LesezeitIn EnglishPo polskuEn españolEn français中文بالعربية

Am 21. Oktober 2026 hat das PHP-Projekt PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Die Versionen beheben zwei kritische Schwachstellen, CVE-2026-109618 und CVE-2026-109619, mit denen ein Angreifer ohne Anmeldung Code auf einem Webserver ausführen kann. Das PHP-Team sagt, alle PHP-Nutzer sollten sofort aktualisieren (php.net).

Wenn Ihre Website auf WordPress, WooCommerce, Joomla, Drupal oder einer anderen PHP-Software läuft, betrifft Sie das. Die Lücken liegen in PHP selbst, nicht in WordPress oder einem Plugin. Ein WordPress-Update behebt sie deshalb nicht. Ihr PHP muss aktualisiert werden, in der Regel von Ihrem Hosting-Anbieter.

Was passiert ist

  • 20. Oktober 2026: Das PHP-Sicherheitsteam kündigte für den 21. Oktober 2026 um 14:00 UTC ein Sicherheitsrelease an, das zwei kritische Schwachstellen mit CVSS v4.0 9.2 behebt (php.net).
  • 21. Oktober 2026, 03:02 UTC: Cloudflare schaltete für seine Kunden, auch im kostenlosen Tarif, Firewall-Regeln gegen den Angriff frei. Cloudflare sagt, die Details seien vor dem offiziellen Release durchgesickert, und es habe Angriffsverkehr gegen seine Kunden gesehen (Cloudflare-Blog).
  • 21. Oktober 2026: PHP veröffentlichte die korrigierten Versionen und zwei Sicherheitshinweise, GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp, beide als Critical mit 9.2 bewertet.

Die beiden Lücken heißen „php2shell“ (Cloudflare-Blog, BleepingComputer). Das britische National Cyber Security Centre rät Organisationen zu aktualisieren und zu erwägen, ein System vom Netz zu nehmen, wenn es sich nicht schnell aktualisieren oder absichern lässt (NCSC).

Wer betroffen ist

Laut PHP ist jede PHP-Installation gefährdet, die Webanfragen bedient, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten stuft PHP das Risiko bei mod_php ein: Dort funktioniert ein nachgewiesener Exploit mit einer einzigen Anfrage ohne Anmeldung, noch bevor Anwendungscode läuft (php.net).

Beide Hinweise nennen alle Versionen unterhalb von 8.2.35, 8.3.36, 8.4.27 und 8.5.12 als betroffen (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp). Auch ältere Zweige sind betroffen: Das NCSC nennt PHP 5 und neuer (NCSC), Cloudflare nennt PHP 5.4 oder neuer (Cloudflare-Blog).

Wenn Ihre Website PHP nutzt und seit dem Nachmittag des 21. Oktober niemand PHP aktualisiert hat, gehen Sie davon aus, dass sie betroffen ist.

So prüfen Sie, welche PHP-Version Ihre Website nutzt

In WordPress: Öffnen Sie Werkzeuge > Website-Zustand > Info und dort den Bereich Server. Er zeigt die PHP-Version, auf der Ihre Website läuft (WordPress.org-Dokumentation). Meldet der Website-Zustand außerdem, dass Ihre Website eine veraltete PHP-Version nutzt, behandeln Sie das als dringend.

Im Hosting-Panel: Die meisten Panels (cPanel, Plesk, DirectAdmin und anbietereigene Panels) haben eine Seite, auf der Sie die PHP-Version ansehen oder wählen können, oft „PHP-Version“, „PHP-Auswahl“ oder „PHP-Einstellungen“ genannt. Finden Sie sie nicht, fragen Sie Ihren Anbieter.

Vergleichen Sie, was Sie sehen, mit den korrigierten Versionen unten. Ein Vorbehalt: Linux-Distributionen und Anbieter mit Langzeitsupport haben die Patches vorab erhalten und liefern eigene Pakete aus (php.net). Ihre Versionsnummer muss nicht zu den Nummern des PHP-Projekts passen, auch wenn die Korrektur enthalten ist. Nutzt Ihr Anbieter Distributionspakete, gibt eine verlässliche Antwort der Anbieter, nicht die Nummer allein.

Was Sie jetzt tun sollten

1. Auf eine korrigierte Version wechseln

Ihr PHP-Zweig Korrigierte Version Supportstatus
8.5 8.5.12 Sicherheitskorrekturen bis 31. Dez. 2029
8.4 8.4.27 Sicherheitskorrekturen bis 31. Dez. 2028
8.3 8.3.36 Sicherheitskorrekturen bis 31. Dez. 2027
8.2 8.2.35 Sicherheitskorrekturen bis 31. Dez. 2026, danach Ende des Supports
8.1 und älter Kein offizielles Release Ende des Supports, siehe unten

Korrigierte Versionen: php.net. Supportzeiträume: Unterstützte PHP-Versionen.

Nutzen Sie PHP 8.2, aktualisieren Sie jetzt auf 8.2.35 und planen Sie den Wechsel auf 8.3 oder neuer. PHP 8.2 erhält nach dem 31. Dezember 2026 keine Sicherheitskorrekturen mehr (php.net).

2. Wenn Sie PHP 8.1, 8.0, 7.4 oder älter nutzen

Das PHP-Projekt veröffentlicht für PHP 8.1 und älter keine Updates mehr. Einige Distributionen und LTS-Anbieter liefern zurückportierte Korrekturen. Wegen der Schwere hat das PHP-Sicherheitsteam außerdem minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 veröffentlicht, gedacht für alle, die PHP aus dem Quellcode bauen oder keinen LTS-Anbieter haben (php.net).

Für eine typische Unternehmenswebsite bei Shared oder Managed Hosting ist die Antwort einfacher: Wechseln Sie im Hosting-Panel auf eine unterstützte Version (8.3 oder neuer) oder bitten Sie Ihren Anbieter darum. Testen Sie die Website danach, denn alte Plugins und Themes laufen auf neuerem PHP manchmal nicht mehr.

3. Fragen Sie Ihren Anbieter

Schicken Sie Ihrem Anbieter eine kurze Nachricht:

Guten Tag, ist das PHP in meinem Paket (Domain: example.de) bereits gegen CVE-2026-109618 und CVE-2026-109619 gepatcht? Welche genaue PHP-Version oder welches Paket nutze ich, und wann wird das Update eingespielt, falls es noch nicht erfolgt ist?

Betreiben Sie einen eigenen Server und nutzen das von Freiwilligen gepflegte Repository rpms.remirepo.net, wird es laut PHP am 21. Oktober keine Updates geben. PHP rät, auf Distributionspakete zu wechseln oder aus dem Quellcode zu bauen (php.net).

4. Eine Firewall verschafft ein paar Tage, sie ist nicht die Lösung

Cloudflare hat Regeln für die bekannten Angriffswege in allen Tarifen mit WAF eingeführt, auch im kostenlosen (Cloudflare-Blog). Der CTO von Cloudflare nannte sie eine Übergangslösung und forderte Administratoren auf zu patchen (Tenable). PHP selbst sagt, es gebe keine vollständigen Gegenmaßnahmen, und nur das Update sei sicher (php.net).

Zwei Grenzen. Die Regeln decken bekannte Angriffsmuster ab, und Angreifer änderten ihre Payloads bereits, um sie zu umgehen (Cloudflare-Blog). Außerdem schützen die Regeln nichts, wenn Angreifer Ihren Server direkt über die IP-Adresse erreichen können. Der Ursprungsserver sollte deshalb Webverkehr nur von Cloudflare annehmen (Sansec).

5. Wenn Sie heute nicht aktualisieren können

PHP nennt Konfigurationsänderungen, die die Angriffsfläche für die bekannten Angriffswege verkleinern, einen Server aber nicht sicher machen (php.net). Es sind Servereinstellungen, bei Shared Hosting muss sie also Ihr Anbieter setzen. Geben Sie diese Liste an Ihren Entwickler oder Anbieter weiter:

  • Für CVE-2026-109618: Setzen Sie memory_limit=-1 so, dass Anwendungen es nicht überschreiben können (zum Beispiel php_admin_value im FPM-Pool oder in der Apache-Konfiguration). Setzen Sie ein niedriges post_max_size (8M ohne Uploads, 32M mit Uploads) mit upload_max_filesize darunter und begrenzen Sie Anfragegröße, Feldanzahl, Multipart-Teile und Header am Webserver oder Proxy. Verwenden Sie nicht RLIMIT_AS oder RLIMIT_DATA.
  • Für CVE-2026-109619: Setzen Sie session.upload_progress.enabled=0 in php.ini, im FPM-Pool oder in der Serverkonfiguration und starten Sie alle Worker neu (ini_set() und .user.ini wirken hier nicht). Setzen Sie unter PHP 8.5 zusätzlich fatal_error_backtraces=0 und starten Sie alle Worker neu. Entfernen Sie ungültige oder veraltete Einstellungen pro Anfrage, die Warnungen erzeugen.

Technische Details

Beide Lücken haben dieselbe Art von Ursache: Wenn eine Anfrage abnormal endet, kann PHP Speicher in einem defekten Zustand zurücklassen, dem ein späterer Schritt vertraut (BleepingComputer, Cloudflare-Blog).

CVE-2026-109618, RCE durch Speicherbeschädigung bei Speichermangel (OOM) (GHSA-w8hw-w9fx-j79w). PHP bricht eine Anfrage mit longjmp() ab, wenn der Speicher ausgeht. An manchen Stellen ist der Anfragespeicher erreichbar, bevor er vollständig initialisiert ist. Schlägt in diesem Moment eine Allokation fehl, kann das Beenden der Anfrage die halb aufgebauten Daten lesen. Angreifer können den Speichermangel mit Multipart-Anfragen erzwingen: ein Body ohne brauchbare Content-Length, ein Teil mit extrem vielen Headern oder viele leere Dateifelder mit verschachtelten Namen. Bei Apache mod_php geschieht das während des automatischen Parsens des Bodys, bevor Anwendungscode läuft. Remotecodeausführung unter dem Konto des Web-Workers wurde gegen mod_php mit Standardgrenzen für Eingabe und Speicher bestätigt. FPM gilt nach Quellcode-Analyse als anfällig, ein vollständiger FPM-Exploit wurde aber nicht gezeigt. Der Patch ersetzt longjmp() bei Speichermangel durch einen verzögerten weichen Stopp an einer sicheren Stelle und ein hartes _exit() bei einer höheren Schwelle.

CVE-2026-109619, RCE durch veralteten globalen Zustand (GHSA-6wmf-4rv5-p3rp). Ein PHP-Worker hält globalen Zustand (Fehler-, Session-, Objekt- und Erweiterungszustand), der auf Speicher zeigt, den eine einzelne Anfrage besitzt. Ein fataler Fehler, auch Speichermangel oder Maximum execution time exceeded, kann das Zurücksetzen dieses Zustands überspringen. Die nächste Anfrage, die derselbe Worker bearbeitet, kann dann den freigegebenen Speicher vor der normalen Initialisierung nutzen: ein Use-after-free. Zwei frühe Verbraucher sind bestätigt: Warnungen aus INI-Einstellungen pro Anfrage, die vor der Initialisierung angewendet werden, und der Session-Upload-Fortschritt, der standardmäßig aktiv ist und nicht verlangt, dass die Anwendung session_start() aufruft. Der Pfad über fatal_error_backtraces in PHP 8.5 ist die Grundlage des bestätigten mod_php-Exploits. Der Session-Pfad wurde gegen mod_php und FPM validiert. Fehler mit error_reporting, display_errors oder @ zu verbergen schützt nicht.

Beide Hinweise bewerten mit 9.2 und dem Vektor CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: Angriff über das Netzwerk, keine Rechte, keine Nutzerinteraktion, hohe Angriffskomplexität und voller Einfluss auf Vertraulichkeit, Integrität und Verfügbarkeit des Servers.

Was ShieldWave prüft

Von außen kann niemand erkennen, ob ein Server den Patch hat. Ein Scan sieht nur die PHP-Version, die der Server von sich selbst angibt.

  • Der kostenlose Scan auf shieldwave.io liest den Antwort-Header X-Powered-By. Meldet der Server eine PHP-Version, die älter ist als die korrigierte Version ihres Zweigs, oder einen Zweig ganz ohne Korrektur, nennt der Bericht einen php2shell-Befund mit beiden CVE-Nummern und dem Release, das Sie brauchen. Viele Anbieter verbergen diesen Header, und Distributionen patchen, ohne die Nummer zu ändern. Ein Befund bedeutet also „fragen Sie Ihren Anbieter“, und kein Befund beweist nicht, dass der Server gepatcht ist.
  • Das Plugin Ensomedia Security für WordPress zeigt die PHP-Version, auf der die Website läuft, und ob dieser Zweig noch unterstützt wird (Plugin-Seite). Damit erfasst es den schlimmsten Fall dieses Vorfalls: eine Website auf PHP 8.1, 8.0, 7.4 oder älter, für die es keine offizielle Korrektur gibt. Das Plugin ist kostenlos, braucht kein Konto und steht im WordPress.org-Verzeichnis. Gehen Sie in Ihrem Dashboard zu Plugins > Installieren und suchen Sie nach „Ensomedia Security“.

Den genauen Patchstand erfahren Sie über den Website-Zustand und die Tabelle oben. Lassen Sie ihn sich von Ihrem Anbieter bestätigen.

Quellen

Offiziell:

Weitere: