PHP2Shell: Der PHP-Bug, mit dem jeder Code auf Ihrem Server ausführen kann (jetzt patchen)

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Notfall-Releases für zwei kritische Fehler, die es einem nicht authentifizierten Angreifer ermöglichten, Code auf einem Webserver auszuführen. Das Paar wird unter CVE-2026-109618 und CVE-2026-109619 geführt und trägt den Namen PHP2Shell. Beide erreichen 9,2 im CVSS v4.0, beide treffen jedes PHP-Setup, das HTTP bedient, und Amazons Honeypots verzeichneten am 17. Oktober Ausnutzungsversuche – vier Tage, bevor der Patch existierte.

PHP läuft auf 69,3 % der Websites, deren serverseitige Sprache bekannt ist (W3Techs). Wenn Sie eine PHP-API, ein Laravel- oder Symfony-Backend, eine WordPress-Seite oder ein Container-Image mit integriertem PHP betreiben, betrifft Sie das.

Dieser Leitfaden behandelt, was die Fehler bewirken, welche Versionen betroffen sind, wie Sie Ihre Server prüfen, was die Gegenmaßnahmen wirklich bringen und wie Sie nachweisen, dass Ihre API nach dem Patchen noch funktioniert.

TL;DR

Was PHP2Shell tatsächlich ist

Beide Fehler haben eine gemeinsame Ursache: PHP kann seinen Speicher in einem beschädigten Zustand hinterlassen, wenn eine Anfrage abnormal endet, und der Aufräumcode vertraut dann auf diesen beschädigten Zustand.

CVE-2026-109618: Korruption bei Speichererschöpfung während des Request-Starts. Wenn PHP Formulardaten in $_POST parst, erhöht der Hash-Tabellen-Code der Zend-Engine seinen Eintragszähler, bevor er den neuen Schlüssel alloziert. Datadogs Analyse führt es auf _zend_hash_str_add_or_update_i() in zend_hash.c zurück. Wenn diese Allokation das memory_limit überschreitet, wirft PHP einen fatalen Fehler und bricht das Einfügen ab. Der Zähler enthält nun einen Bucket, der nie eingerichtet wurde. Beim Herunterfahren zerstört PHP $_POST und behandelt jeden gezählten Bucket als real.

Der Teil, der API-Teams beunruhigen sollte: Das passiert, während PHP noch den Request-Body parst, bevor auch nur eine Zeile Ihres Codes ausgeführt wird. Ihre Auth-Middleware, Ihr Rate-Limiter und Ihre Eingabevalidierung sehen die Anfrage nie. Datadog hat es mit einem einfachen application/x-www-form-urlencoded-Body reproduziert, nicht mit einem Datei-Upload.

CVE-2026-109619: veralteter globaler Zustand über Anfragen hinweg. PHP hält einen worker-weiten Zustand vor, der auf pro Anfrage gültigen Speicher zeigt. Wenn ein fataler Fehler das Zurücksetzen dieses Zustands unterbricht oder eine späte Shutdown-Diagnose ihn nach dem Aufräumen neu erstellt, liest die nächste Anfrage auf demselben Worker freigegebenen Speicher. PHP bestätigte zwei Pfade:

• Backtraces bei fatalen Fehlern (nur PHP 8.5): Eine Konfigurationsdiagnose in einer späteren Anfrage liest übrig gebliebenen Backtrace-Zustand. Befehlsausführung auf mod_php bestätigt.
• Upload-Verarbeitung: Nach einem fatalen Fehler kann der Session-Upload-Fortschritt Zustand für einen späteren Upload hinterlassen. Der Upload-Fortschritt ist standardmäßig aktiv und läuft auch, wenn Ihre App nie session_start() aufruft. Befehlsausführung auf mod_php und PHP-FPM bestätigt.

Das PHP-Sicherheitsteam stuft mod_php als höchstes Risiko ein, da der demonstrierte Exploit aus einer einzigen nicht authentifizierten Anfrage heraus ausgelöst wird, bevor Anwendungscode geladen wird.

Wer es gefunden hat (und warum KI in den Schlagzeilen ist)

Die Fehler gehen auf Code zurück, der in PHP 5.4.0 eingeführt wurde, und steckten somit über ein Jahrzehnt in der Codebasis. Die PHP Foundation nannte Calif, OpenAI und Wiz.

Berichte von Decrypt und The Next Web besagen, dass der Calif-Forscher Ryan Austin die Schwachstellen im August während eines von OpenAIs GPT-5.6 Sol unterstützten Quellcode-Audits fand. OpenAI sagt, sein eigenes Team habe im September im Rahmen seiner Arbeit „Patch the Planet“ eine vollständigere Version gefunden. Wiz sagt, es habe beide Fehler eigenständig mit Gemini 4 Argon, Wiz Atlas und GPT-5.6 Sol gefunden. Die Anerkennung ist umstritten; die Erkenntnis nicht. KI-gestützte Audits finden jetzt jahrzehntealte Speicherfehler in Kerninfrastruktur, und Angreifer haben dieselben Modelle.

Zeitlinie: Warum der Patch einen Tag früher kam

