Die Rede ist von PHP2Shell, einer kritischen PHP-Sicherheitslücke in zwei Teilen: CVE-2026-109618 und CVE-2026-109619, beide mit CVSS 9.2 bewertet. Sie stecken nicht in WordPress, Shopware oder einem anderen Framework, sondern in PHP selbst. Palo Alto Networks zählt weltweit über 22,6 Millionen erreichbare Instanzen, die potenziell betroffen sind.

Was ist passiert

• Was passiert ist: Zwei Fehler in der Speicherverwaltung von PHP erlauben es einem Angreifer, über einen präparierten HTTP-Request Code auf dem Webserver auszuführen. Ein Login ist nicht nötig, und die eigentliche Webanwendung muss dafür gar nicht erst starten.

• Wer betroffen ist: Jede PHP-Installation, die Webanfragen beantwortet, ob über Apache mit mod_php, PHP-FPM, php-cgi, FrankenPHP oder LiteSpeed. Fixes gibt es in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

• Wie ernst es ist: Exploit-Code ist öffentlich, arbeitet laut Rapid7 aber bisher nur unter sehr bestimmten Bedingungen zuverlässig. Angriffsversuche haben Amazon, Cloudflare und watchTowr beobachtet.

• Unsere Empfehlung: Außerhalb des normalen Patch-Zyklus aktualisieren, und zwar jetzt. Wo das nicht sofort geht, die Workarounds setzen und das System abschirmen. Wo PHP 8.1 oder älter läuft, das System vom Netz nehmen, bis es migriert ist.

Was hinter PHP2Shell steckt

Beide Lücken haben dieselbe Wurzel. PHP bricht bei bestimmten Fehlern, etwa wenn der Speicher ausgeht, die laufende Verarbeitung abrupt ab. Was danach aufgeräumt wird, ist aber nicht immer in einem sauberen Zustand.

CVE-2026-109618 betrifft genau diesen Speichermangel. Erreicht ein Request das Speicherlimit, während PHP seine internen Daten gerade erst aufbaut, arbeitet die anschließende Aufräumroutine mit halbfertigen Strukturen. Ein Angreifer kann diesen Zustand gezielt herbeiführen. Laut PHP-Advisory wurde die vollständige Codeausführung über HTTP gegen Apache mit mod_php nachgewiesen, und zwar mit den Standardlimits von PHP. Der Grund: mod_php räumt auch dann auf, wenn der Request-Start schon gescheitert ist. Bei PHP-FPM beendet sich der Worker in dieser Situation, ein vollständiger FPM-Exploit für diese Lücke ist bisher nicht bekannt.

CVE-2026-109619 nutzt aus, dass ein PHP-Worker viele Requests hintereinander bearbeitet. Bricht ein Fatal Error das Aufräumen ab, bleibt im Worker ein Verweis auf Speicher stehen, der bereits freigegeben ist. Der nächste Request im selben Worker greift darauf zu. Das PHP-Projekt hat zwei Wege bestätigt: die in PHP 8.5 standardmäßig aktiven Fehler-Backtraces (Codeausführung unter mod_php) und den Upload-Fortschritt von Sessions (Codeausführung unter mod_php und PHP-FPM). Der Upload-Fortschritt ist ab Werk eingeschaltet und läuft auch dann, wenn die Anwendung selbst gar keine Sessions nutzt. Neben Codeausführung nennt PHP hier auch das Auslesen von Speicher als bestätigte Folge.

Gemeldet haben die Lücken Forscher von Calif, Wiz, Areion und OpenAI. Calif und Wiz haben nach eigenen Angaben KI-Modelle bei der Suche eingesetzt.

Wie gefährlich es wirklich ist

Hier gehen die Einschätzungen auseinander, und das ist für die Priorisierung wichtig.

Das PHP-Projekt bewertet beide Lücken mit CVSS 4.0 9.2, also kritisch. Der Vektor sagt aber auch, dass der Angriff komplex ist und Voraussetzungen hat. Red Hat stuft die Lücke deshalb nur als „Important“ ein. Die Begründung: Ein zuverlässiger Angriff braucht präzise Manipulation des Heaps und gutes Timing, und Standard-RHEL setzt auf PHP-FPM statt mod_php. Dort sei Codeausführung „difficult in practice“.

