PHP2Shell: zwei kritische PHP-Lücken schließen und auf Missbrauch prüfen

Am 21. Oktober 2026 hat das PHP-Projekt zwei Lücken geschlossen, über die Angreifer ohne Anmeldung eigenen Code auf Webservern ausführen können. Beide sitzen in PHP selbst, nicht in WordPress, Nextcloud oder dem Shop darüber; erste Angriffe laufen bereits. Dieser Beitrag erklärt, wer betroffen ist, welche Paketstände sicher sind, was bis zum Patch hilft und wie Sie mit unserem freien Prüfskript nach Spuren eines Einbruchs suchen.

Was ist passiert?

Die Lücke hat eine lange Vorgeschichte und eine sehr kurze Schlussphase. Erste Hinweise auf das Speicherproblem fand ein von OSTIF organisiertes Audit schon 2024, ohne dass ein Angriffsweg erkennbar war. Im August 2026 meldeten die Sicherheitsfirma Calif und kurz darauf Wiz unabhängig voneinander einen Weg zur Codeausführung; im September folgten weitere Angriffswege von OpenAI. Geplant war das Release für den 22. Oktober.

• 17.10.: Amazon sieht in seinen Honeypots einen ersten Angriffsversuch, vier Tage vor der Veröffentlichung.
• 20.10.: Die beiden CVE-Nummern machen mit einem falschen CVSS-Wert von 10,0 die Runde. Das PHP-Projekt zieht das Release auf den 21.10. vor; am Abend erscheint versehentlich ein Video des Angriffs.
• 21.10.: Gegen 13:30 UTC erscheinen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 samt Sicherheitshinweisen. Ubuntu, Debian und die offiziellen Docker-Images ziehen am selben Tag nach. Das BSI gibt eine Cybersicherheitswarnung der Stufe 3 (Orange) heraus; CISA, das britische NCSC und CERT-EU warnen ebenfalls. Cloudflare, watchTowr und andere sehen massenhafte Angriffsversuche.
• 22.10.: Das BSI meldet in Version 1.2 seiner Warnung, dass Berichte über umgehbare Patches widerlegt sind; bestätigte Kompromittierungen in der Bundesverwaltung und in regulierten Branchen kennt es noch nicht. Sophos berichtet von einer ersten erfolgreichen Ausnutzung, bei der vermutlich eine Mirai-Variante nachgeladen wurde.

Die beiden Lücken verständlich erklärt

Ein PHP-Worker arbeitet Anfragen in einer festen Reihenfolge ab: Er nimmt die Anfrage an, liest die Eingaben ein (Formularfelder, Cookies, den Fortschritt laufender Uploads), führt das Skript aus, räumt den Speicher der Anfrage auf und nimmt die nächste. Beide Fehler sitzen in diesem Rahmen, nicht im Anwendungscode darüber.

CVE-2026-109618: Speicher läuft beim Einlesen voll

PHP begrenzt den Speicher je Anfrage über memory_limit. Ist die Grenze erreicht, springt PHP abrupt aus dem laufenden Code heraus. Passiert das, während die Anfragedaten erst halb aufgebaut sind, hält das spätere Aufräumen den halben Zustand für gültig; daraus lässt sich Codeausführung machen. Den Speicher treibt ein Angreifer gezielt hoch, ohne die üblichen Grenzen zu reißen: Multipart-Anfragen ohne Längenangabe umgehen die Prüfung von post_max_size, ein Multipart-Teil darf beliebig viele Header tragen und verschachtelte Feldnamen vervielfachen die Arbeit.

Das PHP-Projekt hat die volle Codeausführung mit mod_php und Standardgrenzen nachgewiesen. Im Labor von Datadog genügte ein einzelner Feldname von rund 3,5 MB, allerdings bei einem bewusst auf 16 MB gesenkten memory_limit. Der Fix ersetzt den abrupten Sprung durch einen geordneten Abbruch an sicherer Stelle.

CVE-2026-109619: Zustand überlebt seinen Speicher

