PHP2Shell: Kritische PHP-Lücken erlauben Codeausführung ohne Anmeldung — jetzt aktualisieren

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht, die in Fachkreisen bereits „PHP2Shell“ genannt werden — in Anspielung auf Log4Shell. Beide Lücken sind mit CVSS 9.2 von 10 bewertet und können dazu führen, dass ein Angreifer ohne Anmeldung und ohne Zutun eines Nutzers eigenen Code auf dem Webserver ausführt. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat dazu den IT-Sicherheitshinweis BITS-H 2026-297981-1032 herausgegeben und die Lage mit Kritikalität 3 / Orange bewertet: „Maßnahmen müssen unverzüglich ergriffen werden.“ Kurz gesagt: • Betroffen: alle PHP-Installationen, die Webanfragen beantworten — PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Verwundbar sind laut CERT-EU alle bekannten Versionen bis mindestens PHP 5. • Geschützt: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 — oder die entsprechend gepatchten Pakete Ihrer Linux-Distribution. • Dringlichkeit: Das BSI hält eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches für wahrscheinlich. Es gibt unbestätigte Berichte über bereits existierende Exploits. • Wenn Sie nicht sofort patchen können: Es gibt Übergangsmaßnahmen, die bekannte Angriffswege erschweren — aber keine, die vollständig schützt.

Beide Schwachstellen liegen im PHP-Kern, nicht in einer einzelnen Erweiterung oder Anwendung. Das PHP-Projekt beschreibt sie so: • CVE-2026-109618 — Codeausführung über Speicherfehler („RCE via OOM corruption“): Wenn PHP der Speicher ausgeht, kann die Verarbeitung an einer Stelle abbrechen, an der interne Daten der Anfrage erst teilweise angelegt sind. Die anschließende Aufräumroutine behandelt diese unfertigen Daten dann als gültig. • CVE-2026-109619 — Codeausführung über veralteten Zustand („RCE via stale global state“): Interner Zustand einer Anfrage kann bestehen bleiben, obwohl der zugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage, die im selben Worker-Prozess landet, kann diesen veralteten Zustand verwenden, bevor er zurückgesetzt wird. Besonders brisant: Laut PHP-Projekt ist das Risiko bei Apache mit mod_php am höchsten. Dort wurde ein Exploit demonstriert, bei dem eine einzige Anfrage ohne Anmeldung den Angriff auslöst — noch bevor überhaupt Code der eigentlichen Anwendung läuft. Ein gut gepflegtes WordPress, ein aktuelles TYPO3 oder ein sauber programmierter Shop schützt also nicht: Die Lücke sitzt eine Ebene darunter. Vollständige technische Details veröffentlicht das PHP-Projekt in den GitHub-Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp.

PHP ist einer der zentralen Bausteine des Webs. Das BSI nennt ausdrücklich WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense als Beispiele für Projekte, die auf PHP aufbauen. Hinzu kommen PHP-Komponenten in proprietären Produkten — von Verwaltungsoberflächen über Firewalls bis zu NAS-Systemen und Appliances. Zwei Punkte machen die Lage aus Sicht des BSI besonders ernst: • Die Lücke betrifft die Programmiersprache selbst. Ein einziger Angriffsweg funktioniert damit gegen eine enorme Zahl unterschiedlichster Systeme — die Voraussetzung für massenhafte, automatisierte Angriffskampagnen. • Patches verraten den Fehler. Spätestens seit KI-gestützten Werkzeugen zur Exploit-Entwicklung können Angreifer veröffentlichte Korrekturen sehr schnell analysieren und daraus funktionierende Angriffe ableiten. Deshalb rechnet das BSI mit einer breiten Ausnutzung innerhalb weniger Stunden. Bis zur Veröffentlichung dieses Beitrags sind laut BSI noch keine bestätigten Angriffe bekannt. Darauf sollte sich niemand verlassen: Bei Lücken dieser Art vergeht zwischen „keine Angriffe beobachtet“ und „flächendeckende Scans“ erfahrungsgemäß sehr wenig Zeit.