Rapid7 hat die öffentlich kursierenden Exploits geprüft. Jeder funktioniert nur für eine bestimmte Kombination aus Betriebssystem, PHP-Version und Webserver, keiner wirkt breit zuverlässig. Gleichzeitig hat Datadog in seinem Labor einen funktionierenden Exploit gegen PHP 8.5.11 mit Apache und mod_php gebaut, der in rund drei Sekunden eine Shell lieferte.

Bei den Angriffen ist die Lage noch unscharf. Amazon meldet einen ersten Versuch am 17. Oktober und seit dem 21. Oktober Versuche, die auf mehrere Angreifergruppen hindeuten. watchTowr sieht seit dem 21. Oktober Ausnutzung in seinen Honeypots, Cloudflare spricht von „early attacks“. Rapid7 hat dagegen noch keine erfolgreiche Ausnutzung gesehen, nur Versuche. In den Katalog bekannt ausgenutzter Schwachstellen der US-Behörde CISA war die Lücke am 22. Oktober noch nicht aufgenommen.

Unsere Lesart: Dass ein Angriff kompliziert ist, schützt nicht lange. Die technischen Details sind öffentlich, mehrere Teams haben Exploits nachgebaut, und Exploits werden erfahrungsgemäß schnell besser. Die US-Behörde CISA und das britische NCSC raten, Systeme offline zu nehmen, wenn sie sich nicht sofort aktualisieren lassen. Das zeigt, wie ernst die Behörden das nehmen.

Welche Versionen betroffen sind

Zwei Dinge fallen dabei gern unter den Tisch. Erstens backporten Linux-Distributionen Sicherheitsfixes oft, ohne die Versionsnummer zu ändern. Ein php -v, das 8.2.28 meldet, kann also gepatcht sein, wenn das Paket der Distribution aktuell ist. Umgekehrt beweist eine neue Versionsnummer auf der Kommandozeile nichts über den PHP-Prozess, der tatsächlich die Website ausliefert. Zweitens steckt PHP an Stellen, an die man nicht sofort denkt: in Containern mit eigenem Interpreter, in Hosting-Paketen, in Admin-Oberflächen von Appliances. Palo Alto hat am 22. Oktober bestätigt, dass alle Versionen von PAN-OS und Panorama betroffen sind, ein Fix stand da noch aus.

Was die Workarounds leisten und was nicht

Das PHP-Projekt ist hier ungewöhnlich deutlich: Die Workarounds verringern das Risiko für bekannte Angriffswege, machen eine Installation aber nicht sicher. Nur das Update ist eine vollständige Lösung. Wer nicht sofort aktualisieren kann, sollte die Maßnahmen trotzdem setzen, denn sie verbauen die beiden bisher bestätigten Angriffswege.

Gegen CVE-2026-109619:

• session.upload_progress.enabled=0

• unter PHP 8.5 zusätzlich fatal_error_backtraces=0

Gegen CVE-2026-109618:

• memory_limit=-1, so gesetzt, dass Anwendungen den Wert nicht überschreiben können

• post_max_size begrenzen: 8M ohne Datei-Uploads, 32M mit Uploads, upload_max_filesize jeweils darunter

• am Webserver oder Reverse Proxy die Größe von Request-Bodies, die Zahl der Felder und Multipart-Teile sowie die Verschachtelungstiefe begrenzen

Für einen PHP-FPM-Pool sieht das etwa so aus:

; /etc/php/8.x/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; nur PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off

; /etc/php/8.x/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; nur PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off

; /etc/php/8.x/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; nur PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off

Bei Apache mit mod_php gehören dieselben Werte als php_admin_value bzw. php_admin_flag in die Server- oder VirtualHost-Konfiguration.

