Lagebild der VamiSec GmbH · · zertifizierter Wiz Partner

PHP2Shell: Sind Ihre PHP-Systeme betroffen?

Wiz Research hat am 21. Oktober 2026 kritische Speicherfehler im Kern von PHP offengelegt: CVE-2026-109618 und CVE-2026-109619. Angreifer können damit ohne Anmeldung Speicher auslesen und Code ausführen, auch wenn die Anwendung selbst sicher ist. Als zertifizierter Wiz Partner prüft VamiSec kurzfristig, ob Sie betroffen sind: von außen mit Wiz ASM, dem Wiz Red Agent und VamiRedteam, von innen über Konnektoren, die den tatsächlichen Versionsstand belegen.

Blackbox von außen Agentlos von innen Nur mit schriftlicher Freigabe

2 CVEsfür vier von Wiz nachgewiesene Angriffswege
9.2CVSS v4.0 laut PHP, für beide CVEs
ab 5.4laut Wiz ist jede PHP-Version seit gut zehn Jahren betroffen
Pre-Authkeine Anmeldung, kein Fehler im Anwendungscode nötig
21.10.2026Patch und koordinierte Veröffentlichung

Kurzantwort

PHP2Shell ist der Name für zwei kritische Schwachstellen im Kern der Programmiersprache PHP: CVE-2026-109618 und CVE-2026-109619, beide mit CVSS v4.0 9.2 bewertet und am 21. Oktober 2026 veröffentlicht. Bricht PHP einen Request mit einem schweren Fehler ab, vor allem bei Speichermangel, bleibt interner Zustand zurück. Ein späterer Request im selben Worker-Prozess, beim OPcache-Pfad auch ein anderer Worker, verwendet diesen veralteten Zustand weiter.

  • Folge: Angreifer können ohne Anmeldung Teile des Prozessspeichers auslesen, etwa Passwörter, Tokens und API-Schlüssel, und Code auf dem Server ausführen.
  • Reichweite: Der Fehler steckt in PHP selbst. Betroffen sind alle Installationen, die Web-Requests verarbeiten: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Wiz hat die Angriffe gegen die zum Testzeitpunkt aktuellen Container-Images von WordPress, Drupal und Joomla demonstriert.
  • Abhilfe: Aktualisieren Sie auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, oder auf ein Distributionspaket mit Fix, und starten Sie alle PHP-Prozesse neu. Workarounds und WAF-Regeln überbrücken nur.
  • Prüfung: VamiSec ermittelt als zertifizierter Wiz Partner kurzfristig, welche PHP-Systeme aus dem Internet erreichbar sind, und mit der Innensicht auch, welche Instanzen tatsächlich verwundbar sind.

Veröffentlicht: Aktualisiert: Autor: Valeri Milke, VamiSecPrimärquelle: Wiz Research

01 · Überblick

Was Wiz Research gefunden hat

PHP ist die serverseitige Sprache hinter einem Großteil des Webs. WordPress, Drupal, Joomla und MediaWiki, die Software hinter Wikipedia, laufen darauf. Laut W3Techs nutzen 69,3 Prozent aller Websites mit bekannter Serversprache PHP (Stand 22. Oktober 2026). Das deckt sich mit den rund 70 Prozent, die Wiz nennt. Sie beschreibt die Verbreitung von PHP, nicht die Zahl verwundbarer Systeme.

Die Forscher Sagi Tzadik, Shir Tamari, Nir Ohfeld und Tomer Schwartz haben mehrere Speicherfehler im PHP-Kern gefunden. Sie entstehen an derselben Stelle: wenn PHP einen Request wegen eines schweren Fehlers abbricht, meist bei Speichermangel (Out of Memory). Der Kern räumt dann nicht vollständig auf. Ein Zeiger auf bereits freigegebenen Speicher bleibt bestehen, und der nächste Request im selben Worker greift darauf zu.

Aus diesem Muster hat Wiz vier Angriffswege entwickelt. Sie reichen vom Auslesen fremder Speicherbereiche bis zur Codeausführung auf dem Server, jeweils ohne Anmeldung. Wiz sieht in PHP2Shell einen ähnlichen Wendepunkt wie Heartbleed (2014) und Log4Shell (2021). Wie bei Log4Shell liegt die größte Schwierigkeit in der Verbreitung: PHP steckt in Webservern, Container-Images, Appliances und Hosting-Plattformen, oft ohne dass es im Asset-Inventar auftaucht.

Unabhängig von Wiz hatten Calif und OpenAI die Grundursache bereits im August 2026 an das PHP-Team gemeldet. Laut Wiz gibt es über die vier gezeigten Wege hinaus weitere Varianten desselben Musters. Der Patch des PHP-Teams setzt an der Ursache an.

Codeausführung ohne Anmeldung

Wiz hat die Fehler zum Exploit-Skript „php2shell“ verkettet und damit Code auf wordpress:latest, drupal:latest und joomla:latest ausgeführt. Die Anwendungen waren nur Beispiele: Laut Wiz kann schon eine einfache „Hello World“-Anwendung auf einer betroffenen Version angreifbar sein.

Speicher-Leck wie bei Heartbleed

Auch ohne Codeausführung lässt sich Speicher des PHP-Workers auslesen. Er kann Daten anderer Requests oder des Servers enthalten, etwa Passwörter, Session-Tokens, API-Schlüssel und Zertifikate.

Unterhalb der Anwendung

Die Angriffe laufen im PHP-Kern ab, bevor oder während die Anwendung startet. Ein Update von WordPress, Plugins oder Frameworks schützt deshalb nicht. Maßgeblich ist allein die PHP-Laufzeit.

02 · Schwachstellen

Zwei CVEs, vier nachgewiesene Angriffswege

Das PHP-Projekt ist die zuständige CVE-Vergabestelle (CNA). Es beschreibt die beiden CVEs nach Fehlerklasse. Wiz ordnet seine vier Angriffswege im Blog etwas anders zu. Wir zeigen beide Sichten.

Offizieller Titel: „RCE via OOM corruption“ · GHSA-w8hw-w9fx-j79w

CVE-2026-109618: Codeausführung durch Korruption bei Speichermangel

Bei einem Out-of-Memory-Fehler springt PHP bisher per longjmp() aus der laufenden Verarbeitung. Trifft das einen Moment, in dem Request-Speicher erreichbar, aber noch nicht vollständig initialisiert ist, liest der Request-Abbau später ungültigen Zustand. Das kann zur Codeausführung führen.

  • Validiert: vollständige Codeausführung ohne Anmeldung über HTTP gegen Apache mod_php mit Standardlimits, bevor Anwendungscode läuft
  • PHP-FPM laut Quellcodeanalyse anfällig; FrankenPHP wahrscheinlich anfällig, LiteSpeed nicht validiert
  • Fix: verzögerter „Soft OOM“ am nächsten sicheren Punkt und sofortiger Prozessabbruch bei hartem Speichermangel

