PHP2Shell ist der Sammelname für zwei kritische Fehler im PHP-Kern: CVE-2026-109618 und CVE-2026-109619. Beide können laut PHP eine nicht authentifizierte Ausführung von Code aus der Ferne ermöglichen. Am 21. Oktober 2026 veröffentlichte PHP Korrekturen in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. AWS registrierte Versuche in seinem Honeypot MadPot; ob sie reale Systeme erfolgreich angegriffen hätten, blieb laut AWS unklar.
Was bei PHP2Shell im Arbeitsspeicher passiert
Die beiden Sicherheitslücken betreffen die Verarbeitung von Webanfragen, funktionieren aber unterschiedlich. CVE-Kennungen sind standardisierte Nummern für Sicherheitslücken.
- CVE-2026-109618 betrifft die Behandlung eines Speichermangels. Dabei können Daten einer Anfrage unvollständig initialisiert bleiben und später bei der Bereinigung falsch verarbeitet werden.
- CVE-2026-109619 betrifft internen Zustand, der einer Anfrage gehört. PHP kann diesen Zustand nach dem Freigeben des zugehörigen Speichers behalten; eine spätere Anfrage desselben Workers kann dann auf veraltete Daten zugreifen. Ein Worker ist ein PHP-Prozess, der Anfragen bearbeitet.
PHP bewertete beide Fehler im Vorabhinweis mit 9,2 nach CVSS v4.0, dem System zur Einstufung des Schweregrads von Sicherheitslücken. Betroffen sein können laut PHP alle Installationen, die Webanfragen bedienen. Dazu zählt PHP-FPM ebenso wie Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Der höchste konkret demonstrierte Risikofall betraf Apache mod_php.
Für Betreiber zählt daher, welche PHP-Laufzeit eine Anfrage tatsächlich verarbeitet, auch wenn PHP in einem Container oder einem Herstellerpaket steckt. Eine installierte Anwendung allein sagt nicht, welche Laufzeit dahinter arbeitet.
Was AWS im Honeypot beobachtete
Ein Honeypot ist ein absichtlich exponiertes System, mit dem Angriffsversuche beobachtet werden. Amazon Threat Intelligence meldete einen Versuch gegen MadPot am 17. Oktober 2026, vier Tage vor der öffentlichen Bekanntgabe der PHP-Fehler.
Am 21. Oktober identifizierte AWS die frühesten Proof-of-Concept-Exploits gegen etwa 02:00 UTC. Ein Proof of Concept, kurz PoC, ist ein Machbarkeitsnachweis für einen Angriff. Zwischen 02:00 und 08:00 UTC registrierte AWS weitere Versuche gegen MadPot. Um 14:00 UTC endete die Offenlegungssperre; PHP veröffentlichte die Korrekturen an diesem Tag.
AWS zufolge blieb offen, ob die beobachteten Versuche auf realen Systemen erfolgreich gewesen wären. Die MadPot-Beobachtungen belegen damit Angriffsaktivität gegen den Honeypot, nicht einen bestätigten Einbruch bei einem realen Server. AWS’ Bericht zur MadPot-Telemetrie beschreibt diese zeitliche Abfolge.
Was die deutsche 16-Prozent-Zahl bedeutet
Check Point berichtete am 22. Oktober, dass 16 Prozent der deutschen Organisationen seit der Offenlegung mit Ausnutzungsversuchen konfrontiert waren. Die Kennzahl erfasst Organisationen mit registrierten Versuchen, keine bestätigten erfolgreichen Einbrüche.
Check Point meldete weltweit 10 Prozent und für Europa 14 Prozent. Nordamerika, Lateinamerika und APAC lagen jeweils bei 6 Prozent, Afrika bei 4 Prozent. Die Zahlen beziehen sich auf denselben versuchsbasierten Maßstab. Check Points Auswertung erläutert die Schätzung.
Welche PHP-Versionen die Fehler beheben
PHP veröffentlichte für vier aktive Versionszweige jeweils eine korrigierte Ausgabe. Die Versionen in der rechten Spalte beheben CVE-2026-109618 und CVE-2026-109619.
| PHP-Zweig | Erste korrigierte Version |
| PHP 8.5 | PHP 8.5.12 |
| PHP 8.4 | PHP 8.4.27 |
| PHP 8.3 | PHP 8.3.36 |
| PHP 8.2 | PHP 8.2.35 |
PHP 8.1 und ältere Zweige erhalten keine Upstream-Versionen mehr. Distributoren und Anbieter mit Langzeitpflege können Korrekturen zurückportieren. Wer ein solches Paket nutzt, sollte die dortige Sicherheitsmeldung und die tatsächlich laufende Paketversion heranziehen. Die PHP-Sicherheitsmitteilung führt die korrigierten Releases und die betroffenen Laufzeitmodelle auf.
Warum Einstellungen und VPN kein Update ersetzen
PHP beschreibt Konfigurationsänderungen als unvollständige Maßnahmen. memory_limit=-1, Begrenzungen für Anfragen und das Deaktivieren von session.upload_progress.enabled adressieren einzelne Angriffspfade. Das Deaktivieren dieser Einstellung blockiert bestätigte Session-Pfade von CVE-2026-109619, aber nicht jede Variante. Als vollständige Behebung nennt PHP ein Update auf eine korrigierte Version.
Ein VPN kann einschränken, wer einen Dienst erreicht, korrigiert aber nicht den PHP-Code. Auch ein abgeschotteter Dienst benötigt deshalb eine korrigierte Laufzeit.
PHP beschreibt außerdem einen separaten, als unwahrscheinlich eingestuften RCE-Pfad unter CVE-2026-115560. Er setzt eine besondere Konfiguration voraus: session.serialize_handler steht zunächst auf php_binary oder php_serialize, wird vor session_start() zur Laufzeit auf php umgestellt und Session-Upload-Fortschritt bleibt aktiviert. Dieser Pfad ist von den beiden PHP2Shell-Fehlern getrennt.
Ein Update entfernt nicht automatisch schädlichen Code, der bereits auf einem Server liegt. Check Point empfiehlt deshalb, nach dem Patchen auch unbekannte PHP-Dateien, ungewöhnliche Anfragen, unerwartete Systembefehle und unbekannte ausgehende Verbindungen zu untersuchen.
