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öglichen, Code auf einem Webserver auszuführen. Das Duo läuft unter CVE-2026-109618 und CVE-2026-109619 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 bereits am 17. Oktober Ausnutzungsversuche – vier Tage, bevor der Patch überhaupt existierte.

Probieren Sie Apidog noch heute aus

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 zeigt, 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

Frage	Antwort
Was ist es?	Zwei Speichersicherheitsfehler in PHPs Request-Verarbeitung, verkettet zu Remote Code Execution
CVEs	CVE-2026-109618 (Korruption bei Speichererschöpfung), CVE-2026-109619 (veralteter Zustand, Use-after-free)
Schweregrad	CVSS v4.0 je 9,2 (früh geleakte IDs nannten 10,0; PHP sagt, das war falsch)
Authentifizierung nötig?	Nein
Betroffen	Jede SAPI, die HTTP bedient: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed
Behobene Versionen	8.5.12, 8.4.27, 8.3.36, 8.2.35
PHP 8.1 und älter	Kein offizielles Release; minimale Quellcode-Backports für 7.4, 8.0, 8.1; 5.4 bis 7.3 bekommen nichts
Ausgenutzt?	Versuche seit dem 17. Oktober beobachtet (Amazon), frühe Angriffe von Cloudflare gemeldet
Behebung	Upgrade, jeden Worker neu starten. Workarounds reduzieren das Risiko, schließen es aber nicht

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. Die Analyse von Datadog führt das auf _zend_hash_str_add_or_update_i() in zend_hash.c zurück. Überschreitet diese Allokation das memory_limit, 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 geschieht, 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 das mit einem schlichten 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. Unterbricht ein fataler Fehler das Zurücksetzen dieses Zustands oder erstellt eine späte Shutdown-Diagnose ihn nach dem Aufräumen neu, 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 der Initiative „Patch the Planet“ eine vollständigere Version gefunden. Wiz wiederum sagt, es habe beide Fehler eigenständig mit Gemini 4 Argon, Wiz Atlas und GPT-5.6 Sol entdeckt. Die Anerkennung ist umstritten – die Erkenntnis nicht: KI-gestützte Audits finden inzwischen jahrzehntealte Speicherfehler in Kerninfrastruktur, und Angreifer haben Zugriff auf dieselben Modelle.

Zeitlinie: Warum der Patch einen Tag früher kam

Datum (2026)	Was geschah
August bis September	Calif, OpenAI und Wiz melden die Fehler privat
17. Okt.	Amazons MadPot-Honeypot verzeichnet einen Ausnutzungsversuch
20. Okt.	CVE-IDs leaken auf Hacker News und in sozialen Medien; PHP veröffentlicht eine Vorabmeldung; CERT-EU gibt Advisory 2026-018 heraus
21. Okt., 14:00 UTC	PHP liefert Fixes aus, nach dem Leak vom 22. Okt. vorverlegt; CISA veröffentlicht eine Warnung; Cloudflare meldet frühe Angriffe
22. Okt.	Keine der beiden CVEs steht bisher in CISA's KEV-Katalog

Amazon rät, ab dem 17. Oktober zu untersuchen – nicht erst ab dem Offenlegungsdatum (Tenables FAQ dokumentiert die vollständige Zeitlinie). 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. Begegnen Sie jedem „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.

# Auf dem Server oder im laufenden Container
php -v
php-fpm -v
# Apache mod_php: Version des geladenen Moduls prüfen
apachectl -M 2>/dev/null | grep -i php

Oder geben Sie die Version 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.

Zweig	Anfällig	Behoben in
8.5	< 8.5.12	8.5.12
8.4	< 8.4.27	8.4.27
8.3	< 8.3.36	8.3.36
8.2	< 8.2.35	8.2.35
7.4 bis 8.1	Alle	Nur Quellcode-Backports oder Vendor-LTS
5.4 bis 7.3	Alle	Kein Fix

Debian, Ubuntu, Red Hat und andere Distributionen backporten Fixes oft, ohne die Upstream-Versionszeichenkette zu ändern. Zeigt php -v eine ältere Nummer, lesen Sie erst 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 oder Distro-Pakete)
sudo apt update && sudo apt install --only-upgrade 'php8.*'

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

# Offizielles Docker-Image: auf einem gepatchten Tag neu bauen
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. CVE-2026-109619 betrifft Zustand, der über Anfragen hinweg in einem Worker lebt – ein nicht neu gestarteter Worker bleibt also 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; 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). Das 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 zusätzlich 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 der 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) – sehr wahrscheinlich ein 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 Zeitdruck in Produktion zu patchen ist der klassische Weg, um 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 der Apidog CLI erledigen.

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 danach, 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 einzigen CVE ab. Patchen Sie.

Muss ich Secrets rotieren? CVE-2026-109619 ermöglicht die Offenlegung von Speicherinhalten. Zeigen Ihre Logs seit dem 17. Oktober Anzeichen einer Kompromittierung, 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. Und wenn Ihr PHP auf 8.1 oder älter läuft, ist diese Woche die Gelegenheit, endlich davon wegzukommen.