CVSS v4.0 9.2CWE-416 · CWE-755 · CWE-824 u. a.

Offizieller Titel: „RCE via stale global state“ · GHSA-6wmf-4rv5-p3rp

CVE-2026-109619: Codeausführung durch veralteten globalen Zustand

Ein Worker behält globale Zustände, etwa zu Fehlern, Sessions oder Objekten, die noch in den freigegebenen Speicher eines früheren Requests zeigen. Nutzt ein späterer Request im selben Worker diesen Zustand vor der normalen Initialisierung, entsteht ein Use-after-free.

  • Bestätigt: der Upload-Progress-Pfad des Session-Moduls (standardmäßig aktiv, kein session_start() nötig), validiert gegen mod_php und PHP-FPM
  • Bestätigt: der Backtrace des letzten Fatal Errors in PHP 8.5 (Option fatal_error_backtraces)
  • Wirkung: Auslesen von Speicher und Codeausführung ohne Anmeldung

CVSS v4.0 9.2CWE-416 · CWE-755 · CWE-824 u. a.

Zum CVSS-Wert: PHP bewertet beide CVEs mit 9.2 nach CVSS v4.0 (Vektor AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H). Die hohe Angriffskomplexität (AC:H) spiegelt wider, dass ein Angriff viele präparierte Requests braucht. Die NVD vergibt zusätzlich 9.8 nach CVSS v3.1, CERT-Bund ebenfalls 9.8. Ein vor der Veröffentlichung kursierender Wert von 10.0 war laut PHP Foundation falsch.

Die vier Angriffswege aus der Wiz-Analyse

Von Wiz Research demonstrierte Angriffswege (Quelle: Wiz-Blog, 21.10.2026)
AngriffswegMögliche WirkungVon Wiz demonstriertCVE laut Wiz-Blog
Use-after-free im Unserializer der Upload-Progress-Verarbeitung Speicherkorruption, Codeausführung Codeausführung ohne Anmeldung auf WordPress, Drupal und Joomla CVE-2026-109618
Auslesen von Prozessspeicher über das Session-Cookie Speicherinhalt anderer Requests wird preisgegeben Auslesen von Worker-Speicher ohne Anmeldung, unabhängig von der Anwendung CVE-2026-109618
Use-after-free im Backtrace des letzten Fatal Errors Speicherkorruption, Codeausführung Codeausführung ohne Anmeldung auf Drupal CVE-2026-109619
Typverwechslung (Type Confusion) im OPcache Korruption des gemeinsamen OPcache-Zustands, Codeausführung Codeausführung ohne Anmeldung auf WordPress CVE-2026-109619

Abweichende Zuordnung: Die PHP-Advisories und die Wiz-Seite php2shell.com führen den Upload-Progress-Pfad und das Speicher-Leck unter CVE-2026-109619. Der OPcache-Pfad steht nur in der Wiz-Analyse, nicht in den PHP-Advisories. Für Patch und Abhilfe spielt das keine Rolle: Die gepatchten Versionen beheben beide CVEs.

03 · Technischer Hintergrund

So wird aus einem Speicherfehler ein Angriff

Alle Angriffswege folgen demselben Muster. PHP-Worker wie PHP-FPM oder Apache mit mod_php bearbeiten viele Requests nacheinander. Bricht einer davon hart ab, kann veralteter Zustand in den nächsten Request hinüberwandern.

Request A

Speicher wird knapp

Ein präparierter Request, etwa ein großer Multipart-Upload, treibt PHP noch beim Request-Start in einen Out-of-Memory-Fehler.

Abbruch

Aufräumen bleibt unvollständig

PHP verwirft den Speicher des Requests. Globale Zeiger, etwa auf Session-ID, Unserializer-Status oder Backtrace, zeigen weiter auf den freigegebenen Bereich.

Request B

Gleicher Worker, neuer Inhalt

Der Angreifer belegt den frei gewordenen Speicher neu. PHP behandelt den veralteten Zeiger so, als wäre er noch gültig.

Wirkung

Leck oder Codeausführung

Speicherinhalt landet URL-kodiert im PHPSESSID-Cookie der Antwort. Andere Varianten erlauben gezielte Speicherkorruption bis zur Codeausführung.

Vereinfachte Darstellung nach der technischen Analyse von Wiz Research. Blau: belegter Speicher, gestreift: veralteter Zustand, orange: ausgelesener Speicher.
Session-Modul · Speicher-Leck

Leck über das Session-Cookie

PHP verarbeitet Multipart-Uploads nach RFC 1867 sehr früh, noch bevor die Module vollständig initialisiert sind. Ist die Upload-Fortschrittsanzeige aktiv, und das ist der Standard, legt das Session-Modul dabei schon eine Session-ID an. Ein Out-of-Memory-Fehler an dieser Stelle hinterlässt einen Zeiger auf freigegebenen Speicher. Ein späterer Upload-Request im selben Worker liest den neu belegten Bereich und schreibt ihn in das PHPSESSID-Cookie der Antwort. Das funktioniert auch, wenn die Anwendung nie session_start() aufruft.

Session-Modul · Unserializer

Use-after-free im Upload-Progress-Unserializer

Im selben frühen Zeitfenster kann das Session-Modul Sitzungsdaten dekodieren und legt dafür Verwaltungsdaten des Unserializers global ab. Bricht ein Speicherfehler diesen Pfad ab, bleiben diese Daten global erreichbar, obwohl ihr Speicher bereits freigegeben ist. Wiz hat diesen Fehler mit dem Speicher-Leck kombiniert. Das Leck beseitigt die Unsicherheit über Speicheradressen, und so gelang Codeausführung ohne Anmeldung auf WordPress, Drupal und Joomla.

Engine · PHP 8.5

Use-after-free im Fatal-Error-Backtrace

PHP 8.5 kann den Backtrace des letzten schweren Fehlers in einer globalen Variable speichern. Ein Out-of-Memory-Fehler gibt den Speicher frei, ohne diese Variable zurückzusetzen. Gibt derselbe Worker im nächsten Request früh eine Meldung aus, folgt PHP dem verwaisten Zeiger in vom Angreifer belegten Speicher. Wiz hat damit Codeausführung ohne Anmeldung gegen Drupal gezeigt.

OPcache · Shared Memory

Typverwechslung im gemeinsamen OPcache

OPcache legt kompilierten Code im Shared Memory ab, den alle Worker gemeinsam nutzen. Schlägt beim Ablegen eine Speicheranforderung fehl, weichen der lokale und der gemeinsame Verwaltungsstand voneinander ab. Ein anderer Worker vergibt den Speicherplatz dann neu, und alte Verweise zeigen auf ein Objekt falschen Typs. Wiz hat daraus eine Angriffskette ohne Anmeldung gegen WordPress gebaut.

04 · Betroffenheit

Welche Versionen und Systeme betroffen sind

