PHP2Shell: RCE ohne Authentifizierung in PHP und wie Sie prüfen, ob Ihre Builds betroffen sind

PHP2Shell sind zwei kritische Schwachstellen in PHP selbst, CVE-2026-109618 und CVE-2026-109619, die es einer nicht authentifizierten Web-Anfrage ermöglichen können, Code auf jeder PHP-Installation auszuführen, die Web-Anfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Beide werden in freier Wildbahn ausgenutzt und stehen im KEV-Katalog der CISA. Der Fix ist PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35; PHP 8.1 und älter erhalten kein Upstream-Release. Aktualisieren Sie, bauen Sie dann jedes Container-Image neu, das PHP enthält, und deployen Sie es erneut, einschließlich alter Tags, die noch laufen, und Images, die Sie an Kunden ausgeliefert haben.

Den Server zu patchen, den Sie kennen, ist der einfache Teil. Was als Angriffsfläche bleibt, ist das PHP, das Sie vergessen haben: eine Runtime, die in ein Basis-Image kompiliert ist, ein Image-Tag vom letzten Jahr, das noch in Produktion läuft, ein CI-Image oder ein Produkt, das mit einem PHP am Ende seines Lebenszyklus an Kunden ausgeliefert wurde. Diese Seite bringt Sie zuerst auf den gepatchten Stand und zeigt dann, wie Sie den Rest finden.

Was passiert ist

Datum (2026)	Ereignis	Quelle
11. und 21. August	Calif meldet die beiden Fehler an das PHP-Projekt	Calif
17. Oktober	Der erste Ausnutzungsversuch, den Amazon in seinen Honeypots sah, noch vor der Veröffentlichung	Amazon Threat Intelligence
20. Oktober	PHP kündigt für den 21. Oktober, 14:00 UTC, ein Sicherheitsrelease an, das zwei mit CVSS 4.0 9,2 bewertete Schwachstellen behebt	php.net
21. Oktober	PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie seine Sicherheitsmeldung; die CVE-Einträge werden öffentlich; NCSC-NL eröffnet sein Repository php2shell	PHP-Sicherheitsmeldung, NCSC-NL
21. Oktober	Die offiziellen Docker-Images php werden auf die behobenen Versionen aktualisiert	docker-library/php
21. Oktober	watchTowr meldet die Ausnutzung beider CVEs in freier Wildbahn; CISA veröffentlicht eine Warnung	watchTowr, CISA
22. Oktober	Searchlight Cyber veröffentlicht php2shell-scanner	GitHub
23. Oktober	PHP empfiehlt, session.upload_progress.enabled=0 zu setzen, wegen eines separaten, unwahrscheinlichen RCE-Vektors, CVE-2026-115560	php.net
26. Oktober	CISA nimmt beide CVEs in den KEV-Katalog auf, mit Frist 29. Oktober für US-Bundesbehörden	CISA KEV

Der Name PHP2Shell stammt aus dem Bericht von Calif und wird in der Branche allgemein verwendet; die Sicherheitsmeldungen von PHP selbst nutzen ihn nicht. Die CVE-Einträge nennen Calif, Wiz und OpenAI als Entdecker.

Wer betroffen ist

Jedes PHP, das Web-Anfragen bedient. Die Sicherheitsmeldung von PHP nennt PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed und sieht das höchste Risiko bei mod_php, „mit einem nachgewiesenen Exploit, bei dem eine nicht authentifizierte Anfrage den Angriff auslösen kann, bevor irgendein Anwendungscode läuft“. Weil die Fehler in PHP selbst liegen, sind Anwendungen auf Basis von Laravel, Symfony oder WordPress immer dann exponiert, wenn es das PHP darunter ist.

Branch	Betroffen	Behoben in	Upstream-Support
8.5	vor 8.5.12	8.5.12	Aktiv
8.4	vor 8.4.27	8.4.27	Aktiv
8.3	vor 8.3.36	8.3.36	Nur Sicherheitsfixes, bis 31. Dezember 2027
8.2	vor 8.2.35	8.2.35	Nur Sicherheitsfixes, bis 31. Dezember 2026
8.1, 8.0, 7.4	alle Versionen, laut Calif und watchTowr	kein Release; minimale Quellcode-Backports in php-src	End of Life
7.3 und älter, einschließlich PHP 5	alle Versionen, laut Calif und watchTowr	kein Upstream-Fix	End of Life