Betroffen ist jede PHP-Installation, die Anfragen aus dem Netz beantwortet. Wer konkret handeln muss, hängt davon ab, wie Ihre Website oder Anwendung betrieben wird: • Eigener Server oder vServer (Root-Zugang): Sie selbst. PHP kommt hier meist über die Paketverwaltung der Distribution (apt, dnf) oder über die Verwaltungsoberfläche (etwa Plesk). • Webhosting-Paket (Shared Hosting): In erster Linie Ihr Hoster. Prüfen Sie trotzdem in der Verwaltungsoberfläche, welche PHP-Version Ihre Website nutzt — veraltete Versionen bis PHP 8.1 bekommen vom PHP-Projekt keine Updates mehr. • Docker-Container: Sie. Container mit PHP müssen auf Basis eines aktualisierten Images neu gebaut werden — ein Update des Hosts allein reicht nicht. • Appliances und Geräte mit Weboberfläche (Firewalls, NAS, Telefonanlagen und Ähnliches): Hier ist der Hersteller gefragt, der gepatchte Firmware bereitstellen muss. Bis dahin sollte die Verwaltungsoberfläche nicht aus dem Internet erreichbar sein. • Lokale Entwicklungsumgebungen (XAMPP, Laragon und Co.): Weniger dringend, solange sie nicht aus dem Netz erreichbar sind — aber ebenfalls aktualisieren. Ein Sonderfall sind Altversionen: Für PHP 8.1 und älter veröffentlicht das PHP-Projekt keine Updates mehr. Manche Distributionen und Anbieter von Langzeit-Support liefern zurückportierte Korrekturen; das PHP-Sicherheitsteam hat zusätzlich minimale Backports für PHP 7.4, 8.0 und 8.1 als Quellcode bereitgestellt. Wer darauf angewiesen ist, sollte das als Anlass nehmen, endlich auf eine unterstützte Version umzusteigen.

Die geschützten Versionen sind: • PHP 8.5.12 • PHP 8.4.27 • PHP 8.3.36 • PHP 8.2.35 Achtung bei Linux-Distributionen: Debian, Ubuntu und Red Hat übernehmen die Korrekturen häufig per Backport in ihre eigene Versionsnummer. Ein Paket kann also sicher sein, obwohl „php -v“ eine ältere Version anzeigt. Gleichen Sie die installierte Paketversion deshalb mit den Sicherheitsmeldungen Ihrer Distribution ab — Ubuntu, Debian und Red Hat veröffentlichen sie jeweils unter der CVE-Nummer CVE-2026-109618. Die Linux-Distributionen und Langzeit-Support-Anbieter haben die Patches laut PHP-Projekt vorab erhalten. Praktische Schritte: 1. Inventur: Auf welchen Servern läuft PHP, in welchen Versionen und mit welchem Betriebsmodus (FPM, mod_php, CGI)? Auf der Kommandozeile zeigt „php -v“ die CLI-Version — die Version, mit der die Website tatsächlich läuft, kann davon abweichen. Prüfen Sie sie im Zweifel in der Verwaltungsoberfläche oder per „php-fpm -v“ bzw. „php-fpm8.3 -v“. 2. Updates einspielen: Distribution (zum Beispiel „apt update && apt upgrade“), Plesk-Updater bzw. Paketquelle der Verwaltungsoberfläche oder Neubau der Container-Images. 3. Dienste neu starten: PHP-FPM, Apache bzw. LiteSpeed neu starten, damit keine alten Worker-Prozesse weiterlaufen. 4. Prüfen: Version erneut kontrollieren — für jede PHP-Version, die auf dem Server installiert ist, nicht nur für die Standardversion. Hinweis für Plesk-Server: Plesk liefert eigene PHP-Pakete aus (plesk-php83, plesk-php84, plesk-php85 usw.), die nicht über die Distribution kommen. Die gepatchten Versionen 8.3.36, 8.4.27 und 8.5.12 stehen seit dem 21. Oktober in den Plesk-Paketquellen bereit. Achtung, Stolperfalle aus unserer Praxis: Plesk signiert die PHP-Paketquellen inzwischen mit einem neuen Schlüssel. Kennt der Server ihn noch nicht, meldet „apt update“ nur eine unscheinbare Warnung („NO_PUBKEY 5B6AB2160B50DB96“) — und der Server bleibt still auf der verwundbaren Version, obwohl er „aktuell“ wirkt. Abhilfe: den Plesk-Schlüsselbund von autoinstall.plesk.com/plesk.gpg neu einspielen (Fingerabdruck des neuen Schlüssels: 43C5 DA0D BF8B 7DE1 457C 9428 5B6A B216 0B50 DB96), dann erneut aktualisieren und mit „/opt/plesk/php/8.x/bin/php -v“ jede installierte Version prüfen. Hinweis für Nutzer des Remi-Repositorys: Das PHP-Projekt rät ausdrücklich, sich nicht allein auf rpms.remirepo.net zu verlassen, weil dort am Veröffentlichungstag noch keine Updates verfügbar waren.