Entscheidend ist die PHP-Laufzeit, nicht die Anwendung. Gefährdet sind alle Installationen, die Web-Requests verarbeiten: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Projekt stuft mod_php als besonders gefährdet ein, weil der Angriff dort greift, bevor Anwendungscode läuft.

PHP-Zweige, Fix-Stand und Support (Quellen: php.net, PHP-Advisories, Wiz, Calif; Stand 22.10.2026)
PHP-ZweigSupportVerwundbarBehoben in
8.5Aktiver Support bis 31.12.2027vor 8.5.128.5.12
8.4Aktiver Support bis 31.12.2026vor 8.4.278.4.27
8.3Nur Sicherheitsfixes bis 31.12.2027vor 8.3.368.3.36
8.2Nur Sicherheitsfixes, Ende am 31.12.2026vor 8.2.358.2.35
8.1 · 8.0 · 7.4Ohne Supportalle Versionenkein Release Das PHP-Team hat nur minimale Quell-Backports veröffentlicht. Gepatchte Pakete kommen von Distributionen und LTS-Anbietern.
7.3 bis 5.4Ohne Supportlaut Wiz und Calif betroffenkein Upstream-Fix Nur einzelne Distributions- und Hoster-Builds, etwa Debian ELTS oder Ubuntu Pro. Ablösen.

Die offiziellen CVE-Einträge nennen nur die Zweige 8.2 bis 8.5. Daraus folgt nicht, dass ältere Versionen sicher sind: PHP hat Backports für 7.4 bis 8.1 bereitgestellt, und Wiz sowie Calif nennen PHP 5.4 als frühesten betroffenen Stand.

Achtung bei Distributionspaketen: Ubuntu, Red Hat, AlmaLinux, CloudLinux, Debian ELTS und viele Hoster portieren den Fix zurück, ohne die PHP-Versionsnummer zu ändern. Debian trixie und bookworm haben dagegen die neuen Versionen 8.4.27 und 8.2.35 übernommen. Ubuntu 24.04 meldet zum Beispiel weiterhin PHP 8.3.6, ist mit dem Paket 8.3.6-0ubuntu0.24.04.13 aber gepatcht. Maßgeblich ist dann der Paketstand. Umgekehrt beweist eine verborgene Versionsangabe nichts.

Wo PHP oft unbemerkt läuft

  • Container-Images: offizielle php-Images, CMS-Images wie wordpress, drupal und joomla sowie eigene Images auf deren Basis
  • Kubernetes-Workloads mit PHP-FPM hinter Nginx oder Apache, auch in Sidecars, Jobs und CronJobs
  • Virtuelle Maschinen mit PHP aus Distributionspaketen, Drittanbieter-Repositories oder eigenen Builds
  • PaaS und Serverless: App Engine, Cloud Run, Elastic Beanstalk, Azure App Service und ähnliche Dienste, die je nach Konfiguration nicht automatisch aktualisieren
  • Managed und Shared Hosting für Websites, Shops und Landingpages, oft verwaltet von Agenturen oder Fachabteilungen
  • Appliances und Fremdprodukte mit PHP-Weboberfläche, etwa Monitoring-, Ticket- oder Admin-Werkzeuge. Hier hilft nur ein Update des Herstellers. Laut BSI veröffentlichen inzwischen auch immer mehr Hersteller von Netzwerkkomponenten eigene Hinweise, weil PHP in ihren Produkten steckt. Das NCSC-NL pflegt dazu eine öffentliche Liste.

Version oder Ausgabe von php -v einfügen. Läuft vollständig im Browser, es wird nichts übertragen. Ersetzt keine Prüfung aller Instanzen.

Versionen schnell inventarisieren

Diese Befehle lesen nur aus und verändern nichts. Sie helfen bei einer ersten Bestandsaufnahme, ersetzen aber keine vollständige Inventur.

# PHP-Version und Einstellungen. Achtung: php -i zeigt die CLI-Konfiguration.
php -v
php -i | grep -i -E "session.upload_progress.enabled|memory_limit"
# PHP-FPM und mod_php nutzen oft eine eigene php.ini (Binärname je nach Distribution)
php-fpm8.3 -i | grep -i -E "session.upload_progress.enabled|memory_limit"

# Paketstand: Distributionen portieren Fixes oft ohne neue Versionsnummer
dpkg -l | grep -E "^ii\s+(php|libapache2-mod-php)"              # Debian/Ubuntu
apt-get changelog php8.3 | grep -E "CVE-2026-10961[89]"          # Paketnamen anpassen
rpm -q --changelog php-common | grep -E "CVE-2026-10961[89]"     # RHEL/Alma/Rocky/SUSE
apk info -vv | grep -i "^php"                                     # Alpine

# Container-Image: eingebaute PHP-Version auslesen
docker run --rm --entrypoint php <image> -v
docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' <image> | grep PHP_VERSION

# Kubernetes: Pods mit PHP-typischen Images finden
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -i -E "php|wordpress|drupal|joomla|nextcloud|magento|matomo"
Proof of Concept zur Erkennung · Open Source

Aktiv prüfen mit dem php2shell-scanner von Assetnote

Das Forschungsteam von Assetnote hat am 22. Oktober 2026 einen Scanner für CVE-2026-109618 und CVE-2026-109619 veröffentlicht. Er weist das verwundbare Verhalten über HTTP nach, ohne Code auf dem Zielsystem auszuführen. Damit eignet er sich, um Befunde aus Inventar und Außensicht gezielt zu bestätigen.

  • Der Scanner sendet eine kleine Kontrollanfrage und bis zu drei präparierte Multipart-Requests mit 62-fach verschachtelten Array-Schlüsseln, die von 1 MiB auf 20 MiB anwachsen.
  • Als verwundbar gilt ein Ziel, wenn PHP mit einem Speicherfehler, einer leeren HTTP-500-Antwort im Vergleich zur Kontrollanfrage oder einem Ausfall des FPM-Workers reagiert oder eine ungepatchte Version ausweist.
  • Standardmäßig prüft er /index.php. Eigene Pfade, Header und Hostlisten lassen sich angeben, getrennte Regeln für mod_php und PHP-FPM ebenfalls.

Vor dem Einsatz beachten

  • Nur Systeme prüfen, für die Sie berechtigt sind.
  • Je geprüftem Pfad entstehen rund 29 MiB Last, und der Scanner löst bewusst Speicherfehler aus. Planen Sie produktive Systeme in einem Wartungsfenster ein.
  • Bei niedrigem memory_limit meldet der Scanner auch gepatchte Versionen als verwundbar. Gleichen Sie Treffer immer mit installierter Version und Paketstand ab.
VamiSec unterstützt

Analyse, Recon und Attack Surface Management

Wir planen und begleiten den Einsatz des Scanners, werten die Ergebnisse aus und trennen echte Treffer von Fehlalarmen. Ihre externe Angriffsfläche erfassen wir dabei mit VamiRedteam. Die agentische Plattform kartiert Domains, Subdomains, Hosts und exponierte Dienste und arbeitet nur im freigegebenen Umfang: mit signierter Autorisierung, harter Grenze am Scope und lückenlosem Audit-Log.

