PHP-Sicherheitslücke PHP2Shell: Was du jetzt tun musst

BlueBranch » Unser Magazin » PHP-Sicherheitslücke PHP2Shell: Was du jetzt tun musst

Von

Lukas M. Beck

21. Oktober 2026

10 Min. Lesezeit

PHP2Shell ist der Name für zwei kritische Sicherheitslücken im PHP-Kern (CVE-2026-109618 und CVE-2026-109619, je CVSS 9,2). Angreifer können darüber ohne Login Code auf dem Webserver ausführen, bei Apache mit mod_php sogar, bevor deine Anwendung startet. Geschlossen sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21. Oktober 2026.

Du betreibst eine Website, einen Shop oder eine Webanwendung auf PHP? Dann prüfe heute, welche PHP-Version auf deinem Server läuft. Ein Update von WordPress, Contao oder Shopware allein schließt diese Lücke nicht, denn der Fehler steckt im PHP-Interpreter selbst.

Aktualisiert am 21. Oktober 2026: watchTowr meldet beobachtete Angriffe, die Angaben zu den Angriffswegen sind präzisiert.

Das Wichtigste in Kürze

• Zwei kritische Lücken im PHP-Kern: CVE-2026-109618 („RCE via OOM corruption“) und CVE-2026-109619 („RCE via stale global state“), beide mit CVSS v4.0 9,2.
• Angriff ohne Login: Präparierte HTTP-Requests reichen. Bei Apache mit mod_php läuft der Angriff, bevor dein Anwendungscode startet.
• Sichere Versionen: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es keine offiziellen Releases mehr.
• Betroffen sind übliche Server-Setups: Apache mit mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed.
• Nur das Update schützt vollständig. Konfigurationsänderungen und WAF-Regeln senken das Risiko, schließen die Lücke aber nicht.
• Die Lücken werden bereits ausgenutzt: watchTowr beobachtet seit dem 21. Oktober Angriffe, Cloudflare meldete laut Sansec schon am Morgen erste Angriffe, noch vor dem offiziellen Patch.

Was ist PHP2Shell?

PHP2Shell bezeichnet zwei Speicherfehler im PHP-Kern, über die ein Angreifer aus der Ferne eigenen Code auf deinem Server ausführt (Remote Code Execution). Er braucht dafür keine Zugangsdaten. Die Advisories stufen die Angriffskomplexität als hoch ein, die Folgen für Vertraulichkeit, Integrität und Verfügbarkeit ebenfalls. Das PHP-Sicherheitsteam bewertet beide Schwachstellen als kritisch und hat sie am 21. Oktober 2026 mit neuen Versionen geschlossen.

Die Details waren schon am 20. Oktober durchgesickert. Laut Sansec und Huntress bestätigte das Sicherheitsunternehmen watchTowr die Lücken, PHP zog den Release daraufhin auf Mittwoch, 14:00 Uhr UTC (16:00 Uhr deutscher Zeit), vor. Gemeldet hatten die Fehler unter anderem Forschende von Wiz Research und Calif, die seit August 2026 daran arbeiteten.

CVE-2026-109618: Speicherfehler bei zu wenig Arbeitsspeicher

Wenn einem PHP-Request der Speicher ausgeht (Out of Memory), bricht PHP die Anfrage hart ab. In bestimmten Momenten ist der Speicher der Anfrage dann schon erreichbar, aber noch nicht fertig eingerichtet. Beim Aufräumen greift PHP auf diese halb fertigen Daten zu. Auslösen lässt sich das laut Advisory über präparierte Formular-Uploads (multipart/form-data), etwa mit fehlender Content-Length, sehr vielen Headern pro Teil oder leeren Dateifeldern.

CVE-2026-109619: veralteter Zustand im wiederverwendeten Worker

PHP-Worker bearbeiten nacheinander viele Anfragen. Nach einem Fatal Error, etwa einem Speicherüberlauf, bleiben Fehler-, Session- oder Objektdaten im Worker zurück, deren Speicher bereits freigegeben ist. Landet die nächste Anfrage beim selben Worker, liest PHP diese veralteten Daten. Bestätigt sind laut Advisory ein Weg über Fatal-Error-Backtraces in PHP 8.5 und ein Weg über den Session-Upload-Fortschritt, beide gegen mod_php, der zweite auch gegen PHP-FPM. Dafür braucht es mindestens zwei Anfragen: Eine hinterlässt den Zustand, die nächste nutzt ihn. Bei PHP-FPM läuft der Angriff erst während der normalen Verarbeitung und braucht eine passende Funktion in der Anwendung, etwa session_start() oder unserialize().

Welche PHP-Versionen sind betroffen?