Ein PHP-Worker bedient viele Anfragen nacheinander und hält dafür globalen Zustand. Unterbricht ein fataler Fehler, ein Timeout oder ein Speicherfehler das Aufräumen, zeigt ein Teil dieses Zustands weiter auf Speicher der alten Anfrage, obwohl der schon freigegeben ist (use-after-free). Die nächste Anfrage im selben Worker kann ihn dann benutzen. Bestätigt sind drei Wege:

• Upload-Fortschritt: session.upload_progress.enabled ist ab Werk an und auch ohne session_start() in der Anwendung erreichbar.
• Einstellungen je Anfrage: INI-Werte etwa aus .htaccess oder php_value, die früh Warnungen werfen. Fehler auszublenden hilft nicht.
• Backtrace fataler Fehler: nur PHP 8.5 mit fatal_error_backtraces.

Wer ist betroffen?

Betroffen ist jede PHP-Laufzeit, die HTTP-Anfragen bedient, nach Angaben von BSI und CERT-EU über alle Versionen seit PHP 5. Das Risiko hängt von der Betriebsart ab:

Sichere Versionen

Die wichtigsten Fixstände, Stand 22. Oktober 2026. Vergleichen Sie mit der Paketversion Ihrer Quelle:

1.Patchen und neu starten

Auf Ubuntu und Debian genügen die normalen Paketquellen. Wichtig ist der zweite Schritt: Ein laufender PHP-FPM- oder Apache-Prozess behält den alten Code im Speicher, bis er neu startet.

# install the fixed packages
sudo apt update
sudo apt install --only-upgrade 'php8.1*' libapache2-mod-php8.1

# restart whatever runs PHP for the web (only the services you have)
sudo systemctl restart php8.1-fpm
sudo systemctl restart apache2

# Debian 12 (php8.2) or Debian 13 (php8.4)
sudo apt update && sudo apt install --only-upgrade 'php8.2*'

# RHEL, AlmaLinux, Rocky: compare with the erratum, not with php -v
sudo dnf upgrade 'php*'
rpm -q php-common php-fpm

Ob der Patch drin ist, zeigt auf Ubuntu 22.04 dieser Einzeiler; er gibt je Paket OK oder VULNERABLE aus:

dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'php8.1*' libapache2-mod-php8.1 2>/dev/null \
  | awk '$1=="ii"{r=system("dpkg --compare-versions "$3" ge 8.1.2-1ubuntu2.28"); print $2, $3, (r==0?"OK":"VULNERABLE")}'

Und dieser zählt die Prozesse, die noch alten PHP-Code im Speicher halten. Bei 0 ist alles neu geladen:

sudo grep -ls 'php.*(deleted)' /proc/[0-9]*/maps 2>/dev/null | wc -l

2.Notbehelf bis zum Patch

Wer nicht sofort patchen kann, sollte das System vom Internet trennen; das empfehlen BSI, CISA und CERT-EU übereinstimmend. Ist das nicht möglich, senken die offiziellen Notbehelfe des PHP-Projekts das Risiko, schließen die Lücken aber nicht. Das PHP-Projekt sagt dazu unmissverständlich: Einen vollständigen Schutz gibt es nur durch das Update.

; CVE-2026-109618: no memory limit inside PHP, use a cgroup/container limit instead
memory_limit = -1
post_max_size = 8M          ; 32M if uploads are needed
upload_max_filesize = 8M    ; always below post_max_size

; CVE-2026-109619: no upload progress tracking
session.upload_progress.enabled = 0

; PHP 8.5 only
fatal_error_backtraces = 0