Analyse anfragen

Stand bei Distributionen und Plattformen

Auswahl, Stand 22.10.2026 vormittags. Prüfen Sie den aktuellen Stand beim jeweiligen Anbieter.
AnbieterStand
DebianBehoben für trixie (DSA-6574-1, php8.4) und bookworm (DLA-4848-1, php8.2); ELTS-Updates für 7.4, 7.3 und 7.0
UbuntuBehoben für 26.10, 26.04 LTS, 24.04 LTS und 22.04 LTS (USN-8948-1); ältere Releases über Ubuntu Pro (USN-8948-2)
Red Hat Enterprise LinuxUpdates für RHEL 8, 9 und 10 laufen (Bulletin RHSB-2026-013, noch nicht abgeschlossen)
AlmaLinuxAlle PHP-Streams auf 8, 9 und 10 gepatcht, mit Suffix .alma.1 an der alten Versionsnummer
SUSEErste Updates veröffentlicht (u. a. SUSE-SU-2026:4843-1), Gesamtstatus noch offen
Alpine Linuxphp83, php84 und php85 auf edge, 3.24 und 3.23 gepatcht; 3.22 und php82 noch offen
Docker Official Imagesphp 8.2 bis 8.5 neu gebaut; wordpress, drupal und joomla:latest am 22.10. mit gepatchtem PHP; EOL-Tags wie 8.1 und 7.4 erhalten keinen Neubau
CloudLinux / cPanelea-php 5.2 bis 8.5 als Backports veröffentlicht, teils mit unveränderter Versionsnummer
Google CloudApp Engine Standard ab PHP 8.2 automatisch; Cloud Run ab PHP 8.2 nur mit automatischen Base-Image-Updates; GKE, App Engine Flexible und eigene Images neu bauen und ausrollen; Laufzeiten mit PHP 8.1 und älter bleiben laut Google verwundbar
AWSAWS-Dienste laut AWS nicht betroffen; Pakete für Amazon Linux; Elastic Beanstalk und Lightsail erfordern Plattform-Update bzw. neue Instanzen

05 · Sofortmaßnahmen

Was jetzt zu tun ist

Die Reihenfolge folgt dem Risiko: zuerst die aus dem Internet erreichbaren Systeme, dann interne Anwendungen, Build-Pipelines und Basis-Images. Das PHP-Projekt sagt dazu: „There are no complete mitigations, updating is the only safe choice.“

  1. Inventar erstellen

    Erfassen Sie alle PHP-Instanzen mit Version und Paketstand: Hosts, Container-Images in Registries, laufende Kubernetes-Pods, PaaS-Dienste, Hosting-Verträge und Appliances. Markieren Sie, was aus dem Internet erreichbar ist.

  2. Patchen und neu starten

    Aktualisieren Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf das gepatchte Paket Ihrer Distribution. Starten Sie danach Apache, PHP-FPM und alle langlebigen PHP-Worker neu, sonst läuft der alte Code weiter.

  3. Images neu bauen und ausrollen

    Bauen Sie Container-Images mit PHP neu, aktualisieren Sie Basis-Images und rollen Sie die Pods neu aus. Ein Patch auf dem Host schützt keine Container, die ihr eigenes PHP mitbringen.

  4. Altversionen ablösen

    Für PHP 8.1 und älter gibt es kein offizielles Release mit Fix. Nutzen Sie gepatchte Pakete eines LTS-Anbieters oder migrieren Sie auf 8.4 oder 8.5. Was sich nicht patchen lässt, sollten Sie nach Empfehlung von BSI und CISA vorübergehend vom Internet trennen.

  5. Übergangsschutz, wo das Patchen dauert

    PHP nennt Übergangsmaßnahmen, die das Risiko senken, aber nicht beseitigen. Das BSI rät, sie alle gemeinsam umzusetzen. Sie wirken nur, wenn sie in der php.ini, im FPM-Pool oder in der Serverkonfiguration stehen, nicht per ini_set() oder .user.ini. Danach müssen alle Worker neu starten.

  6. Auf Angriffsspuren prüfen

    Werten Sie Logs mindestens ab dem 17. Oktober 2026 aus. Amazon hat an diesem Tag den ersten Angriffsversuch auf seine Honeypots beobachtet. Die Merkmale stehen im Abschnitt Erkennung.

  7. Zugangsdaten tauschen, wenn es Hinweise gibt

    Das Speicher-Leck kann Passwörter, Tokens, API-Schlüssel und Zertifikate offenlegen. Gibt es Anzeichen eines Angriffs vor dem Patch, rotieren Sie diese Geheimnisse und machen Sie Sitzungen ungültig.

  8. Dokumentieren und Meldepflichten prüfen

    Halten Sie Inventar, Patch-Zeitpunkte und Befunde fest. Bei Hinweisen auf eine Ausnutzung prüfen Sie die Meldepflichten nach NIS2, DSGVO, DORA oder CRA.

Übergangsmaßnahmen laut PHP · nicht vollständig

Konfiguration

  • session.upload_progress.enabled = 0 blockiert die bestätigten Session-Pfade, nicht aber andere Varianten. PHP rät, die Option auch nach dem Patch aus zu lassen, wenn sie nicht gebraucht wird.
  • fatal_error_backtraces = 0 (nur PHP 8.5) blockiert den bestätigten Backtrace-Pfad.
  • memory_limit = -1, per php_admin_value fest gesetzt, damit Anwendungen den Wert nicht überschreiben können, kombiniert mit einem Speicherlimit über Container oder cgroup. Kein RLIMIT_AS oder RLIMIT_DATA verwenden.
  • post_max_size = 8M, bei Uploads 32M, mit upload_max_filesize darunter.
  • Niedriges pm.max_requests in PHP-FPM, im Extremfall 1, wenn die Leistung es erlaubt.
  • Fehlerausgaben zu verbergen hilft nicht: display_errors, error_reporting oder @ schützen nicht.
Vorgelagert · Härtung

Webserver, Proxy und System

  • Limits am Webserver oder Proxy für Request-Größe, Zahl der Felder, Multipart-Teile, Header und Verschachtelungstiefe, auch für Requests ohne verwertbare Content-Length
  • Multipart-Uploads sperren, wo sie nicht gebraucht werden
  • SELinux oder AppArmor, um die Folgen einer Codeausführung einzugrenzen
  • WAF- und CDN-Regeln als zusätzliche Schicht (siehe unten). Direkter Verkehr zum Origin-Server umgeht sie.

Laut PHP schließt memory_limit = -1 den Fehler nicht vollständig, weil auch andere Speicheranforderungen scheitern können. Ohne Containerlimit erhöht die Einstellung zudem das Risiko, dass der Server den gesamten Speicher aufbraucht.

WAF und CDN: wer was bereitstellt