Betroffen ist jede PHP-Version, die Webanfragen bedient und nicht auf dem neuen Stand ist. Sansec spricht von allen Webservern mit PHP 5.4 oder neuer. Die folgende Tabelle zeigt, ab welcher Version die Lücken geschlossen sind.

Wichtig bei Linux-Paketen: Debian, Ubuntu oder Red Hat übernehmen Sicherheitskorrekturen oft in ihre eigene Paketversion, ohne die PHP-Versionsnummer zu ändern. Eine Anzeige wie „8.2.29“ heißt dort nicht automatisch „verwundbar“. Maßgeblich ist der Sicherheitshinweis deiner Distribution. Wer PHP aus dem Remi-Repository bezieht, bekam den Fix laut Sansec am 21. Oktober noch nicht.

Ist meine Website betroffen?

Ja, wenn deine Website auf PHP läuft und dein Server noch keine gepatchte Version nutzt. Dabei ist egal, ob du WordPress, Contao, Shopware, Magento, Drupal, Laravel oder eigene Individualsoftware betreibst. Laut Sansec haben Forschende von Calif die Angriffe gegen WordPress 7.1.2, Drupal 11.4.3 und Magento 2.4.9 bestätigt, Wiz Research zusätzlich gegen WordPress und Drupal.

Ein CMS-Update, ein Sicherheits-Plugin oder der Wartungsmodus von WordPress schützen nicht, denn der Fehler steckt im PHP-Interpreter. Bei mod_php greift der Angriff, bevor WordPress oder ein anderes System die Anfrage überhaupt sieht. Bei PHP-FPM greift er während der normalen Verarbeitung, auch dort kann die Anwendung ihn nicht abfangen.

So prüfst du deine PHP-Version in 4 Schritten

1. Version im Webserver prüfen, nicht nur auf der Kommandozeile. php -v zeigt die CLI-Version. Der Webserver kann eine andere Version oder ein anderes Paket nutzen. In WordPress findest du die Version unter Werkzeuge → Website-Zustand → Bericht → Server.
2. Paket-Changelog nach der CVE-Nummer durchsuchen. Auf Debian und Ubuntu mit apt changelog php8.3-fpm | grep CVE-2026-109618, auf Red-Hat-Systemen mit rpm -q --changelog php | grep CVE-2026-109618. Ein Treffer heißt: Der Fix ist im Paket.
3. Bei Shared Hosting den Hoster fragen. Prüfe die PHP-Version in deinem Kundenmenü und die Statusseite deines Anbieters. Fehlt dort ein Hinweis, frag per Ticket nach, bis wann der Patch eingespielt ist.
4. Alle PHP-Installationen auflisten. Denk an Staging-Server, alte Microsites, Admin-Tools, Docker-Images und Appliances mit eingebautem PHP. Huntress empfiehlt, mit den Systemen zu beginnen, die direkt aus dem Internet erreichbar sind.

Sofortmaßnahmen: Was du jetzt tun musst

Das Update ist die einzige vollständige Lösung. Spiel die gepatchte Version ein und starte danach alle PHP-Worker neu, sonst laufen alte Prozesse mit dem fehlerhaften Code weiter.

# Debian/Ubuntu, Beispiel PHP 8.3 mit PHP-FPM
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm

# Apache mit mod_php
sudo systemctl restart apache2

Kannst du nicht sofort aktualisieren, etwa weil dein Hoster noch nicht so weit ist oder eine alte Anwendung an PHP 8.1 hängt, senken diese Übergangsmaßnahmen das Risiko. Jede hat einen Preis:

Setz diese Werte administrativ, also in der php.ini, in der FPM-Pool-Konfiguration (php_admin_value bzw. php_admin_flag) oder in der Serverkonfiguration. Per ini_set() oder .user.ini greifen sie zu spät. Danach gilt dasselbe wie beim Update: alle PHP-Worker neu starten. Teste danach deine Formulare, den Login und, falls vorhanden, den Checkout.

Woran erkennst du einen Angriff?

Bestätigte Indikatoren (IOCs) gab es am 21. Oktober noch nicht. Sansec und Huntress nennen aber Muster, auf die du in Logs und Prozesslisten achten solltest:

• Auffällige multipart-Requests, auf die Memory-Limit-Fehler oder gehäufte HTTP-500-Antworten folgen.
• Ungewöhnlich große oder kaputte PHPSESSID-Cookies in Antworten.
• Unerklärliche Neustarts von PHP-Workern oder eine stark erhöhte Worker-Fluktuation.
• Prozesse, die direkt vom Webserver gestartet werden: sh, bash, python, perl, curl, wget oder nc als Kindprozess von php-fpm, httpd oder apache2.
• Befehle wie whoami, id oder uname -a aus dem Kontext des Webservers.