Die Sicherheitsmeldungen von PHP führen nur die unterstützten Branches auf. Für ältere berichtet Calif, dass „der früheste betroffene Pfad, den wir gefunden haben, auf PHP 5.4.0 zurückgeht“, und watchTowr führt PHP 7 und PHP 5 als betroffen ohne Fix. PHP sagt, dass die Branches 8.1 und älter „keine Updates mehr vom PHP-Projekt erhalten“, hat aber minimale Quellcode-Backports für 7.4, 8.0 und 8.1 für alle veröffentlicht, die aus dem Quellcode bauen. Manche Distributionen und kommerzielle Anbieter für Langzeit-Support liefern zurückportierte Fixes für Branches am Ende ihres Lebenszyklus; fragen Sie Ihren. Wenn Sie die nächste Hauptversion testen: PHP 8.6.0 RC4, am selben Tag veröffentlicht, enthält die Fixes ebenfalls.

Wie es funktioniert

Beide CVEs sind Speichersicherheitsfehler in der Art, wie PHP eine Anfrage aufbaut und wieder abbaut, unterhalb jedes Anwendungscodes. Die CVE-Einträge stufen beide als Use after free (CWE-416) ein, dazu als fehlerhafte Behandlung von Ausnahmezuständen, Zugriff auf einen nicht initialisierten Zeiger, unkontrollierte Speicherzuweisung und fehlerhafte Initialisierung (CWE-755, CWE-824, CWE-1325, CWE-1419). In den Worten von PHP:

• CVE-2026-109618, RCE durch OOM-Korruption: „Die Behandlung von Speichermangel kann PHP unterbrechen, während interne Anfragedaten erst teilweise initialisiert sind. Die Bereinigung der Anfrage kann die ungültigen Daten dann als gültig behandeln.“ Ein Request-Body, der darauf ausgelegt ist, den Speicher zu erschöpfen, während PHP ihn parst, kann diesen Abbruch auslösen. Apache mit mod_php führt die Bereinigung auch dann aus, wenn der Start der Anfrage fehlgeschlagen ist; deshalb funktioniert der Angriff dort, bevor irgendein Anwendungscode läuft. Für PHP-FPM sagt die Sicherheitsmeldung von PHP, dass die Quellcodeanalyse eine Anfälligkeit stützt, auch wenn noch kein vollständiger FPM-Exploit nachgewiesen wurde.
• CVE-2026-109619, RCE durch veralteten globalen Zustand: „Interner Zustand, der zu einer Anfrage gehört, kann fortbestehen, nachdem der zugrunde liegende Speicher freigegeben wurde. Eine spätere Anfrage, die derselbe Worker bearbeitet, kann diesen veralteten Zustand verwenden, bevor die normale Initialisierung ihn zurücksetzt.“ Dafür braucht es zwei Anfragen, die denselben Worker erreichen: eine, die den Zustand zurücklässt, etwa durch einen fatalen Fehler, und eine, die ihn verwendet. Die Sicherheitsmeldung von PHP bestätigt den Weg über den Session-Upload-Fortschritt gegen mod_php und FPM sowie den Weg über Backtraces fataler Fehler in PHP 8.5 gegen mod_php.

Deshalb zielen die vorläufigen Einstellungen von PHP auf Speicherlimits, die Größe des Request-Bodys, den Session-Upload-Fortschritt und Backtraces fataler Fehler: Jede schließt einen Weg zu den Fehlern, nicht die Fehler selbst. PHP bewertet als CNA beide mit 9,2 nach CVSS 4.0. Die eigenen CVSS-3.1-Bewertungen der NVD liegen bei 9,8 für CVE-2026-109618 und 8,1 für CVE-2026-109619.

So prüfen Sie, ob Sie betroffen sind

Beginnen Sie mit den Hosts, die Sie kennen, und suchen Sie dann in allem, was Sie bauen und ausliefern, nach PHP.

Auf einem Host oder einer VM prüfen Sie die Version, die PHP meldet. Prüfen Sie auch die Web-SAPI, denn php-fpm oder das Apache-Modul können aus einem anderen Paket stammen als die Kommandozeile:

php -v
php-fpm -v

Distributionspakete (Debian, Ubuntu, Alpine, RHEL) erhalten den Fix oft als Backport ohne neue Upstream-Version: Ubuntu 24.04 zum Beispiel liefert den Fix als 8.3.6-0ubuntu0.24.04.13. Eine reine Versionsprüfung führt hier in die Irre. Listen Sie das installierte Paket auf und vergleichen Sie es mit der behobenen Paketversion im Security Tracker Ihrer Distribution:

dpkg -l 'php*' | grep '^ii'    # Debian, Ubuntu
apk info -v | grep '^php'      # Alpine
rpm -qa 'php*'                 # RHEL, Fedora, Rocky, Alma

In Container-Images. Offizielle php:-Images kompilieren PHP aus dem Quellcode, daher steckt die Version im Image selbst, nicht in einer Paketliste der Distribution. Fragen Sie das Image direkt:

docker run --rm --entrypoint php php:8.3-fpm -v

Um jedes Image zu prüfen, das Sie tatsächlich betreiben, listen Sie sie auf und fragen jedes einzelne. Für Kubernetes:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | sort -u \
  | while read -r image; do
      version=$(docker run --rm --entrypoint php "$image" -r 'echo PHP_VERSION;' 2>/dev/null)
      printf '%s\t%s\n' "${version:-no php}" "$image"
    done

Images, die FROM debian oder FROM alpine gebaut sind und PHP über den Paketmanager installieren, brauchen die Paketprüfung von oben, ausgeführt im Image.

In Ihren Repositories suchen Sie nach jeder Stelle, an der PHP gewählt wird:

git grep -nE '^FROM[[:space:]]+(.*/)?php:' -- '*Dockerfile*' '*.dockerfile'
git grep -nE 'php-version|image:.*php' -- .github/workflows '*.yml' '*.yaml'

Fest gepinnte Tags wie php:8.3.30-fpm bleiben verwundbar, bis jemand sie ändert. Gleitende Tags wie php:8.3-fpm wurden ab dem 21. Oktober mit den behobenen Versionen neu gebaut, aber ein Image, das davor gebaut wurde, behält das alte PHP, bis Sie es neu bauen. Die php-Bedingung in composer.json sagt, welche Versionen Ihr Code akzeptiert, nicht welche läuft.

Im CI. Build- und Test-Jobs nutzen oft ihr eigenes PHP: einen php:-Service-Container, eine Setup-Action mit einem php-version-Input oder ein Runner-Image. Sie bedienen keinen Produktionsverkehr, zeigen aber, welche Images und Versionen Ihre Pipeline erzeugt.

Exponierte Hosts. Der php2shell-scanner von Searchlight Cyber prüft eine URL mit großen Multipart-Anfragen, etwa 29 MiB pro Pfad. Setzen Sie ihn nur gegen Hosts ein, die Sie testen dürfen. Sein README warnt vor Fehlalarmen bei gepatchtem PHP mit niedrigem memory_limit, und wenn PHP seine Version nicht preisgibt, kann der Scanner einen gepatchten Server nicht von einem verwundbaren unterscheiden. Behandeln Sie ihn als Hinweis, nicht als Beweis. Das Repository von NCSC-NL sammelt Erkennungsregeln und eine Liste von Produkten, die PHP mitliefern, samt ihrem Status.

Was der heutige Scan Ihnen nicht sagen kann. Ein Scan der Images in Ihrer Registry deckt heute ab, was Sie heute deployen würden. Er deckt nicht ein früheres Release ab, das Sie an einen Kunden ausgeliefert haben, nicht das alte Tag, das ein Kunde noch betreibt, und nicht, welche Ihrer Builds Images mit verwundbarem PHP erzeugt haben. Dafür brauchen Sie eine Aufzeichnung dessen, was jeder Build eingebracht hat, pro Release. Siehe Sind wir betroffen? So bewerten Sie eine neue CVE über Ihre Builds hinweg.

So beheben Sie es, und was Sie tun, wenn Sie noch nicht patchen können

1. Aktualisieren Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf das behobene Paket Ihrer Distribution. Unter 8.1 oder älter wechseln Sie auf einen unterstützten Branch; die Backports von PHP und Builds von Anbietern sind Notlösungen.
2. Bauen Sie jedes Image neu auf einer behobenen Basis (ziehen Sie das Basis-Image erneut oder bauen Sie ohne Cache) und deployen Sie es erneut. Bereits laufende Images behalten ihr altes PHP, bis sie ersetzt werden, starten Sie also auch die Workloads neu.
3. Verifizieren Sie mit der Checkliste unten, gegen die laufenden Container, nicht nur gegen das neue Image.