Schutzregeln der Anbieter, Stand 22.10.2026. Alle Anbieter betonen: kein Ersatz für den Patch.
AnbieterSchutzAutomatisch aktiv?
CloudflareManaged Rules „Generic Rules – Anomalous Execution“ und eine Regel für Antwortenja für alle WAF-Pläne inklusive Free, seit 21.10., 03:02 UTC
VercelWAF-Regeln gegen bekannte php2shell-Muster, auch für Proxies zu externen PHP-Backendsja für alle Projekte
AWS WAFPHP-Regelgruppe Version 2.3 mit Regel PHP2Shell_BODY, dazu SizeRestrictions_BODY aus dem Core Rule Setteilweise nur wenn die Regelgruppen im WebACL eingebunden sind
Azure Front DoorManaged Rule 99006001, die schädliche Teile aus Antworten entferntnein standardmäßig aus, Rollout bis 28.10.
Google Cloud ArmorManaged Rules, Kategorien File Upload und RFI empfohlenteilweise nur bei bereits aktiven Managed Rules
Fastly Next-Gen WAFCVE-spezifische Template-Regel für beide CVEsnein muss aktiviert werden
AkamaiAdaptive-Security-Engine-Regel 3000991nicht angegeben
Imperva Cloud WAFSchutz ohne Konfiguration, Elastic WAF und WAF Gateway brauchen Updatesja laut Imperva

06 · Erkennung

Woran Sie einen Angriff erkennen können

Die Merkmale stammen von Wiz, Fastly, Amazon, Huntress und CrowdStrike. Sie sind Ansatzpunkte für eine Untersuchung, kein Beweis. Laut Wiz schließt ihr Fehlen eine Betroffenheit nicht aus.

Netzwerk und Requests

Auffällige Anfragen

  • Multipart-Uploads mit dem Feld PHP_SESSION_UPLOAD_PROGRESS
  • Form-POSTs über 1 bis 2 MB oder mit tief verschachtelten Feldnamen in eckigen Klammern
  • Auffällig große oder fehlerhafte PHPSESSID-Cookies in Antworten
  • Viele gleichartige Requests in kurzer Folge
Logs

Fehlerbilder

  • Memory-Limit-Fehler mit dem Zusatz in Unknown on line 0
  • Gehäufte HTTP-500-Antworten nach Multipart-Requests
  • Segfault-Meldungen von Apache (AH00052) und unerklärliche Neustarts von PHP-Workern

CrowdStrike weist darauf hin, dass ein erfolgreicher Angriff auch unauffällig mit HTTP 200 enden kann.

Host

Folgen einer Codeausführung

  • PHP-Prozesse wie php-fpm, php-cgi, httpd oder apache2, die Shells, Interpreter oder curl, wget und nc starten
  • Befehle wie /bin/sh -c, whoami, id, uname
  • Neue Dateien im Web-Root, neue Cronjobs oder Konten

Verdacht auf Kompromittierung? Unser CSIRT ist rund um die Uhr unter csirt@vamisec.com erreichbar. Ein Compromise Assessment klärt, ob Angreifer bereits im System sind.

07 · Lage und Hintergrund

Wird PHP2Shell schon ausgenutzt?

Die Quellen widersprechen sich und die Lage ändert sich schnell. Stand gilt: Angriffsversuche werden breit gemeldet, erfolgreiche Angriffe auf reale Systeme hat keine Behörde bestätigt.

Behörden

Noch keine bestätigte Ausnutzung

Dem BSI ist laut seinem Sicherheitshinweis (Version 1.2, Update vom 22.10.) noch keine erfolgreiche Ausnutzung in der Breite bekannt. Proof-of-Concept-Code ist öffentlich. CISA hatte zum 21.10. keine Ausnutzung beobachtet. Im CISA-Katalog bekannter ausgenutzter Schwachstellen (KEV) stehen die CVEs nicht.

Sicherheitsanbieter

Angriffsversuche gemeldet

Amazon Threat Intelligence sah einen ersten Versuch am 17.10. auf eigenen Honeypots und spricht seit dem 21.10. von breiter Ausnutzung, wobei der Erfolg unklar sei. Cloudflare beobachtet Angriffsverkehr und Versuche, die eigenen Regeln zu umgehen. Huntress und Cisco Talos fanden am 21.10. keine erfolgreiche Ausnutzung.

Exploit-Code

Vorsicht bei öffentlichen PoCs

Wiz und Calif veröffentlichen ihren Exploit nicht. Auf GitHub kursieren zahlreiche angebliche PoCs. Einige beruhen auf widerlegten Annahmen, andere könnten Schadcode enthalten. Für die Erkennung gibt es mit dem Scanner von Assetnote ein nachvollziehbares Open-Source-Werkzeug.

Warum ein alter Fehler jetzt ausnutzbar ist

Der verwundbare Code steckt laut Wiz seit mehr als zehn Jahren in PHP. Ihn auszunutzen war bisher extrem aufwendig: Mehrere Fehler müssen verkettet und an das Speicherlayout jeder Zielumgebung angepasst werden. Schon eine andere PHP-Version, Konfiguration oder Anwendung kann die Annahmen eines Exploits brechen.

Genau diese Anpassungsarbeit übernehmen heute KI-Modelle. Wiz hat für die Forschung den eigenen KI-Agenten Wiz Atlas sowie die Modelle Gemini 4 Argon und GPT-5.6 Sol eingesetzt. Laut Wiz schaffte ein einzelner Forscher so in einer Woche, wofür früher ein Spitzenteam Monate gebraucht hätte. Calif arbeitete laut OpenAI mit GPT-5.6 Sol, das PHP-Team nutzte zur Validierung ebenfalls KI-Werkzeuge.

Für Verteidiger heißt das: Komplexität schützt nicht mehr zuverlässig. Schwachstellen, die als theoretisch galten, werden praktisch ausnutzbar. Dieselben Werkzeuge helfen aber auch beim Finden und Beheben, wie dieser Fall zeigt.

Zeitleiste

  1. Calif und OpenAI melden die Grundursache unabhängig voneinander an das PHP-Team (laut PHP Foundation).
  2. Wiz Research findet die erste Schwachstelle, am 20. und 21.08. folgt Codeausführung gegen Drupal und WordPress.
  3. Wiz meldet seine Angriffswege an das PHP-Security-Team.
  4. PHP bestätigt die Wiz-Meldungen und arbeitet an einem koordinierten Fix.
  5. Amazon beobachtet einen ersten Angriffsversuch auf Honeypots.
  6. Die CVE-Nummern sickern durch. PHP zieht die Veröffentlichung um einen Tag vor.
  7. PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Wiz, Calif, OpenAI und die PHP Foundation legen die Details offen. BSI und CISA warnen.
  8. Distributionen und Plattformen liefern Updates nach, Angriffsversuche nehmen zu.

08 · Wiz-Abdeckung

Was Wiz für PHP2Shell bereitstellt

