Behörden schalten Online-Angebote ab, Betreiber installieren Notfallupdates, Bürger erreichen digitale Dienste nicht mehr. PHP2Shell hat bereits Folgen für den Alltag. Der Landkreis Reutlingen meldete am 22. Oktober die vorsorgliche Abschaltung verschiedener Online-Angebote. Das BSI warnt mit Stufe 3 / Orange: Betreiber müssen unverzüglich handeln, erhebliche Einschränkungen des Regelbetriebs sind möglich. Auch Tagesschau und Tagesthemen berichteten über die Lücken und Abschaltungen.
Die Dienste wurden vorsorglich abgeschaltet, um Einbrüche zu verhindern. Ausfälle gibt es dadurch trotzdem. Wer die Lage nur als nächsten Eintrag auf der Patchliste behandelt, übersieht diesen betrieblichen Druck.
PHP veröffentlichte am 21. Oktober 2026 Sicherheitsupdates gegen die beiden kritischen Lücken. Angreifer können darüber ohne Anmeldung Speicher auslesen und unter den nachgewiesenen Bedingungen eigenen Code auf dem Server ausführen. Weniger als 24 Stunden nach dem formalen Embargoende hatten wir öffentlichen Exploit-Code im Labor geprüft, die Angriffskette gegen eine festgelegte WordPress-Umgebung nachvollzogen und bis zum bestätigten Administratorzugang erweitert.
PHP steckt aber auch in NAS-Anwendungen, Verwaltungsoberflächen und Gebäudesteuerungen. Hinter einem Webpanel kann die Managementebene einer Firewall stehen, eine Gebäudesteuerung oder ein zentraler Dienst für mehrere Standorte. Während Betreiber noch suchen, wo überall PHP läuft, können Agenten bereits bei der Anpassung von Exploits helfen.
Was bei PHP2Shell kaputtgeht
Die PHP-Laufzeit führt den Anwendungscode auf dem Server aus. In dieser Software sitzen die beiden Fehler. Ein Update von WordPress, einem Plugin oder einer anderen Anwendung ersetzt die Laufzeit nicht automatisch.
CVE-2026-109618 betrifft den Abbruch wegen Speichermangels, auf Englisch Out of Memory, kurz OOM. PHP kann dabei unvollständig vorbereitete Datenstrukturen zurücklassen. Beim anschließenden Aufräumen behandelt es sie trotzdem als vollständig und gültig.
Bei CVE-2026-109619 können in einem weiterlaufenden PHP-Prozess Verweise auf bereits freigegebenen Speicher stehen bleiben. Eine spätere Anfrage benutzt dann diese ungültigen Verweise. Der Fehler kann also über die ursprüngliche Anfrage hinauswirken.
Die Folgen reichen vom Auslesen des Prozessspeichers bis zur Ausführung fremden Codes über das Netzwerk. Letzteres heißt Remote Code Execution, kurz RCE. Schon ein Speicherleck ist gefährlich: Im Speicher können Zugangsdaten und andere Geheimnisse liegen. Ein Angreifer braucht keine Shell, also keinen direkten Kommandozugang, um damit Schaden anzurichten.
Fremder Code läuft zunächst mit den Rechten des Webworkers, des Prozesses, der PHP-Anfragen bearbeitet. Das sind nicht automatisch volle Betriebssystemrechte, auch Root-Rechte genannt. Für den Zugriff auf Anwendungskonfigurationen und Datenbanken oder die Übernahme einer Anwendung können die vorhandenen Rechte aber schon reichen.
Ob ein Exploit funktioniert, hängt auch davon ab, wie PHP gebaut wurde, welche Erweiterungen es enthält und wie es in den Webserver eingebunden ist. Apache mit dem PHP-Modul mod_php und der separate Prozessmanager PHP-FPM verhalten sich bei manchen Fehlern unterschiedlich. Einige Angriffswege beginnen bereits beim Einlesen einer Anfrage, bevor Anwendungscode läuft. Ein Loginformular schützt diesen Schritt nicht. Umgekehrt ist ein gescheiterter Exploitversuch kein Sicherheitsnachweis.
Bei CrowdStrikes demonstriertem Angriff über einen URL-encoded-POST-Körper, also herkömmlich codierte Formulardaten, kommt es auf das Verhältnis zweier Einstellungen an. Näherungsweise gilt dafür memory_limit < 4 × post_max_size. Die PHP-Standardwerte memory_limit = 128M und post_max_size = 8M erfüllen diese Bedingung nicht. Größere zulässige POST-Körper können sie erfüllen.
Das betrifft nur diesen Angriffsweg. Das PHP-Advisory dokumentiert vollständige mod_php-RCE auch mit den standardmäßigen PHP-Eingabe- und Speichergrenzen. Bei CVE-2026-109618 bleiben andere Fehler bei der Speicherzuteilung und OOM-Auslöser in Anwendungen möglich. Bei CVE-2026-109619 können auch fatale Fehler und Zeitüberschreitungen problematische Zustände hinterlassen. Die PHP-Sicherheitsmeldung erläutert die Auslöser und begrenzten Gegenmaßnahmen. Ein Vergleich der Einstellungen ersetzt das Update nicht.
WordPress, Drupal und Joomla waren Demonstrationsziele der Forscher. Verwundbar ist PHP selbst, wie die koordinierte PHP2Shell-Seite klarstellt. Auch korrekt programmierte Anwendungen laufen auf der fehlerhaften Laufzeit. Mit unserem früheren wp2shell-Follow-up sollte man den Fall deshalb nicht verwechseln: Dort ging es um eine andere, WordPress-spezifische Angriffskette.
Der Vergleich mit Log4Shell
Ende 2021 stellte Log4Shell Betreiber vor ein ähnliches Problem. Betroffen war Log4j, eine Java-Bibliothek zum Protokollieren von Ereignissen und Fehlermeldungen. Sie steckte in zahlreichen Anwendungen und Produkten. Betreiber mussten erst herausfinden, wo die verwundbare Bibliothek überhaupt lief. EU-Kommission, ENISA, CERT-EU und die nationalen CSIRTs warnten gemeinsam.
Bei der von Apache als CVE-2021-44228 dokumentierten Lücke konnten präparierte Inhalte einer Logmeldung Codeausführung auslösen. Die Bibliothek behandelte bestimmte Zeichenfolgen nicht nur als Text. Eine Nachladefunktion konnte darüber Inhalte eines Angreifers abrufen und unter verwundbaren Bedingungen fremden Code ausführen. Die Eingabe musste dafür bis zur fehlerhaften Logging-Komponente gelangen. Diese musste nicht selbst aus dem Internet erreichbar sein: Auch ein nachgelagertes System konnte betroffen sein, wenn es die Eingabe protokollierte.
Bei PHP2Shell liegt der Fehler dagegen in der Laufzeit selbst. Eine zusätzliche Logging-Bibliothek ist nicht nötig; auch eine einfache Anwendung kann betroffen sein. Nach der Codeausführung kann ein Angreifer die Verbindungen und Rechte des Anwendungsprozesses missbrauchen. Eine interne Datenbank oder ein Fachverfahren erhält dann womöglich manipulierte Daten von einem eigentlich berechtigten Absender. Dazu muss dort kein fremder Code laufen. Daten und davon abhängige Abläufe können trotzdem Schaden nehmen.
Gemeinsam ist beiden Fällen die schwierige Bestandsaufnahme: Viele unterschiedliche Systeme verwenden dieselbe verwundbare Basiskomponente. Updates müssen auch Herstellerpakete und Gerätefirmware erreichen. Zu PHP2Shell fordern EU-Kommission, ENISA, CERT-EU, Europol EC3 und das CSIRTs-Netzwerk ebenfalls sofortige Maßnahmen. Die Warnung nennt ausdrücklich Produkte, deren PHP-Unterbau von außen nicht erkennbar ist.
Neue Gefahr für alte Software
Die PHP2Shell-Forschung nennt betroffene Releases bis zurück zu PHP 5.4. PHP 5.4.0 erschien laut offiziellem Veröffentlichungsarchiv am 1. März 2012. Zum Vergleich: Log4j 2.0-beta9, die früheste von der klassischen Log4Shell-Lücke betroffene Version, erschien am 14. September 2013. Das sind die Veröffentlichungsdaten betroffener Versionen, nicht die Geburtsdaten der Projekte.
Damit können auch Anwendungen akut gefährdet sein, die seit Jahren unverändert laufen. Sie brauchen keinen neuen Programmierfehler. Es reicht, dass sich ihre vorhandene PHP-Laufzeit nun nachweislich angreifen lässt. Bei gepflegten Systemen folgt ein Notfallupdate. Bei aufgegebenen Anwendungen oder Geräten beginnt erst die Suche nach jemandem, der noch eine Korrektur liefern kann. Dass die Software funktioniert, heißt nicht, dass sich noch jemand um ihre Sicherheit kümmert.
PHP endet nicht beim Webhosting
Wer nur die Websites seiner Organisation abhakt, lässt einen Teil der Infrastruktur ungeprüft.
Palo Alto Networks bestätigt die Betroffenheit von PAN-OS und Panorama, der Firewall-Software und ihrer zentralen Verwaltung. Bei PAN-OS geht es um die Management-Weboberfläche einschließlich XML-API, also auch Verwaltungszugriffe durch andere Programme. Der Hersteller bewertet die Folgen als möglichen Ausfall oder Störung des Dienstes. Eine technische Erklärung, warum weitergehende Folgen ausgeschlossen seien, liefert das Advisory nicht. Die Begrenzung bleibt damit eine Herstellerbewertung. Eine erfolgreiche Firewall-Übernahme ist ebenfalls nicht belegt. Prüfen müssen Betreiber die Managementebene dennoch.
Bei NAS-Systemen, also Netzwerkspeichern, kommt es auf die einzelne Komponente an. Synology nennt betroffene PHP-Pakete sowie Mail Station und Synology Calendar. Davon unterscheidet der Hersteller das im Betriebssystem eingebaute PHP, für das er keine externe Angriffsfläche sieht. „Synology betroffen“ bedeutet deshalb nicht automatisch, dass die DSM-Anmeldung verwundbar ist. Mehrere Komponenten auf demselben Gerät brauchen getrennte Prüfungen.
Auch in der Gebäudeautomation steckt PHP. Das Datenblatt des Computrols CBAS-Web-Servers nennt Apache, MySQL und PHP 8.3.6 oder neuer. Techniker steuern darüber die Anlage im Browser; Nutzer können zusätzliche Betriebszeiten buchen. Dieser Server gehört zum Gebäudebetrieb. Welche PHP-Version auf einem konkreten Gerät installiert ist, verrät die Mindestangabe im Datenblatt nicht.
Mindz IT beschreibt ein cloudbasiertes Gebäudemanagement mit PHP-8.0-/Laravel-Backend. Es überwacht und verwaltet verteilte Gebäude über deren programmierbare Steuerungen, einschließlich Gerätezeitplänen. Die undatierte Projektbeschreibung belegt den Aufbau, nicht den heutigen Patchstand eines laufenden Dienstes. Beim Hausautomationsanbieter Jeedom ist die Reaktion dagegen dokumentiert: Er meldete am 21. Oktober die Aktualisierung seiner eigenen Online-Dienste auf korrigierte PHP-Versionen.
Diese Beispiele zeigen, wo Betreiber suchen müssen. Sie sind keine Liste durchweg verwundbarer Geräte. Auch die Produktklasse allein sagt wenig: Fortinet führt FortiOS ausdrücklich als nicht betroffen, während andere Produkte noch untersucht werden. Entscheidend sind die tatsächlich eingesetzte PHP-Komponente und ihr Patchstand.
Die Ausnutzung ist auch nicht auf x86-64-Server beschränkt. CrowdStrike berichtet von eigenem Exploit-Code für x86-64 und ARM. In der getesteten Apache-Konfiguration mit mod_php und dem Prozessmodell Prefork funktionierte er auch nach Worker-Neustarts zuverlässig. Auf ARM umging das Team allein über HTTP-Anfragen zudem ASLR, die zufällige Verteilung von Speicheradressen. Das ist ein weiterer Grund, PHP auch in anderen Geräteklassen zu prüfen, einschließlich Gebäudeautomation. Einen erfolgreichen Angriff auf eine konkrete Gebäudesteuerung belegt der Bericht nicht.
Heise security fordert ebenfalls die Prüfung von NAS, Appliances und Routern und nennt zusätzlich Security-Appliances und Loadbalancer mit PHP-Unterbau. Auch dort dient die Herstellerliste der Bestandsaufnahme, nicht als Nachweis für jedes einzelne Produkt.
Heise weist außerdem auf interne Anwendungen und Geräte hin. Wer über einen anderen Weg ins Netz gelangt ist, kann erreichbare, verwundbare PHP-Oberflächen für weitere Zugriffe oder eine dauerhafte Präsenz nutzen. Ein nur intern erreichbares Webpanel ist weniger exponiert, braucht aber weiterhin Updates und enge Zugriffsrechte. Bei einer zentralen Gebäudesteuerung gehört dazu die Frage, welche Anlagen, Zugangsdaten und Verwaltungsschnittstellen sie erreichen kann. Ihre Übernahme könnte mehrere Standorte treffen.
Zusätzliche Schutzmaßnahmen müssen den jeweiligen Angriffsweg tatsächlich abdecken. Die bloße Hoffnung, ein internes Netz oder ein vorgeschalteter Filter werde es schon richten, ist keine Entwarnung.
Eine gewisse Ironie bleibt für die kriminelle Dienstleistungswirtschaft: Auch Anbieter fertiger Phishing- und anderer Cybercrime-Dienste brauchen Portale und Backends. Verwundbares PHP wird nicht sicherer, weil das Geschäftsmodell darin besteht, andere Leute zu kompromittieren. Bulletproof Hosting ist schließlich kein Speichersicherheitskonzept.
KI bei der Entdeckung und der Patchprüfung
Die PHP Foundation beschreibt die Vorgeschichte bis zum Audit von 2024. Ein verwandtes OOM-Problem war bekannt, seine Ausnutzbarkeit aber nicht nachgewiesen. Erst die späteren Berichte von Calif, OpenAI und Wiz zeigten die volle Tragweite. Einen Fehler im Code zu kennen und daraus einen funktionierenden Angriff zu entwickeln, sind unterschiedliche Arbeitsschritte.
Calif beschreibt die Forschung als Zusammenspiel von Fachwissen und Agentenarbeit. Der Forscher kannte ältere PHP-Schwachstellen und hatte eine Vorstellung davon, wo sich eine Suche lohnen würde. Der Agent half, die Codepfade zu verfolgen und weitere Varianten zu finden. Nach Angaben von Calif waren für die anfängliche Entdeckung weder eine besondere Testumgebung noch exklusiv verfügbare Modelle nötig.
OpenAI nennt das bei Calif eingesetzte Modell: Nach Darstellung des Anbieters entdeckte Calif mit GPT-5.6 Sol eine der kritischen Schwachstellen. Wiz entdeckte und meldete unabhängig davon beide Fehler.
Wiz arbeitete nach eigenen Angaben mit Wiz Atlas, Gemini 4 Argon und GPT-5.6 Sol. Das Team hebt den Beitrag von Gemini 4 Argon bei der Entdeckung, Exploit-Entwicklung, Angriffserkennung und Prüfung des Patches hervor.
Raluca Ada Popa, Leiterin für Gemini-Sicherheit bei Google DeepMind, betont im Wiz-Bericht den Nutzen für Verteidiger: KI habe geholfen, die komplexen Fehler zu finden und zu beheben. Wiz beschreibt zugleich, wie Modelle die Anpassung von Exploits an andere PHP-Versionen, Einstellungen und Speicherlayouts erleichtern. Wer solche Arbeit beschleunigt, hilft also nicht zwangsläufig nur den Verteidigern. Zur autorisierten Forschung gehörten hier bereits funktionierende Exploits.
Das sind Aussagen der beteiligten Forscher und Anbieter, kein unabhängiger Modellvergleich. Die PHP Foundation betont außerdem, dass Menschen die Entscheidungen treffen und an jedem Patch arbeiten. Die Modelle nehmen den Verantwortlichen diese Arbeit nicht ab.
KI bei der Ausnutzung: Unser Laborversuch
Unser Ausgangspunkt war öffentlicher GitHub-Code. Die Dokumentation beschrieb bereits einen WordPress-RCE-Nachweis für einen bestimmten PHP-Build. Wir haben weder die Lücke neu entdeckt noch den Exploit-Kern aus den Sicherheitsmeldungen entwickelt.
Unser Security-Agentensystem prüfte den Code und rekonstruierte die Angriffskette im isolierten Labor. Das Ziel war eine WordPress-Installation auf PHP 8.4.7 als Apache-Modul mod_php. Zuerst gelang das Auslesen von Speicher, dann die Codeausführung als Webworker. Darauf aufbauend wurde ein neuer WordPress-Administrator angelegt. Die Anmeldung an der Verwaltungsoberfläche funktionierte.
Der Administratorzugang war also das Ergebnis der PHP-Ausnutzung, nicht deren Voraussetzung. Ein Plugin-Upload diente nicht als Einstieg.
Die Gegenprobe mit PHP 8.4.27 stoppte die Kette schon beim Speicherleck. Der folgende Schritt zur Kommandoausführung wurde nicht mehr ausgelöst. Der Abschnitt stützt sich auf unseren dokumentierten Laborbericht. Eine erneute Durchführung der Versuche oder eine zusätzliche unabhängige Prüfung der privaten Rohartefakte erfolgte für diesen Artikel nicht.
Das formale Embargo endete am 21. Oktober um 14:00 UTC, also 16 Uhr deutscher Sommerzeit. Unser dokumentiertes Laborergebnis lag weniger als 24 Stunden danach vor. Prüfung, Rekonstruktion und Erweiterung beschäftigten uns innerhalb der Arbeitssitzung für Minuten bis Stunden. Die Zeitangabe ist keine gemessene Neuentwicklungsdauer und bedeutet nicht, dass vorher noch keine Informationen verfügbar waren.
AWS dokumentiert einen PHP2Shell-Ausnutzungsversuch vom 17. Oktober gegen sein MadPot-Honeypotnetz. Auch öffentliche PoCs, also Machbarkeitsnachweise, und weitere Versuche lagen vor dem formalen Embargoende vor. Die Telemetrie belegt Versuche, keine erfolgreichen Einbrüche in reale Systeme. Nach dem Release erschienen laut AWS binnen Stunden weitere öffentliche Exploits, die fast sofort gegen die Sensoren eingesetzt wurden.
Unser Labor zeigt, wie wenig zusätzliche Arbeit zwischen vorhandenem Exploit-Code und einem bestätigten Anwendungsschaden liegen kann. Bei ähnlichem PHP-Unterbau lässt sich ein Teil des Einstiegs wiederverwenden. Andere Builds, Erweiterungen, Ausführungsmodelle und Speicherlayouts können weitere Anpassungen verlangen. Agenten können dabei Versuche wiederholen, Fehlschläge untersuchen und Ergebnisse auswerten. Dafür muss kein Mensch ununterbrochen vor dem Bildschirm sitzen.
Auch die Vorauswahl möglicher Ziele ist automatisierbar. Shodan erfasst Dienstbanner und Versionsinformationen, die erreichbare Dienste nach außen melden. Solche Angaben können veraltet sein oder zurückportierte Patches nicht erkennen lassen. Sie beweisen keine Verwundbarkeit, erleichtern aber die Suche nach möglichen Zielen.
AWS nennt KI-gestützte Analyse als Grund dafür, dass mehr Akteure schneller von einem Patch oder einer Sicherheitsmeldung zum Exploit kommen. Ob die konkret beobachteten Akteure KI nutzten, belegen ihre Anfragen nicht. Unser Labor zeigt jedoch einen solchen KI-gestützten Arbeitsablauf in der Praxis. Betreiber sollten nicht darauf setzen, dass Angreifer nach einer Sicherheitsmeldung erst eine Woche Anlauf brauchen.
Wer eine erreichbare, verwundbare PHP-Umgebung ungepatcht betreibt, wettet darauf, dass der passende Bot später kommt als das eigene Wartungsfenster. Nicht jeder Versuch gelingt. Daraus wird trotzdem kein Schutzkonzept.
Eine absurde Randbeobachtung blieb uns außerdem: Bei der RCE-Arbeit hatten wir damit gerechnet, dass die regulären Schutzmechanismen des Modellanbieters eingreifen. Das passierte nicht. Gebremst wurden wir erst beim Auftrag: „Wir schreiben einen Artikel, sichte bitte die Quellen.“ Derselbe Anbieter, weiterhin die regulären Guardrails, keine Variante mit reduzierten Schutzmechanismen. Die Angriffskette ließ sich im Labor ausarbeiten. Die anschließende Quellenrecherche scheiterte zunächst am Sicherheitsfilter.
Patchen, neu starten, den tatsächlichen Stand prüfen
Die ersten korrigierten PHP-Versionen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Maßgeblich sind die offiziellen PHP-Empfehlungen und die Sicherheitsmeldungen des jeweiligen Distributions- oder Geräteherstellers. Dieser kann den Fix in ein älteres Paket übernehmen, ohne dessen sichtbare PHP-Versionsnummer entsprechend zu ändern. Für solche Backports braucht es einen belegten Paket- oder Firmwarestand. Ein altes Paket ist nicht sicher, nur weil noch Support für das Gerät verkauft wird.
Nachtrag vom 23. Oktober 2026: Das PHP-Projekt weist auf einen zusätzlichen, seltenen Session-Sonderfall hin (CVE-2026-115560). Er setzt voraus, dass eine Anwendung session.serialize_handler zunächst als php_binary oder php_serialize konfiguriert und dann zur Laufzeit mit ini_set() vor session_start() auf php umstellt. Zugleich muss die Upload-Fortschrittsverfolgung aktiviert sein. Bis zum nächsten regulären Bugfix-Release empfiehlt PHP, session.upload_progress.enabled=0 zu setzen. Wer diese bereits zuvor empfohlene Maßnahme umgesetzt hat, sollte sie beibehalten; weitere Schritte sind für diesen Sonderfall dann nicht nötig. Anwendungen ohne Laufzeitwechsel des Session-Serialisierungshandlers können die Funktion laut PHP aktiviert lassen. Die oben genannten Sicherheitsversionen beheben die beiden ursprünglichen PHP2Shell-Lücken; der zusätzliche Hinweis ist gesondert zu prüfen.
Das Update muss alle betroffenen PHP-Installationen erreichen. Anschließend müssen Apache, PHP-FPM und andere langlebige PHP-Worker neu starten. Ein neues Paket hilft nicht, wenn die alten Prozesse weiterlaufen. Zu prüfen ist die PHP-Version, die tatsächlich Webanfragen verarbeitet. php -v in der Konsole kann eine andere Installation anzeigen. Mehrere PHP-Versionen auf einem Rechner und getrennte Container brauchen jeweils eine eigene Prüfung.
Bei Geräten, die Betreiber nicht selbst aktualisieren können, muss der Hersteller Auskunft geben: Welche PHP-Komponente ist eingebaut, welchen Patchstand hat sie und wann kommt die Korrektur? Ohne Sicherheitswartung bleiben gegebenenfalls nur Isolation oder Ersatz. Die Zuständigkeit des Lieferanten macht die Lücke nicht kleiner.
Ein Patch entfernt auch keine bereits angelegten Konten oder Dateien und macht gestohlene Zugangsdaten nicht unbrauchbar. Zuvor erreichbare Systeme müssen deshalb auf Einbrüche geprüft werden. Nach der AWS-Chronologie sollte die Untersuchung mindestens bis zum 17. Oktober zurückreichen, nicht erst bis zur öffentlichen Sicherheitsmeldung. Ansatzpunkte sind auffällige Upload-Anfragen, Speicherfehler, Worker-Abstürze, unerwartete Prozessstarts und Änderungen an Anwendungen oder privilegierten Konten. Solche Spuren können andere Ursachen haben. Ihr Fehlen beweist umgekehrt keine Sicherheit.
In CrowdStrikes getesteter Apache-mod_php-Konfiguration blieb der Worker bei erfolgreicher Ausnutzung stabil. Der Server antwortete mit HTTP 200, die Anwendungslogs waren unauffällig. Im Webserver-Fehlerprotokoll stand ein Speicherlimitfehler mit in Unknown on line 0. Dieser Eintrag ist ein Prüfhinweis, kein Beweis für eine Kompromittierung.
Wenn das Update nicht sofort möglich ist
Die koordinierte PHP2Shell-Seite und die Handlungsempfehlungen des PHP-Projekts beschreiben Zwischenmaßnahmen. Sie decken einzelne Angriffswege ab oder begrenzen deren Folgen. Keine ersetzt das Update. Betreiber müssen die Einstellungen administrativ vorgeben, auf Nebenwirkungen prüfen und die betroffenen Worker neu starten. Ein blockierter Angriffsweg kann auch einen benötigten Upload oder eine andere Funktion unterbrechen.
- Anfragegröße und Verschachtelung begrenzen. Ein kleineres
post_max_sizeund ein passendesmax_input_nesting_levelerschweren bestimmte Wege zum Speichermangel.post_max_sizebegrenzt aber nicht jede tatsächlich eingelesene Anfrage zuverlässig. Webserver oder Proxy sollten zusätzlich die dekodierte Anfragegröße begrenzen, also die Datenmenge nach der Dekodierung. Dasselbe gilt für die Zahl der Eingabefelder, Multipart-Teile und Header je Teil. Diese Grenzen müssen auch greifen, wenn im HTTP-HeaderContent-Lengthkeine brauchbare Längenangabe steht. - Nicht benötigte Upload-Fortschrittsverfolgung abschalten.
session.upload_progress.enabled = 0muss schon vor dem Einlesen der Anfrage gelten, etwa überphp.ini, die FPM-Pool- oder Serverkonfiguration.ini_set()im Anwendungscode oder eine FPM-.user.inigreifen dafür zu spät. Die Maßnahme blockiert die bestätigten Session-Angriffswege, nicht alle Varianten. - Fehlerausgabe einschränken.
display_errors = 0hält PHP-Fehlermeldungen von entfernten Nutzern fern. Die interne Verarbeitung, die CVE-2026-109619 auslösen kann, läuft trotzdem weiter. Unter PHP 8.5 blockiertfatal_error_backtraces = 0den bestätigten Angriff über Rückverfolgungen bei fatalen Fehlern, aber keine anderen Varianten. Verborgene Fehlermeldungen bedeuten keine behobenen Speicherfehler. - PHP-FPM-Worker häufiger ersetzen. Ein niedrigeres
pm.max_requestsbegrenzt die Folgeanfragen an denselben Worker. Das erschwert mehrstufige Angriffe, die beschädigten Zustand weiterverwenden. Wenn die Leistungseinbußen vertretbar sind, nennt das Advisorypm.max_requests = 1als Zwischenmaßnahme. Angriffswege ohne Worker-Wiederverwendung bleiben davon unberührt. - Worker-Rechte begrenzen. SELinux- oder AppArmor-Regeln können festlegen, welche Dateien und Programme ein kompromittierter Worker erreichen darf. Das begrenzt mögliche Schäden, verhindert aber nicht jede Ausnutzung oder jedes Speicherleck.
Besondere Vorsicht verlangt memory_limit = -1, also das Abschalten des PHP-Speicherlimits. Keine andere Konfiguration und auch die Anwendung darf anschließend wieder ein endliches Limit setzen. Die Einstellung kann bestimmte OOM-Angriffswege unterbrechen. Den Speichermangel muss dann aber das Betriebssystem behandeln. Dabei können Prozesse und laufende Anfragen enden, je nach Prozessgruppe auch weitere Worker oder der ganze Dienst.
Die Empfehlung verbindet diese Änderung deshalb mit Betriebssystemgrenzen wie cgroup v2 memory.max, um den Speicherverbrauch der PHP-Prozesse einzudämmen. Auch das garantiert nicht, dass Fehler bei der Speicherzuteilung ausbleiben. Die Grenze soll vor allem Ausfälle und Schäden begrenzen. RLIMIT_AS und RLIMIT_DATA sind kein geeigneter Ersatz: Sie können dieselben verwundbaren Fehlerpfade auslösen. Ein blind ausgerollter Einzeiler wäre hier schlechte Betriebsarbeit.
Zusätzlich sollten Betreiber die Erreichbarkeit beschränken, besonders bei öffentlich zugänglichen Verwaltungsoberflächen. Eine Web Application Firewall, kurz WAF, kann bestimmte Anfragen abfangen, bevor sie PHP erreichen. Wer sich vorübergehend darauf stützt, muss prüfen, ob der Schutz den jeweiligen Angriffsweg tatsächlich abdeckt.
Die Lücke bleibt länger als die Schlagzeile
Weitere Produktmeldungen und später entdeckte Einbrüche sind zu erwarten: PHP ist weit verbreitet, Herstellerprüfungen laufen noch, und Angriffsversuche sind bereits dokumentiert. Besonders leicht geraten Geräte aus dem Blick, deren Betreiber gar nicht wissen, dass darin PHP läuft.
In „Der Angreifer gibt nur noch den Auftrag“ ging es bereits darum, praktische Angriffsschritte an Agenten zu delegieren. Bei PHP2Shell sehen wir, wie Menschen und Modelle alte Fehler untersuchen, ihre Ausnutzbarkeit nachweisen und öffentliche Forschung schnell in funktionierende Werkzeuge überführen. Eine garantierte Schonfrist für die Verteidiger gibt es nicht.
PHP2Shell folgt der Laufzeit, nicht dem Etikett auf dem Gerät. Wer nur seine Websites patcht, kann deshalb fertig sein und trotzdem noch ein Problem haben.
Titelbild: KI-generiertes Symbolbild zu Betriebseinschränkungen und Notfallwartung wegen PHP2Shell. Bild in voller Auflösung öffnen.