Das PHP-Projekt nennt Übergangsmaßnahmen, die bekannte Angriffswege blockieren. Ganz deutlich vorweg: Sie machen eine Installation nicht sicher. Nur das Update schützt vollständig. Gegen CVE-2026-109619 (veralteter Zustand): • „session.upload_progress.enabled = 0“ setzen — in der php.ini, im FPM-Pool oder in der Serverkonfiguration, die vor der Verarbeitung der Anfrage greift. „ini_set()“ und „.user.ini“ reichen nicht. Danach alle Worker neu starten. Wichtig: Laut PHP-Projekt blockiert das nur die bestätigten Angriffswege über Sessions, andere Varianten aber nicht. heise online hält die Maßnahme nach eigenem Kenntnisstand sogar für unwirksam. Verlassen Sie sich also keinesfalls darauf. • Nur bei PHP 8.5: zusätzlich „fatal_error_backtraces = 0“ setzen und alle Worker neu starten. • Ungültige oder veraltete Einstellungen entfernen, die bei jeder Anfrage Warnungen erzeugen. Warnungen nur zu verstecken (error_reporting, display_errors, @) hilft nicht. Gegen CVE-2026-109618 (Speicherfehler): • „post_max_size“ niedrig halten: 8M für Anwendungen ohne Datei-Upload, 32M mit Uploads. „upload_max_filesize“ muss darunter liegen. • Am Webserver oder Proxy Grenzen für Anfragegröße, Anzahl der Formularfelder, Multipart-Teile, Header und Verschachtelungstiefe setzen — auch für Anfragen ohne Längenangabe. • Das PHP-Projekt nennt zusätzlich „memory_limit = -1“ (nicht überschreibbar, etwa per php_admin_value). Das entfernt zwar den steuerbaren Auslöser, hebt aber jede Speichergrenze für PHP auf. Ohne Container- oder cgroup-Grenze als Absicherung kann ein einzelner Prozess dann den ganzen Server lahmlegen — diese Maßnahme gehört deshalb nur in erfahrene Hände. Die Grenzen RLIMIT_AS und RLIMIT_DATA sollten ausdrücklich nicht als Ersatz dienen, weil sie den verwundbaren Fehler selbst auslösen können. Ergänzend nennt das BSI: • Eine Web Application Firewall (WAF) kann Angriffe abfangen — aber nur, wenn sie bereits Erkennungsregeln für diese beiden Lücken hat. Fragen Sie beim Anbieter nach. • Als letzte Möglichkeit: den Webserver vorübergehend vom Internet trennen, bis das Update eingespielt ist. Für einen Shop oder ein Kundenportal ist das schmerzhaft — aber weniger schmerzhaft als ein kompromittierter Server.