Wiz-Kunden finden im Threat Intel Center ihres Wiz-Tenants ein eigenes PHP2Shell-Advisory. Laut Wiz enthält es Erkennung, Reaktion und Anleitungen zur Behebung.

Agentlose Schwachstellenerkennung

Wiz liest über read-only Cloud-Schnittstellen und Disk-Snapshots, welche PHP-Pakete auf VMs, in Container-Images, Registries und Serverless-Funktionen stecken, ohne Agenten. Der Security Graph zeigt, welche verwundbaren Instanzen aus dem Internet erreichbar sind.

Laufzeit-Erkennung mit Wiz Defend

Der eBPF-basierte Wiz Runtime Sensor erkennt Verhalten, das typisch für die Ausnutzung von PHP2Shell ist. Ab Sensor-Version 1.0.12768 lässt sich eine Response Policy aktivieren, die solche Prozesse automatisch beendet. Wir empfehlen, sie zuerst im Simulationsmodus zu testen.

Behebung und Threat Hunting

Das Advisory liefert Anleitungen zur Behebung und zur Suche nach Angriffsspuren. Laut Google Cloud kann der Wiz Green Agent daraus ressourcengenaue Schritte ableiten. Ebenfalls laut Google Cloud stehen gepatchte PHP-Images von WizOS allen Wiz-Kunden 60 Tage lang ohne Zusatzkosten bereit.

Wiz nennt für PHP2Shell ausdrücklich die agentlose und die Laufzeit-Erkennung. Für Wiz ASM und den Red Agent beansprucht Wiz keine PHP2Shell-spezifische Erkennung. Wir setzen sie daher nicht als PHP2Shell-Scanner ein, sondern für die Außensicht: Welche PHP-Systeme sind erreichbar, und wo liegen Geheimnisse offen? Das Wiz Threat Briefing zu PHP2Shell ist als Aufzeichnung verfügbar.

09 · VamiSec-Betroffenheitsprüfung

Wir prüfen kurzfristig, ob PHP2Shell Sie betrifft

Als zertifizierter Wiz Partner setzen wir die Wiz-Plattform gezielt für PHP2Shell ein. Sie entscheiden, wie tief wir schauen: nur von außen, ohne Zugang zu Ihrer Umgebung, oder zusätzlich von innen über read-only Konnektoren. Am Ende steht eine priorisierte Liste, welche Systeme Sie zuerst patchen müssen.

Variante A · von außen

Blackbox-Prüfung

Wir betrachten Ihre Umgebung so, wie ein Angreifer sie aus dem Internet sieht. Sie brauchen uns dafür keinen Zugang zu geben.

  • Wiz ASM findet Ihre erreichbaren Domains, Subdomains, IP-Adressen und API-Endpunkte, ausgehend von Ihren Stammdomains
  • Wir identifizieren PHP-Stacks und Versionsmerkmale. Die Attack Surface Rules von Wiz prüfen erreichbare Dienste zusätzlich auf bekannte Schwachstellen, Fehlkonfigurationen und offengelegte Geheimnisse
  • Der Wiz Red Agent testet erreichbare Web-Anwendungen und APIs als KI-gestützter Angreifer auf Logikfehler, Autorisierungslücken und offengelegte Daten. Einen eigenen PHP2Shell-Test nennt Wiz dafür nicht
  • Offengelegte Geheimnisse prüft er darauf, ob sie noch gültig sind und worauf sie Zugriff geben
  • Ergänzend erfassen wir Ihre Angriffsfläche mit Recon und Attack Surface Management von VamiRedteam und bestätigen Verdachtsfälle nach Freigabe mit dem Scanner von Assetnote

Ergebnis: Liste Ihrer erreichbaren PHP-Systeme mit Risikobewertung. Von außen erhalten Sie Indizien, aber keine Gewissheit über den Patch-Stand.

Variante B · von innen

Cloud- und Kubernetes-Prüfung

Wir verbinden Wiz mit Ihren Cloud-Konten und Clustern, mit minimalen Leserechten und ohne Agenten auf Ihren Workloads. Für den Scan legt Wiz kurzzeitig Disk-Snapshots an und löscht sie danach wieder.

  • Read-only Cloud-Konnektoren für AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud und VMware vSphere
  • Agentloser Scan von VMs, Container-Images, Registries und Serverless-Funktionen auf installierte PHP-Pakete und Versionen. Paketstände mit zurückportierten Fixes gleichen wir mit den Hinweisen der Distributionen ab
  • Kubernetes-Konnektor per Helm-Chart mit lesenden Rechten für EKS, AKS, GKE, OpenShift und selbst betriebene Cluster
  • Optional und nur nach gesonderter Freigabe der Wiz Runtime Sensor, ein eBPF-Sensor auf Hosts und Knoten, um Angriffe zur Laufzeit zu erkennen. Er setzt eine passende Wiz-Lizenz voraus

Ergebnis: belastbares Inventar für die verbundenen Konten und Cluster, welche Workloads welche PHP-Version nutzen und welche davon verwundbar sind. Selbst kompiliertes PHP und Appliances prüfen wir gesondert.

01 · Erstgespräch

Umfang klären

In 30 Minuten klären wir Domains, Cloud-Anbieter, Cluster und Ihre Prioritäten.

02 · Freigabe

Schriftlich autorisieren

Sie geben den Umfang schriftlich frei. Ohne Freigabe testen wir nichts.

03 · Prüfung

Außen- und Innensicht

Wir führen die vereinbarten Prüfungen durch und melden kritische Funde sofort.

04 · Ergebnis

Bericht und Maßnahmenplan

Sie erhalten eine Management-Zusammenfassung, die technische Befundliste und die Patch-Reihenfolge.

Was wir von Ihnen brauchen
  • Für die Außensicht: Ihre Stammdomains und bekannten IP-Bereiche sowie eine schriftliche Freigabe des Prüfumfangs
  • Für die Innensicht: eine read-only Rolle je Cloud-Konto, die wir gemeinsam anlegen, und die Installation des Kubernetes-Konnektors per Helm
  • Eine Ansprechperson aus Betrieb oder IT-Sicherheit für Rückfragen
So gehen wir vor
  • Wir arbeiten nur im freigegebenen Umfang und stimmen Testzeitfenster mit Ihnen ab
  • Aktive Verifikation einzelner Systeme, etwa mit dem Assetnote-Scanner, nur nach gesonderter schriftlicher Freigabe und in einem abgestimmten Zeitfenster, weil sie gezielt Speicherfehler auslöst und PHP-Worker zum Absturz oder Neustart bringen kann
  • Vertraulichkeit regeln wir vorab per NDA, die Verarbeitung von Prüfdaten bei Bedarf per Auftragsverarbeitungsvertrag
  • Bei Hinweisen auf eine Kompromittierung schalten wir auf Wunsch sofort unser CSIRT ein

Betroffenheitsprüfung anfragen

Buchen Sie direkt einen Termin oder schreiben Sie an wiz@vamisec.com. Wir antworten innerhalb von 24 Stunden. Nennen Sie gern schon Domains, Cloud-Anbieter und Cluster, dann können wir den Umfang sofort einschätzen.