Wenn Sie noch nicht aktualisieren können, nennt die Sicherheitsmeldung von PHP Maßnahmen, die „die Angriffsfläche für bestimmte Angriffswege verringern, eine Installation aber nicht sicher machen“. Für CVE-2026-109618:

• „Setzen Sie memory_limit=-1, vorzugsweise so, dass Anwendungen es nicht überschreiben können, etwa mit php_admin_value im FPM-Pool oder in der Apache-Konfiguration, und prüfen Sie, dass keine Pool-, Verzeichnis- oder Anwendungseinstellung wieder ein endliches Limit setzt.“
• „Für Anwendungen, die keine Datei-Uploads benötigen, setzen Sie post_max_size = 8M. Sind Datei-Uploads nötig, setzen Sie post_max_size = 32M. Halten Sie upload_max_filesize unter post_max_size.“
• Nutzen Sie ein Speicherlimit für Container oder cgroups als Grenze für die Verfügbarkeit, und ersetzen Sie es nicht durch RLIMIT_AS oder RLIMIT_DATA, „da diese den verwundbaren Fehlschlag bei der Speicherzuweisung auslösen können“.

Für CVE-2026-109619:

• „Setzen Sie session.upload_progress.enabled=0 und starten Sie jeden Worker neu. Verwenden Sie php.ini, einen FPM-Pool oder eine Serverkonfiguration, die vor dem Parsen der Anfrage greift. Verlassen Sie sich nicht auf ini_set() oder FPM-.user.ini.“
• „Setzen Sie unter PHP 8.5 fatal_error_backtraces=0 und starten Sie jeden Worker neu.“

Prüfen Sie, mit welchen Werten jeder Worker tatsächlich läuft:

php-fpm -i | grep -E 'memory_limit|post_max_size|session.upload_progress.enabled'

Die Warnung der CISA geht weiter: Organisationen, die nicht sofort aktualisieren können oder noch PHP 8.1 oder älter betreiben, „sollten PHP-basierte Systeme vom Netz nehmen, bis sie gepatcht oder aktualisiert werden können“. Sie rät außerdem, auf PHP-Worker-Prozesse zu achten, die Shells starten oder Tools herunterladen.

Den Fix verifizieren

1. Fragen Sie das laufende PHP, nicht das Image, das Sie deployen wollten. Führen Sie php-fpm -v (oder php -v) in jedem laufenden Container und auf jedem Host aus und bestätigen Sie 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer.
2. Verlassen Sie sich bei Distributionspaketen nicht allein auf den Versionsstring. Debian, Ubuntu, RHEL und andere Distributionen portieren den Fix in die Version zurück, die sie bereits ausliefern, daher kann ein gepatchtes PHP weiterhin 8.3.6 melden: Der Fix von Ubuntu 24.04 ist 8.3.6-0ubuntu0.24.04.13. Vergleichen Sie die vollständige Paketversion mit dem Security Tracker Ihrer Distribution, oder suchen Sie die CVE im Changelog des Pakets, das sie meist nennt. Die Falle funktioniert auch umgekehrt: Ein Scanner, der nur Upstream-Versionsnummern vergleicht, kann ein zurückportiertes Paket als verwundbar melden.
3. Prüfen Sie, dass jeder Workload das neu gebaute Image ausführt. Ein Tag, das jetzt auf ein behobenes Image zeigt, ändert nichts an einem Pod, der das alte gezogen hat. Vergleichen Sie den Image-Digest, den jeder Container ausführt, mit dem Digest, den Sie gebaut haben:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.image}{"\t"}{.imageID}{"\n"}{end}{end}'

4. Prüfen Sie, dass jeder Worker neu gestartet wurde. PHP-FPM und Apache behalten den alten Code geladen, bis sie neu starten; die Prozessprüfung unter „Auf Kompromittierung prüfen“ zeigt alle, die ihn noch ausführen.
5. Wenn Sie sich noch auf die vorläufigen Einstellungen verlassen, prüfen Sie jeden Pool mit dem Befehl php-fpm -i von oben, und behalten Sie sie bei, bis das Upgrade überall erledigt ist.
6. Führen Sie die Bestandsaufnahme erneut aus, aus dem Abschnitt zur Prüfung, über Ihre Registry, CI-Images und die Releases, die Kunden betreiben, nicht nur über die Produktion.

Auf Kompromittierung prüfen