Zum Zeitpunkt dieses Beitrags gibt es laut BSI keine bestätigten Angriffe und damit auch keine verlässlichen Angriffsmerkmale (Indicators of Compromise). Im Netz kursierende Listen sollten Sie mit Vorsicht behandeln, bis das BSI oder das PHP-Projekt sie bestätigen. Das BSI empfiehlt, PHP-Webserver, die aus dem Internet erreichbar sind, verstärkt zu beobachten. Unabhängig von dieser Lücke sind das die üblichen Hinweise auf eine Kompromittierung, auf die wir in solchen Lagen achten: • neue oder veränderte PHP-Dateien im Webverzeichnis, vor allem in Upload- und Cache-Ordnern • ungewöhnliche Prozesse, die unter dem Benutzer des Webservers oder von PHP-FPM laufen • unerwartete ausgehende Verbindungen des Webservers • auffällig viele sehr große oder abgebrochene Anfragen in den Zugriffsprotokollen • neue Cronjobs, Administratorkonten oder SSH-Schlüssel Wer einen Verdacht hat, sollte den Server nicht einfach „aufräumen“, sondern Protokolle sichern und sich Unterstützung holen — ein kompromittierter Server ist ohne saubere Analyse nicht vertrauenswürdig.

So gehen wir bei unseren Kunden vor: 1. Heute noch inventarisieren: Alle Server, Websites, Container und Geräte mit PHP erfassen — samt Version und Betriebsmodus. Vergessene Testsysteme und alte Subdomains nicht übersehen. 2. Sofort aktualisieren, wo Updates bereitstehen: Distribution, Verwaltungsoberfläche, Container-Images. Danach alle PHP-Dienste neu starten und die Version prüfen. 3. Wo noch kein Update bereitsteht: Übergangsmaßnahmen setzen (Upload-Fortschritt deaktivieren, Anfragegrößen begrenzen) und — weil keine davon verlässlich schützt — betroffene Systeme bis zum Update besser vom Internet trennen. Verwaltungsoberflächen von Appliances gehören ohnehin nicht ins offene Netz. 4. Beobachten: Protokolle und Webverzeichnisse in den nächsten Tagen auf Auffälligkeiten prüfen; die Meldungen von BSI, PHP-Projekt und Distribution verfolgen. 5. Altlasten abbauen: PHP-Versionen bis 8.1 sind ohne Herstellerunterstützung, PHP 8.2 erreicht am 31. Dezember 2026 sein Lebensende. Planen Sie jetzt den Umstieg auf PHP 8.4 oder 8.5 — die nächste kritische Lücke kommt bestimmt. Wenn Sie das nicht selbst stemmen möchten: Prüfung, Aktualisierung und Absicherung Ihrer Webserver übernehmen wir im Rahmen unseres IT-Supports und unserer Managed Services. Mehr zur Absicherung Ihrer Infrastruktur finden Sie unter IT-Sicherheit.

PHP2Shell ist keine Lücke in einer einzelnen Anwendung, sondern im Fundament eines großen Teils des Webs. Wer eine Website, einen Shop, eine Cloud-Lösung oder ein Gerät mit PHP-Weboberfläche betreibt, ist mit hoher Wahrscheinlichkeit betroffen — auch wenn die Anwendung selbst aktuell ist. Die gute Nachricht: Die Updates sind da, und sie lassen sich in den meisten Umgebungen in Minuten einspielen. Entscheidend ist jetzt Geschwindigkeit. Zwischen der Veröffentlichung eines Patches und den ersten automatisierten Angriffen liegen heute oft nur noch Stunden. Sie sind unsicher, ob Ihre Systeme betroffen sind, oder Ihr Hoster bzw. Hersteller liefert noch kein Update? Sprechen Sie uns an — wir helfen kurzfristig.