Wiz Partner Badge Technical Foundations Wiz Partner Badge Demo Accreditation

10 · Meldepflichten

Wann Sie PHP2Shell melden müssen

Eine ungenutzte Schwachstelle allein löst in Deutschland und der EU keine Meldepflicht aus. Das ändert sich, wenn sie bei Ihnen ausgenutzt wurde. Hersteller, die PHP in eigenen Produkten ausliefern, müssen zudem melden, sobald es verlässliche Hinweise auf eine aktive Ausnutzung gibt. Anbieter digitaler Infrastruktur und Dienste, IKT-Dienstleister und Finanzunternehmen können außerdem verpflichtet sein, ihre Kunden schon bei einer erheblichen Cyberbedrohung über mögliche Schutzmaßnahmen zu informieren. Die Fristen beginnen mit der Kenntnis vom Vorfall, nicht mit der Veröffentlichung der CVE. Diese Übersicht ist eine Orientierung und keine Rechtsberatung.

NIS2 · BSI-Gesetz §§ 30, 32, 35

Wichtige und besonders wichtige Einrichtungen

Schwachstellen zu behandeln und zu patchen ist Teil des Risikomanagements, das das BSI-Gesetz vorschreibt. Melden müssen Sie einen erheblichen Sicherheitsvorfall, etwa einen erfolgreichen unbefugten Zugriff, der den Betrieb schwer stören kann. Dann gilt: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht einen Monat nach der Meldung.

DSGVO · Art. 33, 34

Wenn personenbezogene Daten betroffen sind

Hat das Speicher-Leck personenbezogene Daten oder Zugangsdaten offengelegt, melden Sie das der Aufsichtsbehörde binnen 72 Stunden, außer es besteht voraussichtlich kein Risiko. Bei hohem Risiko informieren Sie die Betroffenen unverzüglich. Jede Datenpanne ist zu dokumentieren.

Cyber Resilience Act · Art. 14

Hersteller, die PHP in Produkten ausliefern

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten über die Meldeplattform der ENISA melden, auch für bereits verkaufte Produkte. Das betrifft etwa Appliances oder Software mit eingebettetem PHP. Fristen: 24 Stunden, 72 Stunden und ein Abschlussbericht 14 Tage nach Verfügbarkeit eines Fixes. Website-Betreiber sind nicht Adressat.

DORA · Art. 19

Finanzunternehmen

Banken, Versicherer und andere Finanzunternehmen melden nicht nach dem BSI-Gesetz, sondern nach DORA an ihre Aufsicht. Ein erfolgreicher, böswilliger Zugriff ist dort ein zentrales Kriterium für einen schwerwiegenden IKT-Vorfall. Die Erstmeldung ist binnen 4 Stunden nach der Einstufung fällig, spätestens 24 Stunden nach Kenntnis.

Ein abgewehrter Angriffsversuch ist in der Regel kein meldepflichtiger Vorfall, sondern allenfalls ein Beinahevorfall. Freiwillige, auch anonyme Meldungen an das BSI sind trotzdem möglich. Vertiefung: NIS2, Cyber Resilience Act, DORA.

11 · FAQ

Häufige Fragen zu PHP2Shell

Was ist PHP2Shell?

PHP2Shell ist der Name für zwei kritische Schwachstellen im Kern von PHP: CVE-2026-109618 und CVE-2026-109619. Sie entstehen, wenn PHP einen Request wegen Speichermangels abbricht und interner Zustand zurückbleibt, den ein späterer Request weiterverwendet. Angreifer können so ohne Anmeldung Speicher auslesen und Code ausführen. Veröffentlicht wurden die Lücken am 21. Oktober 2026 von Wiz Research, Calif, OpenAI und dem PHP-Projekt.

Bin ich von PHP2Shell betroffen?

Betroffen ist jede PHP-Installation, die Web-Requests verarbeitet und älter ist als 8.2.35, 8.3.36, 8.4.27 oder 8.5.12, sofern kein gepatchtes Distributionspaket installiert ist. Das gilt für PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP 8.1 und älter erhalten kein offizielles Release mit Fix.

Welche PHP-Versionen sind sicher?

Sicher sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie neuere Versionen. Pakete von Distributionen wie Debian, Ubuntu oder Red Hat können den Fix auch ohne neue Versionsnummer enthalten. Prüfen Sie dann das Paket-Changelog auf beide CVE-Nummern.

Was gilt für PHP 8.1, 8.0, 7.4 und ältere Versionen?

Für diese Zweige veröffentlicht das PHP-Projekt keine Updates mehr. Für 7.4, 8.0 und 8.1 hat es nur minimale Quell-Backports bereitgestellt, für ältere Versionen gar keinen Fix. Nutzen Sie gepatchte Pakete eines LTS-Anbieters oder migrieren Sie auf PHP 8.4 oder 8.5. BSI und CISA raten, nicht patchbare Systeme vorübergehend vom Internet zu trennen.

Reicht ein Update von WordPress, Drupal oder Joomla?

Nein. Die Schwachstellen liegen in der PHP-Laufzeit, nicht in der Anwendung. Ein Update von CMS, Themes oder Plugins schützt nicht. Sie müssen PHP selbst aktualisieren und danach alle PHP-Prozesse neu starten.

Wird PHP2Shell bereits aktiv ausgenutzt?

Stand 23. Oktober 2026 melden Amazon, Cloudflare und andere Anbieter breite Angriffsversuche. BSI und CISA haben aber noch keine erfolgreiche Ausnutzung bestätigt, und die CVEs stehen nicht im KEV-Katalog der CISA. Behandeln Sie aus dem Internet erreichbare PHP-Systeme trotzdem so, als würden sie angegriffen.

Schützt eine WAF oder ein CDN vor PHP2Shell?

Nur teilweise. Cloudflare, Vercel, AWS, Google, Akamai, Imperva, Fastly und Microsoft haben Regeln veröffentlicht, teils automatisch aktiv, teils nicht. Alle betonen, dass sie den Patch nicht ersetzen. Angreifer variieren ihre Anfragen, und Verkehr, der direkt zum Server geht, umgeht die WAF.

Gibt es Workarounds, wenn ich nicht sofort patchen kann?

Ja, aber nur teilweise wirksame. PHP empfiehlt unter anderem session.upload_progress.enabled = 0, auf PHP 8.5 fatal_error_backtraces = 0, ein kleineres post_max_size und memory_limit = -1 zusammen mit einem Container-Speicherlimit. Die Einstellungen gehören in die php.ini oder den FPM-Pool, danach müssen alle Worker neu starten.

Gibt es einen Scanner oder Proof of Concept für PHP2Shell?

