Das BSI hat zu PHP2Shell eine Cybersicherheitswarnung der Warnstufe „3 / Orange“ herausgegeben und stuft das Risiko damit als außerordentlich hoch ein. Einige Organisationen haben vorsorglich Dienste vom Netz genommen.
Die Lücken stecken in der PHP-Engine selbst. Damit sind auch Systeme gefährdet, deren eigener Code fehlerfrei ist: Content-Management-Systeme wie WordPress, Drupal oder Joomla, im deutschsprachigen Raum verbreitete Shopsysteme wie Shopware und Magento sowie eigene Unternehmensanwendungen. Für Einrichtungen, die unter NIS2 bzw. das österreichische NISG 2026 fallen, ist PHP2Shell zudem ein Praxistest für ihr Schwachstellen- und Patchmanagement.
PHP – Die Lage
PHP hat Updates für zwei kritische Sicherheitslücken veröffentlicht, die eine nicht authentifizierte Remote-Code-Ausführung ermöglichen können: CVE-2026-109618 und CVE-2026-109619, beide mit CVSS v4.0 9,2. Cloudflare meldet Angriffsverkehr auf die Lücken, darunter Versuche, die eigenen Schutzmaßnahmen zu umgehen. Besonders dringend sind Apache-mod_php-Installationen: PHP berichtet von einem nachgewiesenen Exploit, der greift, bevor überhaupt Anwendungscode ausgeführt wird.
Gefährdet sind alle PHP-Installationen, die Webanfragen bedienen, darunter PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Unternehmen sollten Systeme mit Internetanbindung priorisieren, beginnend mit Apache mod_php.
Die PHP-Schwachstellen im Überblick
- CVE-2026-109618 (Speicherüberlauf-Korruption): Unterbricht ein Speicherüberlauf einen anfälligen Vorgang, bleiben Anfragedaten teilweise initialisiert. Bereinigungsroutinen verarbeiten diesen ungültigen Zustand, was Remote-Code-Ausführung ermöglicht.
- CVE-2026-109619 (veralteter globaler Status): PHP behält Verweise auf bereits freigegebenen Speicher. Eine spätere Anfrage an denselben Worker greift darauf zu („Use-after-free“). Forscher haben darüber Remote-Code-Ausführung demonstriert.
Auch PHP-FPM muss gepatcht werden: PHP hat dort Remote-Code-Ausführung über den Sitzungslebenszyklus bestätigt. Zudem wurde die nicht authentifizierte Offenlegung von Worker-Speicher nachgewiesen, der Passwörter, Authentifizierungstoken und API-Schlüssel enthalten kann.
Behobene Versionen
| PHP-Zweig | Behobene Version |
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Bei Distributionspaketen gilt der Sicherheitshinweis des Anbieters, da zurückportierte Korrekturen eine ältere Versionsnummer behalten können. PHP 7.4, 8.0 und 8.1 sind nicht mehr regulär unterstützt. Dafür gibt es begrenzte Quellcode-Backports. Betreiber sollten einen korrigierten Build vom Distributions- oder Supportanbieter beziehen oder auf eine unterstützte Version wechseln.
Vorübergehende Abhilfemaßnahmen laut PHP
Nur ein Update schließt die Lücken vollständig. Die folgenden Maßnahmen verringern das Risiko, machen ungepatchte Systeme aber nicht sicher.
CVE-2026-109618:
- memory_limit=-1 auf Administrationsebene erzwingen (z. B. php_admin_value im FPM-Pool oder in der Apache-Konfiguration), alle Worker neu starten und sicherstellen, dass keine andere Einstellung wieder ein Limit setzt. Achtung: Das erhöht das Risiko der Ressourcenerschöpfung und ist nur eine Übergangslösung.
- Anfragegrenzen setzen: post_max_size=8M ohne Uploads, 32M mit Uploads. upload_max_filesize unterhalb von post_max_size halten.
- Größe und Komplexität von Anfragen auch am Webserver oder Proxy begrenzen. Multipart-Anfragen blockieren, wenn die Anwendung sie nicht benötigt.
- Container- oder cgroup-Speichergrenzen als Verfügbarkeitsschutz nutzen, aber kein RLIMIT_AS oder RLIMIT_DATA, da diese den anfälligen Pfad auslösen können.
CVE-2026-109619:
- session.upload_progress.enabled=0 über php.ini, FPM-Pool oder Serverkonfiguration setzen und Worker neu starten. ini_set() oder .user.ini reichen nicht.
- Unter PHP 8.5 zusätzlich fatal_error_backtraces=0 auf Administrationsebene setzen.
- Ursachen von Diagnosemeldungen, schwerwiegenden Fehlern und Timeouts beheben. Unterdrücken per error_reporting, display_errors oder @ schützt nicht.
- Optional für PHP-FPM: pm.max_requests=1, sofern die Performance das zulässt.
Ist ein Patch nicht sofort möglich, den öffentlichen Zugriff einschränken oder den Dienst vorübergehend isolieren. Jedes offene System braucht einen Verantwortlichen und eine Frist.
Behebung überprüfen
- Alle PHP-Installationen finden, auch parallele Zweige, Container, Hosting-Panels und in Appliances gebündeltes PHP. Die Version von php -v gehört nicht unbedingt zur Instanz, die Webanfragen bedient.
- Das richtige Paket oder Image aktualisieren, bei Containern gepatchte Images beziehen oder neu bauen.
- Worker neu starten oder Container neu bereitstellen und prüfen, dass keine Worker mit altem Build mehr laufen.
- Notfalländerungen zurückbauen: Nach dem Patch wieder ein endliches memory_limit setzen, temporäre Beschränkungen überprüfen und das Verhalten unter Speicherlast testen.
Von Saeed Abbasi, Leiter der Threat Research Unit (TRU) und Director Product bei Qualys