Amazon rät, ab dem 17. Oktober zu untersuchen (Tenables FAQ dokumentiert die vollständige Zeitlinie), nicht erst ab dem Offenlegungsdatum. Zum Release-Zeitpunkt erklärte das PHP-Team, es habe den nach dem Leak aufgetauchten Proof-of-Concept-Code geprüft und keinen funktionierenden Exploit gefunden. watchTowr hat inzwischen erklärt, beide Fehler reproduziert zu haben. Behandeln Sie jedes „PoC“-Repository, das Sie finden, mit Misstrauen: Nicht verifizierter Exploit-Code enthält oft Malware.

Sind Sie betroffen? Prüfung in fünf Minuten

1. Prüfen Sie die Runtime, die den Traffic bedient, nicht Ihren Laptop. Die CLI-Binary kann sich in Version und Konfiguration vom FPM- oder Apache-Modul unterscheiden.

# On the server or inside the running container
php -v
php-fpm -v
# Apache mod_php: check the loaded module version
apachectl -M 2>/dev/null | grep -i php

Oder geben Sie sie einmal über eine geschützte Route aus und entfernen Sie sie danach:

<?php echo PHP_VERSION, ' ', PHP_SAPI;

2. Vergleichen Sie mit den behobenen Versionen.

Debian, Ubuntu, Red Hat und andere Distributionen backporten Fixes oft, ohne die Upstream-Versionszeichenkette zu ändern. Wenn php -v eine ältere Nummer anzeigt, lesen Sie das Advisory Ihrer Distribution, bevor Sie in Panik geraten.

3. Inventarisieren Sie das versteckte PHP. Container, die vor Monaten mit FROM php:8.3-fpm gebaut wurden, Vendor-Appliances, selbst kompilierte Builds, Admin-Panels auf vergessenen Subdomains. Cisco hat bereits ein Advisory eröffnet, um die eigene Produktlinie zu prüfen. Shodan zählt über 1,9 Millionen internetzugewandte PHP-Hosts; ein Forscher schätzt, dass 1,3 Millionen oder mehr anfällig sein könnten.

Wie Sie patchen

# Debian / Ubuntu (Ondřej Surý PPA or distro packages)
sudo apt update && sudo apt install --only-upgrade 'php8.*'

# RHEL / Rocky / Alma with Remi
sudo dnf upgrade 'php*'

# Official Docker image: rebuild on a fixed tag
docker pull php:8.4.27-fpm
docker build --pull -t my-api:patched .

Dann tun Sie den Schritt, den die meisten Teams vergessen: Starten Sie jeden PHP-Worker neu oder ersetzen Sie ihn. Ein laufender FPM-Pool behält die alte Binary im Speicher. Starten Sie php-fpm neu, laden Sie Apache neu und rollen Sie jeden Container aus. Bei CVE-2026-109619 geht es um Zustand, der über Anfragen hinweg in einem Worker lebt, daher ist ein nicht neu gestarteter Worker weiterhin anfällig.

Auf 8.1 oder älter haben Sie drei Optionen: ein Vendor-LTS-Paket, das Bauen aus PHPs Quellcode-Backport oder ein Upgrade auf 8.2+. CISA empfiehlt, nicht patchbare PHP-Systeme offline zu nehmen, und das britische NCSC und das FBI sagten dasselbe.

Gegenmaßnahmen, wenn Sie heute nicht patchen können

Diese verschaffen Zeit. Gina Peter Banyard vom PHP-Core-Team sagte gegenüber BleepingComputer, keine Gegenmaßnahme blockiere die Angriffe vollständig.

Für CVE-2026-109618:

• Setzen Sie memory_limit=-1 dort, wo Apps es nicht überschreiben können (php_admin_value im FPM-Pool oder in der Apache-Konfiguration). Dies blockiert den bekannten Pfad, aber nicht jede Art, wie eine Allokation fehlschlagen kann.
• Reduzieren Sie post_max_size (8M ohne Uploads, 32M mit Uploads).
• Begrenzen Sie die Request-Body-Größe am Reverse-Proxy (client_max_body_size in nginx) und setzen Sie Container- oder cgroup-Speicherlimits als Verfügbarkeitsgrenze.
• Verwenden Sie keine RLIMIT_AS- oder RLIMIT_DATA-Prozesslimits. Sie können genau die Allokationsfehler verursachen, die der Exploit benötigt.

Für CVE-2026-109619:

• Setzen Sie session.upload_progress.enabled=0 in einer Konfiguration, die vor dem Request-Parsing geladen wird.
• Setzen Sie unter PHP 8.5 außerdem fatal_error_backtraces=0.
• Das Verstecken von Fehlern mit display_errors=0 oder @ bewirkt nichts. Der veraltete Zustand existiert weiterhin.

Am Edge: Cloudflare hat WAF-Regeln für bekannte Vektoren in jedem Tarif bereitgestellt, auch im kostenlosen. Der CTO nannte sie temporär.

Nach jeder Änderung an php.ini starten Sie jeden Worker neu, sonst wird sie nicht wirksam.