• Unumgehbar setzen: in php.ini, im FPM-Pool als php_admin_value[…] oder in Apache mit php_admin_value, nicht per ini_set() oder .user.ini. Prüfen, dass kein Pool, kein Verzeichnis und keine Anwendung wieder ein Limit setzt.
• Speicher anders begrenzen: Ohne memory_limit braucht der Server eine Grenze über cgroups oder den Container. Niemals RLIMIT_AS oder RLIMIT_DATA verwenden: Sie lösen genau den verwundbaren Pfad aus.
• Am Webserver oder Proxy begrenzen: Größe, Feldzahl, Zahl der Multipart-Teile, Header je Teil und Verschachtelungstiefe der Anfrage, auch für Anfragen ohne Content-Length. Wer kein Multipart braucht, blockt es ganz.
• Worker kurz leben lassen: pm.max_requests = 1 im FPM-Pool, wenn die Leistung es zulässt.
• Aufräumen: ungültige oder veraltete INI-Einstellungen je Anfrage entfernen, die früh Warnungen erzeugen, und von außen erreichbare fatale Fehler und Timeouts beheben.
• WAF als Zusatz: Cloudflare schützt seit dem 21.10. mit verwalteten Regeln auch im kostenlosen Tarif; bei bezahlten Zonen prüfen, dass sie auf „Block“ stehen. Die Regel von AWS deckt nur CVE-2026-109619 ab. Beide Anbieter sehen ihre Regeln ausdrücklich als Ergänzung zum Update.

3.Woran man Angriffe erkennt

Ein Angriff hinterlässt je nach Ausgang unterschiedliche Spuren. Fehlversuche stehen oft im Error-Log, ein erfolgreicher Angriff dagegen meist nicht: Im Labor von Datadog kam nach 3,1 Sekunden ein normales HTTP 200 zurück, der Worker lief weiter. Deshalb zählen Prozesse und Dateien mehr als Logs.

4.Das Prüfskript php2shell-check.sh

Wir haben die Prüfungen aus diesem Beitrag in ein Skript gegossen, das wir auf eigenen und betreuten Servern einsetzen. Es läuft als root, ändert nichts am System und schreibt nur einen Bericht. Im Terminal erscheinen ausschließlich feste Texte, Zählwerte und Zeilennummern; Pfade, Adressen und Logzeilen stehen nur im Bericht, den nur root lesen kann. So lässt sich die Ausgabe gefahrlos weitergeben.

curl -fsSLO https://nokkela.blog/downloads/php2shell-check.sh
curl -fsSLO https://nokkela.blog/downloads/php2shell-check.sh.sha256
sha256sum -c php2shell-check.sh.sha256      # must print: php2shell-check.sh: OK

sudo bash php2shell-check.sh                   # lookback from 2026-10-17
sudo SINCE=2026-08-01 bash php2shell-check.sh  # longer lookback

Lesen Sie das Skript vor dem ersten Lauf: Es sind gut 500 Zeilen Bash ohne Abhängigkeiten außer den Bordmitteln von Debian und Ubuntu. Die Ausgabe auf einem Testsystem mit absichtlich gelegten Spuren sieht so aus:

### php2shell-check 1.0.0 (CVE-2026-109618, CVE-2026-109619), since 2026-10-17
[ INFO ] Platform Ubuntu 22.04.5 LTS
[ INFO ] Web users: 1, web roots: 2, error logs: 2, access logs: 1

### PHP packages
[  OK  ] 'All 5 PHP packages at a fixed version'
[  OK  ] 'Running processes use the current PHP code'

### Attack attempts in the logs
[FAILED] 'Errors while setting up requests (Unknown on line 0): 2 (report lines 17-18)'
[FAILED] 'Crashed Apache or PHP workers, core dumps: 3 (report lines 21-23)'
[FAILED] 'Session errors and upload-progress sessions: 2 (report lines 26-27)'
[FAILED] 'Published PHP2Shell indicators (scanners, source IPs, payload): 3 (report lines 30-32)'

### Traces of a compromise
[FAILED] 'Foreign processes under the web user: 2 (report lines 35-36)'
[FAILED] 'Programs running from /tmp, /dev/shm, memory or a web root: 1 (report line 39)'
[FAILED] 'Script files written by the web user: 1 (report line 42)'
[ INFO ] Other changed script files (deployment?): 1 (report line 45)
[FAILED] 'Files of the web user in /tmp, /var/tmp, /dev/shm: 1 (report line 48)'
[FAILED] 'Signs of persistence (cron, SSH, systemd, accounts): 2 (report lines 51-52)'
[FAILED] 'Package files differing from their package: 1 (report line 55)'
[ INFO ] No SSH logins in the journal