Drei Details entscheiden darüber, ob das wirkt. Die Einstellungen müssen greifen, bevor PHP den Request verarbeitet. ini_set() im Anwendungscode und .user.ini-Dateien kommen zu spät. Danach müssen alle Worker neu gestartet werden, damit keiner mit den alten Einstellungen weiterläuft. Und memory_limit=-1 hebt die Speicherbremse von PHP auf, deshalb gehört eine Grenze auf Ebene von Container oder cgroup dazu, damit ein einzelner Request nicht den ganzen Server lahmlegt. Die Betriebssystem-Limits RLIMIT_AS und RLIMIT_DATA sind dafür ausdrücklich ungeeignet, weil sie genau den verwundbaren Fehlerpfad auslösen können.

Fehlermeldungen auszublenden, etwa über display_errors oder error_reporting, hilft laut PHP nicht. WAF-Regeln, wie Cloudflare sie für alle Tarife ausgerollt hat, sind eine sinnvolle zusätzliche Schicht, aber nach Cloudflares eigener Aussage nur eine Überbrückung.

So gehen Sie vor

1. Inventar aufstellen. Jede Website, jeder Shop, jedes Intranet, jede Admin-Oberfläche mit PHP gehört auf die Liste. Notieren Sie Version, Herkunft (Distributionspaket, Container-Image, selbst kompiliert, Hoster), SAPI und wer für Updates zuständig ist. Prüfen Sie den PHP-Prozess, der die Website ausliefert, nicht nur die Kommandozeile.

2. Internetexponierte Systeme zuerst. Was öffentlich erreichbar ist und mit mod_php läuft, hat die höchste Priorität. Ein Scanner hilft beim Gegencheck, Tenable, Rapid7 und Searchlight Cyber haben passende Prüfungen veröffentlicht.

3. Aktualisieren. Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, bzw. auf den gepatchten Paketstand Ihrer Distribution. Bei Debian, Ubuntu oder RHEL zeigt dpkg -l | grep php bzw. rpm -qa | grep php den installierten Stand, die zugehörige Sicherheitsmeldung der Distribution sagt, ob er den Fix enthält. Danach alle Worker neu starten.

4. Wo das Update nicht sofort geht: Workarounds plus Abschirmung. Einstellungen wie oben setzen, Worker neu starten, das System hinter eine WAF oder ein VPN stellen. Bei PHP 8.1 und älter das System vom Netz nehmen, bis es migriert ist.

5. Hoster und Hersteller fragen. Bei Managed Hosting, SaaS und Appliances mit PHP-Oberfläche liegt das Update nicht bei Ihnen. Fragen Sie aktiv nach dem Stand und lassen Sie sich die Antwort schriftlich geben.

6. Rückblickend prüfen. Amazon empfiehlt, Untersuchungen mindestens ab dem 17. Oktober anzusetzen. Auffällig sind laut Datadog Speicherfehler mit dem Zusatz „in Unknown on line 0“, Segfaults der Webserver-Prozesse und vor allem ein Webserver-Prozess, der eine Shell startet. Wichtig: Fehlen solche Einträge, heißt das nicht, dass nichts passiert ist.

7. Den Rest aufräumen. PHP 8.2 verliert am 31. Dezember 2026 den Support. Wer jetzt ohnehin anfassen muss, plant die Migration auf 8.4 oder 8.5 gleich mit ein.

Fazit

• Das Update ist der einzige vollständige Schutz. Die Workarounds kaufen Zeit, mehr nicht. PHP selbst sagt das unmissverständlich.

• Die Angriffe sind schwierig, aber nicht theoretisch. Exploit-Code ist öffentlich, mehrere Teams haben ihn nachgebaut, und Angriffsversuche laufen. Am meisten gefährdet sind öffentlich erreichbare Systeme mit Apache und mod_php.

• Die eigentliche Arbeit ist das Inventar. Wer weiß, wo überall PHP läuft, ist mit dem Patchen schnell durch. Wer es erst herausfinden muss, sollte heute damit anfangen.

Sie wissen nicht genau, auf wie vielen Ihrer Systeme PHP läuft und in welchem Stand? Wir prüfen Ihre Webserver und internetexponierten Anwendungen, spielen die Updates ein oder setzen die Workarounds, wo ein Update nicht sofort möglich ist, und sehen in den Logs nach, ob es seit dem 17. Oktober Auffälligkeiten gab. Sprechen Sie uns an.