PHP2Shell wird in freier Wildbahn ausgenutzt, und Amazon sah den ersten Versuch am 17. Oktober 2026, vier Tage vor dem Fix. Wenn ein aus dem Internet erreichbares PHP seitdem zu irgendeinem Zeitpunkt eine betroffene Version ohne die vorläufigen Einstellungen betrieb, prüfen Sie es.

Wie groß die Angriffsfläche ist. Shodan-Bannerzählungen, die Mallory am 20. Oktober veröffentlichte und über die CybelAngel berichtete, fanden 2,24 Millionen aus dem Internet erreichbare Hosts, die PHP angeben; von den rund 1,5 Millionen, die eine Version zeigen, betreiben 883.717 (59 %) einen Branch ohne offiziellen Fix. Gezählt werden Hosts, keine bestätigt verwundbaren Systeme: Zurückportierte Pakete können alt aussehen und trotzdem gepatcht sein, und etwa 740.000 Hosts verbergen ihre Version.

Appliances und Produkte, die PHP mitliefern. PHP läuft auch in Appliances, Netzwerkgeräten, Verwaltungsoberflächen und Herstellerprodukten, in denen Sie es womöglich nicht selbst aktualisieren können. Die Bestandsliste von NCSC-NL erfasste am 9. November 2026 968 solcher Produkte: 205 behoben, 215 verwundbar, 93 in Untersuchung, 240 abhängig von der Laufzeitumgebung und 214 nicht betroffen. Prüfen Sie diese Produkte gesondert und spielen Sie Hersteller-Updates ein, sobald sie verfügbar sind.

Stellen Sie sicher, dass der Fix wirklich läuft. Auf Hosts und VMs führt ein PHP-FPM-, php-cgi- oder Apache-Prozess, der vor dem Upgrade gestartet wurde, weiterhin den alten Code aus. Seine Memory Map zeigt dann das ersetzte Binary oder libphp als gelöscht. Vergleichen Sie außerdem die Startzeiten der Prozesse mit dem Zeitpunkt des Upgrades:

for pid in $(pgrep -f 'php-fpm|php-cgi|apache2|httpd|frankenphp'); do
  grep -qE '(php|libphp)[^/]*\(deleted\)' "/proc/$pid/maps" 2>/dev/null \
    && echo "PID $pid still runs a replaced PHP"
done
ps -o pid,lstart,args -p "$(pgrep -d, -f 'php-fpm|php-cgi|apache2|httpd|frankenphp')"

Indikatoren aus Primärquellen:

• Anfragen: POST-Anfragen mit Formular-Uploads, die den String PHP_SESSION_UPLOAD_PROGRESS enthalten, den Amazon Threat Intelligence in Ausnutzungsversuchen sah. Amazon nennt auch Quelladressen (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37), weist aber darauf hin, dass sie zu gemeinsam genutzter Anonymisierungsinfrastruktur gehören: Gehen Sie einem Treffer nach, behandeln Sie ihn aber nicht als Beweis.
• Prozesse und Dateien: PHP-Worker-Prozesse, die Shells starten oder Tools herunterladen (CISA, die am 23. Oktober eine Sigma-Erkennungsregel ergänzte), sowie unerwartete Prozessausführungen oder Dateiänderungen auf Webservern (Amazon).
• Logs: in Logs von Apache, PHP-FPM, Reverse Proxys und Diensten wiederholte Warnungen oder Core-Fehler, bevor Skripte laufen, fatale Fehler und Parse-Fehler sowie Maximum execution time exceeded. Die Sicherheitsmeldung von PHP ergänzt, dass „das Fehlen eines Fehlers in den Logs kein Beweis für Sicherheit ist“.

Wann Sie von einer Kompromittierung ausgehen sollten. Wenn Sie einen dieser Indikatoren finden oder wenn ein exponierter Server ein betroffenes PHP ohne Gegenmaßnahmen betrieb und Ihre Logs eine Ausnutzung nicht ausschließen können, behandeln Sie ihn als kompromittiert. PHP beschreibt die Auswirkung als Remote Code Execution unter dem Konto des Web-Workers, und dieses Konto kann meist die Konfiguration und die Secrets der Anwendung lesen.

Rotieren Sie, was der Worker lesen konnte. Datenbankpasswörter, API-Schlüssel und Tokens in Umgebungsvariablen und Konfigurationsdateien, Schlüssel, die Sessions oder Cookies signieren (und die damit signierten Sessions), sowie alle Cloud-Zugangsdaten, die dem Host zur Verfügung stehen. Rotieren Sie, nachdem der Host neu aufgebaut ist, damit die neuen Secrets nie auf einer kompromittierten Maschine liegen.