Ja. Assetnote hat den Open-Source-Scanner php2shell-scanner auf GitHub veröffentlicht (github.com/assetnote/php2shell-scanner). Er weist das verwundbare Verhalten über präparierte Multipart-Requests nach, ohne Code auszuführen, erzeugt aber rund 29 MiB Last je Pfad und löst Speicherfehler aus. Setzen Sie ihn nur auf eigene oder freigegebene Systeme ein und gleichen Sie Treffer mit dem Paketstand ab. VamiSec unterstützt bei Planung und Auswertung, inklusive Recon und Attack Surface Management mit VamiRedteam.

Muss ich PHP-FPM oder Apache nach dem Update neu starten?

Ja. Laufende Worker behalten den alten Code im Speicher. Starten Sie Apache, PHP-FPM und alle langlebigen PHP-Prozesse neu, und rollen Sie Container mit neu gebauten Images aus.

Wie finde ich verwundbares PHP in Containern und Kubernetes?

Prüfen Sie die PHP-Version in jedem Image, etwa über die Umgebungsvariable PHP_VERSION oder php -v, und gleichen Sie die laufenden Pods mit den Images ab. Basis-Images aus Registries und CI-Pipelines gehören dazu. Wiz kann das agentlos für verbundene Cloud-Konten, Registries und Cluster übernehmen. Selbst kompiliertes PHP und Appliances sollten Sie zusätzlich prüfen.

Welche Daten können abfließen, und muss ich Schlüssel tauschen?

Das Speicher-Leck kann Daten anderer Requests und des Servers enthalten, etwa Passwörter, Session-Tokens, API-Schlüssel und Zertifikate. Gibt es Hinweise auf einen Angriff vor dem Patch, sollten Sie diese Geheimnisse rotieren und aktive Sitzungen ungültig machen.

Muss ich PHP2Shell melden?

Die Schwachstelle allein ist nicht meldepflichtig. Eine Meldepflicht entsteht bei einem erheblichen Sicherheitsvorfall nach NIS2, bei einer Datenpanne nach DSGVO, bei einem schwerwiegenden IKT-Vorfall nach DORA oder für Hersteller bei einer aktiv ausgenutzten Schwachstelle im eigenen Produkt nach dem Cyber Resilience Act.

Wie läuft die Betroffenheitsprüfung von VamiSec ab?

Nach einem 30-minütigen Erstgespräch und Ihrer schriftlichen Freigabe prüfen wir von außen mit Wiz ASM, dem Wiz Red Agent und VamiRedteam. Auf Wunsch prüfen wir zusätzlich von innen über read-only Wiz-Konnektoren für Cloud und Kubernetes. Sie erhalten eine priorisierte Befundliste und einen Maßnahmenplan. Kritische Funde melden wir sofort.

Welchen Zugang braucht VamiSec für die Prüfung?

Für die Außensicht keinen, nur Ihre Domains, IP-Bereiche und eine schriftliche Freigabe. Für die Innensicht eine read-only Rolle je Cloud-Konto und den Kubernetes-Konnektor von Wiz. Beide arbeiten mit minimalen, überwiegend lesenden Rechten und installieren keine Agenten auf Ihren Workloads. Für den agentlosen Scan erstellt Wiz kurzzeitig Disk-Snapshots, und der Kubernetes-Konnektor darf standardmäßig alle Ressourcen im Cluster lesen, auch Secrets.

Wo werden die Daten bei der Prüfung verarbeitet?

Wiz bietet Tenants in der EU an. Welchen Tenant wir für Ihre Prüfung nutzen, legen wir vorab mit Ihnen fest. Scans verbundener Cloud-Ressourcen laufen laut Wiz in der Region der jeweiligen Ressource. Einzelne Verarbeitungen, etwa für Support und Nutzungsanalysen, finden laut Subprozessorliste auch außerhalb der EU statt. Für Analysen des Red Agent nutzt Wiz laut seiner Subprozessorliste einen globalen Endpunkt. Wenn Sie strikte Vorgaben zur Datenresidenz haben, stimmen wir den Einsatz des Red Agent vorab mit Ihnen ab.

12 · Quellen

Primärquellen und Hinweise der Anbieter

Diese Seite fasst die Veröffentlichungen mit eigenen Worten zusammen. Verbindlich sind die Originalquellen. Wir aktualisieren die Seite, sobald sich die Lage ändert.

  1. PHP2Shell: AI uncovers critical RCE vulnerabilitiesWiz Research, 21.10.2026
  2. php2shell.comWiz, Übersicht mit Versionen und Übergangsmaßnahmen
  3. Critical remote code execution vulnerabilities, update nowPHP-Projekt, Advisory vom 21.10.2026
  4. GHSA-w8hw-w9fx-j79w (CVE-2026-109618)PHP-Projekt, GitHub Security Advisory
  5. GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)PHP-Projekt, GitHub Security Advisory
  6. Today's PHP security releaseThe PHP Foundation, 21.10.2026
  7. CVE-2026-109618 und CVE-2026-109619CVE-Einträge der CNA PHP
  8. NVD: CVE-2026-109618National Vulnerability Database
  9. PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweitBSI, IT-Sicherheitshinweis BITS-H 2026-297981-1132, Version 1.2 vom 22.10.2026
  10. WID-SEC-2026-4055CERT-Bund, Warn- und Informationsdienst
  11. Security Advisory 2026-018CERT-EU, 21.10.2026
  12. Joint statement on critical PHP vulnerabilitiesEU-Kommission, ENISA, CERT-EU, Europol, CSIRTs Network
  13. Critical Vulnerabilities in PHP Require Immediate PatchingCISA, 21.10.2026
  14. PHP2ShellCalif
  15. Patch the Planet: global response coordinationOpenAI, 21.10.2026
  16. Responding to core PHP vulnerabilitiesGoogle Cloud
  17. PHP vulnerabilities: WAF protectionCloudflare
  18. Proactive protection for critical PHP RCEFastly
  19. PHP2Shell security bulletinVercel
  20. Security Bulletin 2026-143-AWSAWS
  21. PHP2Shell exploitation prior to public disclosureAmazon Threat Intelligence
  22. Addressing PHP2Shell: upgrade guidance and Azure WAFMicrosoft
  23. Critical RCE vulnerabilities in PHP coreAkamai
  24. PHP2Shell vulnerability updatesImperva
  25. PHP2Shell hunting guidanceHuntress
  26. PHP RCE zero-daysCrowdStrike
  27. assetnote/php2shell-scannerAssetnote, Open-Source-Scanner zur Erkennung, 22.10.2026
  28. NCSC-NL/php2shellNCSC-NL, Liste betroffener Software
  29. VamiRedteamVamiSec, agentische Plattform für Recon, Attack Surface Management und Pentests
  30. Usage statistics of PHPW3Techs, 22.10.2026
  31. Wiz ASM auto recon · Wiz Red Agent · Agentless scanningWiz, Produktinformationen

Klarheit über Ihre PHP-Systeme

Wir zeigen Ihnen, wo PHP in Ihrer Umgebung läuft, welche Instanzen verwundbar und erreichbar sind und was Sie zuerst tun sollten.