### Result
[FAILED] 'Yellow: 10, review and assess'
[ INFO ] Report: /opt/php2shell-check/reports/report-20261022-212135.txt
[ INFO ] View all findings: tail -n +16 /opt/php2shell-check/reports/report-20261022-212135.txt

Rote Zeilen bedeuten: Patch fehlt oder alter Code läuft noch. Gelbe Zeilen sind Funde, die Sie ansehen und bewerten. Der Rückgabewert ist 2 bei Rot, 1 bei Gelb und 0 ohne Funde, damit lässt sich das Skript auch in Ansible oder ein Monitoring einbinden.

5.Was tun bei einem Fund?

Die Reihenfolge ist wichtiger als jeder einzelne Schritt: erst schließen, dann prüfen, dann aufräumen.

• Isolieren: Den Server vom Netz nehmen oder per Firewall auf Ihren Verwaltungszugang beschränken. Nicht ausschalten, solange Sie Beweise sichern wollen: Prozesse und Speicher sind dann verloren.
• Beweise sichern: den Bericht des Prüfskripts, die Error- und Access-Logs ab dem 17.10., die Liste der laufenden Prozesse und, wenn möglich, ein Abbild der Platte.
• Geheimnisse wechseln: alles, was PHP lesen konnte, gilt als bekannt: Datenbank-Passwörter, API-Schlüssel in .env oder Konfigurationsdateien, Cloud-Zugänge, SMTP-Zugänge, Sitzungsschlüssel der Anwendung. Das gilt vorsorglich auch ohne Hinweis auf Codeausführung, wenn der Server ungepatcht im Internet stand: Wiz hat gezeigt, dass sich über die Lücke Speicherinhalte auslesen lassen.
• Neu aufsetzen statt bereinigen: Einen kompromittierten Server sauber zu putzen gelingt selten sicher. Neu installieren, gepatchtes PHP einspielen, Daten aus einer Sicherung vor dem 17.10. prüfen und zurückspielen.
• Melden: Bei personenbezogenen Daten gilt die 72-Stunden-Frist der DSGVO (Art. 33); Einrichtungen unter NIS2 haben eigene Meldepflichten.

Häufige Fragen

Quellen

Externe Quellen, Stand 22. Oktober 2026 (öffnen in einem neuen Tab):

• PHP-Projekt, Sicherheitsrelease vom 21. Oktober 2026
• PHP-Projekt, GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP-Projekt, GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation, Hintergrund zum Sicherheitsrelease
• BSI, Cybersicherheitswarnung zu PHP (Stufe 3)
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching
• NCSC (Vereinigtes Königreich), Critical security issue affecting PHP
• CERT-EU, Security Advisory 2026-018
• NVD, CVE-2026-109618
• Ubuntu, USN-8948-1
• Ubuntu, USN-8948-2 (ESM)
• Debian, DSA-6574-1 (trixie)
• Debian LTS, DLA-4848-1 (bookworm)
• Red Hat, RHSB-2026-013
• AlmaLinux, Updates zu PHP2Shell
• Ondřej Surý, PPA ondrej/php
• Amazon Threat Intelligence, Ausnutzung vor der Veröffentlichung
• Cloudflare, WAF-Schutz gegen PHP2Shell
• Calif, PHP2Shell
• Wiz, PHP2Shell
• Datadog Security Labs, Erkennung und Analyse
• Sophos, Proof of Concept und erste Ausnutzung
• ELLIO, Beobachtungen aus dem Sensornetz
• Eye Security, Risikobewertung
• Bitdefender, Technical Advisory
• Elastic Security Labs, Erkennungsregeln

Dieser Beitrag dient der allgemeinen Information und ersetzt keine Prüfung im Einzelfall. Versionsstände und Befehle beziehen sich auf den genannten Stand und sind an Ihre Umgebung anzupassen. Das Prüfskript wird unter der BSD-2-Clause-Lizenz ohne Gewähr bereitgestellt. Stand: Oktober 2026.