Neu aufbauen statt bereinigen. Ersetzen Sie einen kompromittierten Host oder Container aus einem bekannt guten Image, und übernehmen Sie keine Dateien, die der Worker schreiben konnte, etwa Upload-Verzeichnisse, Caches oder generierten Code. Verwenden Sie keine Images, Build-Caches oder Artefakte wieder, die auf einem kompromittierten Host entstanden sind.

Was Sie Ihren Kunden sagen

Wenn Sie Software ausliefern, die auf PHP läuft, werden Ihre Kunden fragen. Antworten Sie mit Versionen und Maßnahmen, auch bevor Sie jede Antwort haben. Eine Antwort, die Sie anpassen können:

PHP2Shell (CVE-2026-109618, CVE-2026-109619) betrifft PHP-Versionen vor 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie alle älteren PHP-Branches. [Produkt] in den Versionen [x bis y] liefert PHP [Version] mit und ist betroffen; Version [z], veröffentlicht am [Datum], liefert PHP [behobene Version]. Bitte aktualisieren Sie auf [z]. Wenn Sie nicht sofort aktualisieren können, wenden Sie die PHP-Einstellungen aus unserer Sicherheitsmeldung [Link] an und beschränken Sie den Netzwerkzugriff auf die Anwendung. [Produkt] in den Versionen [a bis b] ist nicht betroffen. Wir aktualisieren diesen Hinweis bis [Datum].

Wenn Sie noch prüfen, sagen Sie das, und sagen Sie, wann Sie antworten werden. Eine erste Stellungnahme und Vorlagen für jedes Ergebnis finden Sie unter wie Sie Kunden nach einem Lieferkettenangriff antworten.

Wie CRACI hilft

CRACI führt Ihre GitHub-Actions-Jobs aus und zeichnet beim Bauen auf, was jeder Job hereinholt, einschließlich Container-Images, apt- und apk-Paketen und Composer-Paketen, und es bewahrt jeden vergangenen Build mit seiner SBOM auf. Wird eine CVE veröffentlicht, markiert die kontinuierliche Neubewertung die vergangenen Builds, die das betroffene Paket enthielten, sodass Sie sehen, welche Releases exponiert waren und wie lange, nicht nur, was der heutige Scan findet. Policy Gates können Builds blockieren, die eine bestimmte CVE enthalten.

Eine Einschränkung bei diesem Vorfall: PHP, das in ein offizielles php:-Image kompiliert ist, kommt im Image an, nicht als Paket-Download. CRACI zeichnet die Image-Referenz auf, die jeder Build gezogen hat, durchsuchen Sie Ihre Builds also nach den php:-Tags ebenso wie nach PHP-Paketen.

Finden Sie jeden Build, der ein verwundbares PHP ausgeliefert hat

Mehr zu Build-Aufzeichnungen: Build-Time-SBOMs, SBOMs für Docker-Images, was Container-Scanning übersieht, der CISA KEV-Katalog und Trends bei CVE-Veröffentlichungen. Weitere Vorfälle: alle Schwachstellen.

Mehr zur PHP-Sicherheit über diesen Vorfall hinaus finden Sie in unserem Leitfaden zur PHP-Sicherheit.

Quellen und Aktualisierungen

Primärquellen:

• PHP: Sicherheitsmeldung vom 21. Oktober 2026, informative Meldung vom 23. Oktober 2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, unterstützte Versionen
• CVE-Einträge: CVE-2026-109618, CVE-2026-109619
• CISA: Warnung vom 21. Oktober 2026, KEV-Katalog
• NCSC-NL: Repository php2shell
• NVD: CVE-2026-109618, CVE-2026-109619
• FIRST: EPSS-Werte

Forschung und Analysen:

• Calif: PHP2Shell, a tale of two PHP remote vulnerabilities
• Amazon Threat Intelligence
• watchTowr
• Akamai
• CybelAngel
• php2shell-scanner von Searchlight Cyber

Aktualisierungen:

• 2026-11-11: Die Scores der NVD, EPSS, CWE-Klassen, Credits, neueste sichere Versionen und End-of-Life-Daten in der Infobox ergänzt, dazu PHP 8.6.0 RC4 sowie Abschnitte dazu, wie die Fehler funktionieren, wie Sie den Fix verifizieren und wie Sie auf Kompromittierung prüfen.
• 2026-11-11: Erstveröffentlichung.