Anzeichen, dass Sie bereits getroffen wurden

Datadogs Erkennungshinweise laufen auf vier Signale hinaus:

• Log-Zeile: PHP Fatal error: Allowed memory size of ... bytes exhausted mit Unknown on line 0. Das bedeutet, PHP ist während des Request-Starts gestorben, bevor ein Skript lief.
• Apache-Abstürze: AH00052: child pid ... exit signal Segmentation fault (11), ein wahrscheinlich fehlgeschlagener Exploit-Versuch.
• Seltsame Formular-Posts: ein Feldname, der mehrere Megabyte lang ist, oder Binär- und Null-Bytes in einem Feld mit leerem Namen.
• Das starke Signal: Ein Web-Worker (php-fpm, apache2, httpd), der eine Shell startet.

Vertrauen Sie keinen Statuscodes. Datadogs verfeinerter Exploit gab HTTP 200 zurück und der Worker lief weiter. Durchsuchen Sie die Logs bis zum 17. Oktober zurück.

Beweisen Sie, dass Ihre API nach dem Patch noch funktioniert: Lassen Sie Ihren Agenten sie ausführen

PHP unter Druck in Produktion zu patchen ist der Weg herauszufinden, dass ein Minor-Versionssprung etwas verändert hat. Führen Sie vor und nach dem Ausrollen des Fixes Ihre API-Testsuite gegen Staging aus und lassen Sie Ihren Coding-Agenten das mit Apidog CLI tun.

Einrichtung (einmalig):

npm install -g apidog-cli
apidog auth login --with-token <your-access-token>
apidog test-suite list --project <projectId>

Ein Prompt an Claude Code, Codex oder Cursor:

Wir haben gerade PHP auf Staging wegen PHP2Shell auf 8.4.27 aktualisiert. Verwende die Apidog CLI, um unsere Regressionstestsuite gegen die Staging-Umgebung auszuführen, HTML- und JUnit-Berichte zu schreiben und alle fehlschlagenden Endpunkte zusammenzufassen. Bestätige dann, dass ein POST mit einem Body über unserem nginx client_max_body_size am Proxy mit 413 abgelehnt wird, statt PHP zu erreichen.

Was der Agent ausführt:

apidog test-suite run <testSuiteId> --project <projectId> -e <stagingEnvId>

apidog run --test-suite <testSuiteId> --project <projectId> -e <stagingEnvId> \
  -r cli,html,junit --out-dir ./php2shell-reports --upload-report

-r wählt die Reporter aus, --out-dir legt fest, wo die Berichte landen, und --upload-report überträgt eine Zusammenfassung, die Sie in der Apidog-App öffnen können. Fügen Sie --notification-failed-event <targetId> hinzu, um Ihr Team nur zu benachrichtigen, wenn etwas kaputtgeht. Setzen Sie dieselbe apidog run-Zeile in Ihre CI, damit jedes neu gebaute PHP-Image vor dem Ausliefern getestet wird. Der Claude-Code-Einrichtungsleitfaden und die CI/CD-Pipeline-Anleitung behandeln beides im Detail.

Führen Sie die Suite einmal auf der alten Version aus, um eine Baseline zu erhalten, einmal nach dem Upgrade, und vergleichen Sie. Wenn ein Test fehlschlägt, von dem Sie es nie erwartet hätten, wissen Sie es vor Ihren Nutzern. Laden Sie Apidog herunter, um die Suiten zu erstellen und zu verwalten, die die CLI ausführt.

FAQ

Wird PHP2Shell ausgenutzt? Amazon verzeichnete Versuche ab dem 17. Oktober und sagt, es werde inzwischen breit ausgenutzt; Cloudflare und watchTowr melden ebenfalls Angriffe. CISA hatte Stand 22. Oktober keine Ausnutzung bestätigt.

Schützt mich mein Framework? Nein. CVE-2026-109618 wird ausgelöst, während PHP den Body parst, bevor Laravel, Symfony oder WordPress geladen werden.

Ich bin auf Shared Hosting. Was soll ich tun? Prüfen Sie die Statusseite Ihres Hosters. SiteGround und andere sagen, sie hätten gepatcht. Wenn Ihr Hoster nichts gesagt hat, fragen Sie nach.

Reicht session.upload_progress.enabled=0? Nein. Es deckt einen Pfad einer CVE ab. Patchen Sie.

Muss ich Secrets rotieren? CVE-2026-109619 ermöglicht Speicherofflegung. Wenn Logs seit dem 17. Oktober Anzeichen einer Kompromittierung zeigen, rotieren Sie Datenbankpasswörter, API-Schlüssel und Session-Secrets, die der PHP-Prozess lesen konnte.

Das Fazit

Aktualisieren Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Starten Sie jeden Worker neu. Finden Sie das PHP, das Sie vergessen haben. Prüfen Sie die Logs bis zum 17. Oktober zurück. Führen Sie dann Ihre API-Tests aus, damit der Fix nicht zum nächsten Ausfall wird. Wenn Ihr PHP auf 8.1 oder älter läuft, ist diese Woche die Gelegenheit, endlich davon wegzukommen.