Bei Verdacht: Nimm den Server vom Netz oder isoliere ihn, sichere Webserver- und PHP-Logs und suche nach neuen Dateien im Webroot, unbekannten Cronjobs und neu angelegten Admin-Konten. Ändere danach Datenbank-Passwörter und API-Schlüssel, die auf dem Server lagen. Fehlende Log-Einträge beweisen laut PHP-Advisory nicht, dass kein Angriff stattgefunden hat.

Was PHP2Shell für WordPress, Contao und Individualsoftware bedeutet

Für Betreiber einer PHP-Website verschiebt PHP2Shell die Verantwortung: Nicht dein CMS, sondern die Serverumgebung entscheidet diesmal über die Sicherheit. Wer verwaltetes Hosting nutzt, ist auf das Tempo des Hosters angewiesen. Wer einen eigenen Server betreibt, muss selbst patchen und die Worker neu starten.

Besonders kritisch sind Systeme auf PHP 8.1 und älter. Diese Versionen bekommen keine offiziellen Releases mehr und lassen sich nur über Distributoren, LTS-Anbieter oder ein Upgrade absichern. Läuft deine Contao-Installation noch auf einer alten Version, ist jetzt der richtige Moment, die Contao-Wartung samt PHP-Upgrade anzugehen.

Bei Individualsoftware lohnt ein Blick in den Wartungsvertrag. Er sollte regeln, wer Sicherheitsupdates der Laufzeitumgebung einspielt, in welcher Reaktionszeit das bei kritischen Lücken passiert und wann ein Wechsel auf eine unterstützte PHP-Version ansteht. Fehlt diese Regel, merkst du das meist erst an einem Tag wie diesem.

Häufige Fragen zu PHP2Shell

Was ist PHP2Shell?

PHP2Shell ist der Name für zwei kritische Sicherheitslücken im PHP-Kern, CVE-2026-109618 und CVE-2026-109619. Über präparierte HTTP-Requests können Angreifer ohne Login Code auf dem Webserver ausführen. PHP hat beide Lücken am 21. Oktober 2026 geschlossen.

Welche PHP-Version schließt die Sicherheitslücke?

Die Lücken sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 geschlossen. Für PHP 8.1 und älter gibt es keine offiziellen Releases, nur minimale Backports und Patches von Distributoren oder LTS-Anbietern.

Reicht ein WordPress-Update gegen PHP2Shell?

Nein. Der Fehler steckt im PHP-Interpreter, nicht in WordPress. Bei Apache mit mod_php greift der Angriff sogar, bevor WordPress den Request verarbeitet. Schützen kann dich nur ein Update von PHP auf dem Server, ein CMS-Update oder Sicherheits-Plugin hilft hier nicht.

Bin ich mit Shared Hosting betroffen?

Ja, solange dein Hoster die PHP-Version noch nicht aktualisiert hat. Prüfe die Version in deinem Kundenmenü, achte auf die Statusseite des Anbieters und frag per Ticket nach, wann der Patch eingespielt ist.

Hilft es, session.upload_progress.enabled abzuschalten?

Es schließt einen bestätigten Angriffsweg und wird laut PHP-Advisory auch nach dem Update empfohlen. Allein reicht es aber nicht, weil CVE-2026-109618 über andere Wege ausgelöst wird. Die vollständige Lösung ist das Update.

Wird PHP2Shell schon aktiv ausgenutzt?

Ja. watchTowr hat seit dem 21. Oktober 2026 Angriffe in seinem Honeypot-Netz beobachtet. Cloudflare meldete laut Sansec schon um 07:43 Uhr UTC erste Angriffe auf PHP-Seiten, noch vor dem Patch. Huntress hatte bis 16:00 Uhr deutscher Zeit in den eigenen Kundenumgebungen keine Ausnutzung gesehen. Sansec rechnet mit Massenangriffen.

Quellen

1. The PHP Group: Security advisory: Critical remote code execution vulnerabilities, update now sowie Release-Hinweise zu PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, php.net, abgerufen am 21.10.2026.
2. PHP-Sicherheitsteam: GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618), github.com, abgerufen am 21.10.2026.
3. PHP-Sicherheitsteam: GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619), github.com, abgerufen am 21.10.2026.
4. Sansec: Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619, sansec.io, abgerufen am 21.10.2026.
5. Huntress: Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities, huntress.com, abgerufen am 21.10.2026.
6. watchTowr: PHP RCE FAQ: PHP2Shell CVE-2026-109618 & CVE-2026-109619, watchtowr.com, abgerufen am 21.10.2026.

21. Oktober | 16:46 Uhr | Programmiersprachen

Beiträge, die dich außerdem interessieren könnten

Interpretierte und kompilierte Programmiersprache