PHP2Shell: Kritische PHP Sicherheitslücke (CVE-2026-109618 & CVE-2026-109619)

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Kurzfassung

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen im PHP-Core veröffentlicht: CVE-2026-109618 und CVE-2026-109619, zusammen als PHP2Shell bekannt. Beide wurden als kritisch eingestuft, mit jeweils 9,2 von 10 nach CVSS v4.0, und können es einem Angreifer ermöglichen, ohne Zugangsdaten Code auf Deinem Server auszuführen – eine unauthentifizierte PHP Remote Code Execution, kurz RCE. Die PHP Sicherheitslücke 2026 zählt damit zu den schwerwiegendsten Lücken in der Geschichte der Sprache.

Betroffen sind alle PHP-Versionen seit PHP 5.4 bis einschließlich 8.5.11 – also praktisch jede PHP-Installation, die Webrequests verarbeitet, egal ob WordPress, Joomla, Drupal, TYPO3 oder eine kleine selbstgebaute Anwendung. Die Schwachstelle steckt im PHP-Core selbst, nicht in einem CMS oder Plugin.

Gepatcht sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere Versionszweige (8.1 und darunter, inklusive PHP 7.x) erhalten kein offizielles Release mehr. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat zur PHP Sicherheitslücke eine Cybersicherheitswarnung veröffentlicht und fordert unverzügliches Handeln.

Betroffene und gepatchte PHP-Versionen

Was ist PHP2Shell?

Die PHP2Shell Sicherheitslücke ist zweigeteilt: PHP2Shell ist der Sammelname für zwei Schwachstellen im PHP-Core. Beide sind Speicherfehler vom Typ Use-after-Free (CWE-416): PHP verwendet internen Zustand weiter, obwohl der zugehörige Speicher bereits freigegeben wurde. Der Name spielt bewusst auf Log4Shell an, die kritische Java-Lücke von 2021 – und wie dort sitzt das Problem nicht in einer einzelnen Anwendung, sondern in einer Komponente, auf der fast alles aufbaut.

Die kurzen Fachbegriffe vorweg:

• Remote Code Execution (RCE): PHP führt dabei vom Angreifer kontrollierten Code auf Deinem Server aus – ohne Login, ohne Interaktion eines Nutzers.
• Out-of-Memory (OOM): PHP bricht einen Request ab, wenn er das konfigurierte Speicherlimit (memory_limit) erreicht.
• Speicherbeschädigung / Memory Corruption: Programmfehler, bei denen Speicherinhalte ungültig werden und vom Programm später falsch interpretiert werden – die technische Grundlage vieler RCE-Exploits.

CVE-2026-109618: RCE durch Out-of-Memory-Korruption

PHP bricht einen Request per longjmp() ab, wenn das Speicherlimit erreicht wird. Dabei kann PHP mitten in der Verarbeitung stehen – etwa beim Parsen eines multipart/form-data-Requests (dem Format, das Browser für Formulare mit Datei-Uploads verwenden). Die dann noch teilweise initialisierten Request-Daten werden beim Aufräumen fälschlich als gültig behandelt. Der Speicher dahinter kann noch Daten früherer, vom Angreifer kontrollierter Allokationen enthalten.

Das Ergebnis: Ein einzelner, speziell gebauter HTTP-Request kann den PHP-Worker bereits bei der Request-Verarbeitung kompromittieren – bevor überhaupt eine Zeile Deines Anwendungscodes läuft. Auf Apache mit mod_php wurde vollständige Remote Code Execution mit Standardeinstellungen demonstriert; auf PHP-FPM wurde RCE über applikationsseitige Codepfade bestätigt.

CVE-2026-109619: RCE durch veralteten globalen Zustand

PHP-Worker (mod_php-Prozesse, FPM-Worker) bearbeiten viele Requests nacheinander. Zwischen zwei Requests muss interner Zustand sauber zurückgesetzt werden. Bei dieser Schwachstelle kann ein fataler Fehler – etwa durch Speichererschöpfung – einen Request so abbrechen, dass globaler Zustand auf Speicher des alten Requests zeigt, der längst freigegeben ist. Ein Folge-Request desselben Workers verwendet diesen veralteten Zustand, bevor die normale Initialisierung ihn ersetzt.

Konkret bestätigte Wege sind unter anderem frühe INI-Diagnostiken (bei mod_php werden .htaccess- und php_value-Konfigurationen vor dem eigentlichen Request-Start ausgewertet), die Session-Upload-Fortschrittsfunktion (session.upload_progress.enabled ist standardmäßig aktiv) und unter PHP 8.5 die Option fatal_error_backtraces. Ein Proof of Concept wurde gegen eine reale Anwendung auf Apache mit mod_php demonstriert.

Memory Disclosure nach Heartbleed-Muster

Neben der Codeausführung zeigten die Forscher, dass sich über die Schwachstellen auch Teile des PHP-Prozessspeichers auslesen lassen – vergleichbar mit Heartbleed bei OpenSSL. Darin können Session-Tokens, Passwörter, API-Keys oder Zertifikate anderer Requests stecken. Diese Angriffsform braucht keine vorherige Codeausführung und ist entsprechend schwerer zu entdecken.

Wer ist betroffen?

Alle PHP-Installationen, die Webrequests verarbeiten:

• PHP-FPM (typisch hinter Nginx oder Apache)
• Apache mit mod_php
• php-cgi (CGI/FastCGI-Setups)
• FrankenPHP
• LiteSpeed (LSAPI)

Apache mod_php wurde als kritischster Fall eingestuft, aus zwei Gründen: Der demonstrierte Exploit löst die Schwachstelle aus, bevor Anwendungscode läuft, und mod_php teilt sich den Prozessraum direkt mit dem Webserver.

Entscheidend: Die PHP Server Sicherheitslücke liegt im PHP-Core. WordPress, Joomla, Drupal, TYPO3, Magento, Shopware oder Dein eigenes Skript sind nicht die Ursache – aber jede Anwendung auf einer verwundbaren PHP-Runtime ist prinzipiell angreifbar, bis hin zu einem trivialen Skript, das nur eine Ausgabe erzeugt. Wiz Research demonstrierte unauthentifizierte RCE gegen die offiziellen WordPress-, Drupal- und Joomla-Containerimages.

Wie wurde PHP2Shell entdeckt?

Die Geschichte ist bemerkenswert, weil hier erstmals Frontier-KI-Modelle eine entscheidende Rolle in der koordinierten Disclosure einer Schwachstelle dieser Größenordnung spielten:

• Bereits 2024 fand ein PHP-Core-Entwickler bei der Arbeit an Findings aus dem ersten externen Sicherheitsaudit (OSTIF/Quarkslab, finanziert über die Sovereign Tech Agency) erste Anzeichen des OOM-Problems – ein konkreter Exploit-Pfad blieb damals aber theoretisch.
• Am 11. August 2026 meldete die Sicherheitsfirma Calif (Researcher Ryan A, bekannt als lcfr_hax, im Rahmen des „Patch the Planet”-Programms) eine unbedingte Remote Code Execution an das PHP-Projekt. OpenAI meldete unabhängig dieselbe Ursache; Wiz Research folgte am 24. August, OpenAI lieferte am 18. September weitere Angriffsvektoren.
• Die zugrunde liegenden Fehler steckten seit über einem Jahrzehnt im Code. Die Exploit-Kette galt als so komplex, dass sie am Rand dessen lag, was menschliche Forscher praktisch erreichen können – Frontier-Modelle haben diese Hürde gesenkt. Details dazu beschreibt OpenAI in seinem Beitrag zur koordinierten Veröffentlichung.
• Am 20. Oktober lekten die CVE-IDs vorzeitig – mit falschem CVSS-Wert 10,0 und falschem Release-Zeitpunkt. Ein versehentlich veröffentlichtes PoC-Video von Calif und ein Embargo-Bruch durch Chainguard beschleunigten die Veröffentlichung; PHP zog den Release um einen Tag vor.

Wird PHP2Shell bereits ausgenutzt?

Hier unterscheiden sich die Quellenaussagen leicht, daher mit Stand (22. Oktober 2026):

• AWS beobachtete Ausnutzungsversuche bereits ab dem 17. Oktober – vier Tage vor der öffentlichen Disclosure (Datadog Security Labs).
• Cloudflare sah Angriffstraffic gegen Kunden im Leak-Zeitfenster und mutierte Payloads, die die WAF-Regeln zu umgehen versuchten.
• Bitdefender und das kanadische Cyber Centre meldeten zum Berichtszeitpunkt keine bestätigte breite Ausnutzung, weisen aber darauf hin, dass sich das schnell ändern kann – ein funktionsfähiger PoC kursiert.

Bin ich von PHP2Shell betroffen? – der PHP2Shell Check

Bevor Du etwas änderst, solltest Du PHP2Shell prüfen – konkret: Finde heraus, welche PHP-Version Deine Website wirklich verwendet. Das ist nicht immer so einfach, wie es klingt.

Schritt 1: PHP Version prüfen (CLI)

Auf einem Server mit SSH-Zugang:

php -v

oder alternativ:

php -r 'echo PHP_VERSION, PHP_EOL;'

Die Ausgabe zeigt die Version der PHP-Kommandozeile, z. B. PHP 8.3.35 (cli). Liegt sie unter den Fix-Versionen (8.2.35, 8.3.36, 8.4.27, 8.5.12), ist Handlungsbedarf gegeben.

Schritt 2: Die tatsächlich verwendete Version ermitteln

Wichtig: Die CLI-Version muss nicht dieselbe sein, die Apache oder PHP-FPM für Deine Website verwendet. Auf einem Server können mehrere PHP-Versionen parallel installiert sein.

Für PHP-FPM prüfe zuerst, welche FPM-Dienste laufen:

systemctl list-units --type=service | grep -i fpm

Typische Dienste heißen php8.3-fpm, php8.4-fpm oder php-fpm. Die zugehörige Version bekommst Du über das Binary:

php-fpm8.4 -v

Welcher Pool zu welcher Website gehört, steht in der Pool-Konfiguration (Debian/Ubuntu: /etc/php/*/fpm/pool.d/) und in der Webserver-Konfiguration (bei Nginx der fastcgi_pass-Socket, bei Apache die proxy:fcgi:- bzw. SetHandler-Zeilen des Vhosts).

Für Apache mit mod_php:

apache2ctl -M | grep php    # Debian/Ubuntu
apachectl -M | grep php     # Fedora/RHEL

Zeigt die Ausgabe php8_module (bzw. php_module), läuft mod_php – das Paket heißt typischerweise libapache2-mod-php8.x:

dpkg -l | grep libapache2-mod-php   # Debian/Ubuntu
rpm -q php                          # Fedora/RHEL-artig

Schritt 3: Weitere Indizien – und ihre Grenzen

• HTTP-Header: Manche Server senden X-Powered-By: PHP/8.3.5. Das kannst Du mit curl -I https://deine-domain.de oder den Browser-DevTools sehen. Achtung: Der Header wird oft deaktiviert oder vom Webserver/Proxy übersteuert – sein Fehlen bedeutet nicht „sicher”, und sein Inhalt muss nicht zur CGI/FPM-Version passen. Er ist ein Hinweis, kein Beweis.
• phpinfo(): Eine Datei info.php mit <?php phpinfo(); im Webroot zeigt die exakte Version und Konfiguration. Aber: phpinfo() verrät Angreifern sehr viel über Dein System. Lege so eine Datei nur kurz zur Diagnose an und lösche sie sofort danach bzw. sperre den Zugriff – kein öffentliches phpinfo() als Dauerzustand.
• Docker: docker exec <container> php -v zeigt die Version im laufenden Container – die Version auf dem Host sagt nichts über das Image aus.

Achtung Backport-Falle

Linux-Distributionen portieren Sicherheitsfixes oft in ihre bestehenden Paketversionen zurück. Die von php -v ausgegebene Upstream-Versionsnummer kann also 8.3.10 anzeigen, obwohl das Paket bereits den PHP2Shell Patch enthält. Umgekehrt heißt eine unveränderte Hauptversion nicht automatisch „ungepatcht” – und eine neue Upstream-Nummer aus einem Fremd-Repository nicht automatisch „vollständig gepatcht”.

Prüfe deshalb zusätzlich das Paket-Changelog bzw. das Security Advisory Deines Distributors:

apt changelog php8.4-fpm        # Debian/Ubuntu
apt policy php8.4-fpm           # installierte vs. verfügbare Paketversion
rpm -q --changelog php | less   # Fedora/RHEL

Einschlägig sind z. B. Debian Security Advisories (DSA), Ubuntu Security Notices (USN) oder die Errata Deines Enterprise-Distributors.

PHP Sicherheitsupdate installieren: der PHP2Shell Fix

Es gibt keine vollständige Alternative zum PHP2Shell Update – so formuliert es das PHP-Projekt selbst („no complete mitigations, updating is the only safe choice”). Danach den Abschnitt für Dein Setup lesen und nicht vergessen: PHP-FPM bzw. den Webserver neu starten, sonst laufen alte Worker weiter. Kurzform zur PHP Sicherheitslücke – was tun: Version prüfen, Patch einspielen, Dienste neu starten, Logs auf Angriffsspuren lesen.

Debian / Ubuntu

sudo apt update
sudo apt upgrade

Prüfe anschließend die installierte Paketversion (apt policy php8.4-fpm, Name ggf. anpassen) und wirf einen Blick ins Changelog (siehe Backport-Hinweis oben). PHP-Pakete auf Debian/Ubuntu kommen oft aus dem Security-Repository oder – bei neueren Versionen – aus dem bekannten Sury-Repository (packages.sury.org), das die gepatchten Builds zeitnah bereitstellt.

Fedora / RHEL-artige Systeme

sudo dnf upgrade php\*
sudo dnf list php --showduplicates   # verfügbare Versionen prüfen

Auch hier gilt: Paketversion und Changelog (rpm -q --changelog php) gegen das Erratum des Distributors prüfen. Bei Remis Repo oder Modul-Streams die verwendete Quelle beachten.

PHP-FPM neu starten

Nach dem Update zwingend neu starten, sonst arbeiten die alten Worker-Prozesse weiter:

sudo systemctl restart php8.4-fpm   # Name an Deine Version anpassen

Danach verifizieren, dass der Dienst läuft und die neue Version nutzt:

systemctl status php8.4-fpm
php-fpm8.4 -v

Apache mod_php

Bei mod_php läuft PHP im Apache-Prozess – es hilft nichts, wenn Du PHP aktualisierst, aber Apache weiter mit der alten Bibliothek arbeitet:

sudo systemctl restart apache2   # Debian/Ubuntu
sudo systemctl restart httpd     # Fedora/RHEL

Danach die Webseite testen und die Logs prüfen (journalctl -u apache2, /var/log/apache2/error.log).

Managed Hosting (Plesk, cPanel, Hoster-Panel)

Bei Shared Hosting oder Managed Servern hast Du meist keinen Root-Zugriff – und musst ihn auch nicht haben:

1. Prüfen, welche PHP-Version pro Domain gesetzt ist (Plesk: „PHP-Einstellungen”, cPanel: „MultiPHP Manager”, bei vielen Hostern im Kundenpanel).
2. Auf eine gepatchte Version umstellen, falls verfügbar (8.2.35/8.3.36/8.4.27/8.5.12 oder neuer).
3. Hoster kontaktieren, wenn nur verwundbare Versionen angeboten werden – seriöse Anbieter patchen ihre Plattformen zentral und kommunizieren das; frag im Zweifel nach dem PHP2Shell-Status.
4. Bei WordPress zusätzlich im Backend: Werkzeuge → Website-Zustand → Bericht → Server zeigt die PHP-Version, die WordPress tatsächlich sieht.

PHP2Shell und Docker: Container, Images, Plattformen

IRC-Security.de

Cybersecurity Artikel und Tutorials

Docker ändert an der Kernfrage nichts: Entscheidend ist die PHP-Version im Image, nicht die auf dem Host. Container bringen aber zwei Stolperfallen mit: Eigene Images enthalten ihr eigenes PHP, und laufende Container aktualisieren sich nie von selbst.

Wie gefährdet bin ich mit Docker?

Kurz: genauso gefährdet wie ohne Docker, was die Erstlücke angeht. Ist das PHP im Image verwundbar, kann ein HTTP-Request den PHP-Worker im Container kompromittieren – das Netz ist ja gerade der Sinn des Containers.

Die Isolation hilft nur beim zweiten Schritt: Code läuft erstmal „nur” im Container, mit dem Container-User, den gemounteten Volumes und den Secrets in den Umgebungsvariablen. Das begrenzt den Schaden – aber ein Container mit Datenbankzugang, Upload-Verzeichnis und API-Keys ist für Angreifer immer noch sehr ergiebig. PHP2Shell ist auch im Container ein kritisches Ereignis, kein „halb so wild”.

Welche Images sind betroffen?

Alles, was PHP enthält. Typische Kandidaten:

• php:*-Basis-Images (php:8.3-fpm, php:8.4-apache, php:8.5-cli, …) und alles, was darauf aufbaut (FROM php:… in Deinem Dockerfile)
• Images mit gebündeltem PHP: wordpress:*, nextcloud:*, drupal:*, joomla:*, matomo:*, mediawiki:* u. v. m.
• FrankenPHP-Images (dunglas/frankenphp:*)
• Eigene Builds, inkl. Multi-Stage-Builds mit COPY --from=php…

PHP-Basen im Projekt finden:

grep -rnE '^\s*FROM\s+\S*(php|frankenphp)' . --include='Dockerfile*'
grep -rnE 'image:\s*\S*(php|wordpress|nextcloud|drupal|joomla|frankenphp)' . --include='*compose*.y*ml'

Was muss ich konkret tun?

1. Auf gepatchte Tags umstellen. Die offiziellen PHP-Images auf Docker Hub wurden bereits aktualisiert (Tags wie php:8.3.36-fpm-bookworm, php:8.4.27-apache, php:8.5.12-fpm-alpine; auch die Floating-Tags php:8.3, php:8.4 usw. zeigen auf die gefixten Builds). Im Dockerfile statt php:8.3-fpm idealerweise php:8.3.36-fpm-bookworm pinnen.
2. Eigene Images neu bauen – mit --pull. Ohne --pull kann der Build-Cache das alte, verwundbare Basis-Image wiederverwenden:

docker compose build --pull
docker compose up -d --force-recreate

3. Hub-Images ohne eigenen Build einfach neu ziehen und Container neu erstellen:

docker compose pull
docker compose up -d --force-recreate

4. Nicht nur den Webcontainer vergessen: Queue-Worker, Cron-Container, Scheduler – alles, was dasselbe PHP-Image nutzt.
5. Verifizieren im laufenden Container:

docker exec <containername> php -v

6. Digest-Pins beachten: Wer Images per @sha256:… pinnt, muss den Digest manuell auf den gepatchten Build heben – Pins holen keine Sicherheitsupdates automatisch.
7. Alte, verwundbare Images anschließend aufräumen, damit nichts versehentlich daraus startet.

Übernehmen die Anbieter das Update?

Teilweise – und genau hier entstehen die meisten falschen Annahmen:

• Docker Official Images und Docker Hardened Images wurden von Docker Inc. bereits auf die gepatchten PHP-Versionen aktualisiert. Das bedeutet aber nur: Das Image im Registry ist neu – Dein laufender Container bleibt auf dem alten Stand, bis Du ihn neu erstellst.
• App-Images (wordpress, nextcloud & Co.) werden von den jeweiligen Maintainer-Teams mit dem neuen PHP neu gebaut – Pull und Recreate liegen bei Dir.
• Managed Plattformen / PaaS patchen in der Regel ihre eigene Runtime zentral. Ob und wann das passiert, sagt Dir nur das Advisory bzw. die Statuspage des Anbieters – eigene Container-Images, die Du dort deployst, bleiben trotzdem Deine Baustelle.
• Auto-Updater (z. B. Watchtower) können Hub-Images neu ziehen und Container neu erstellen – sie können aber keine lokal gebauten Images reparieren. Für FROM php:…-Dockerfiles brauchst Du ein Rebuild, idealerweise automatisiert über CI oder Dependabot/Renovate.

Coolify konkret

Coolify ist ein Sonderfall, weil Coolify selbst in PHP (Laravel) geschrieben ist – die Plattform war also über alle v4-Linien verwundbar, unabhängig von den Apps, die Du damit deployst:

• Update ab v4.4: im Dashboard über Settings → Update → Check now → Update.
• Ältere v4-Linien: per SSH mit dem offiziellen Patch-Skript (curl -fsSL https://cdn.coollabs.io/coolify/patch.sh | sudo bash), das die passende Security-Release Deiner Linie installiert und nur den Coolify-Container neu erstellt.
• Coolify Cloud ist bereits gepatcht – hier ist nichts zu tun.
• Coolify hat vorsorglich 58 PHP-basierte Service-Templates deaktiviert, bis geprüft ist, welche Images den Fix enthalten.
• Wichtig: Das Coolify-Update patcht nur Coolify selbst. Deine deployten Applikations-Container bleiben verwundbar, bis Du sie neu baust/redeployst – in Coolify also pro Anwendung ein Redeploy mit frischem Build auslösen.

Details stehen in der offiziellen Coolify-Dokumentation und im verlinkten GitHub-Issue.

Dokploy, CapRover, Easypanel, Dokku, Portainer & Co.

Dasselbe Prinzip wie bei Coolify, zweigeteilt:

1. Das Tool selbst prüfen: Läuft die Plattform oder einer ihrer Core-Container auf PHP? Dann Advisory des Projekts lesen und Tool-Update einspielen.
2. Die darüber deployten Apps: bleiben Deine Aufgabe – Images neu bauen bzw. neu ziehen und die Anwendungen neu deployen.

Bei Kubernetes gilt entsprechend: Image mit gepatchtem PHP bauen, dann den Rollout neu starten (kubectl rollout restart), damit alle Pods die neue Version ziehen, und bei Bedarf den Digest der laufenden Pods verifizieren. Wer mehr Hintergrund zu Images, Containern und Docker Compose sucht, findet ihn im Artikel zu den Docker-Grundlagen.

Übergangsmaßnahmen, wenn Du nicht sofort patchen kannst

Sollte ein Update kurzfristig unmöglich sein, reduzieren laut den offiziellen Advisories folgende Maßnahmen die Angriffsfläche – sie schützen aber nicht vollständig und ersetzen das PHP Sicherheitsupdate nicht:

• memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können (z. B. php_admin_value im FPM-Pool oder der Apache-Konfiguration) – entfernt den kontrollierbaren OOM-Trigger, aber nicht jeden Pfad
• niedriges post_max_size (z. B. 8M ohne Upload-Bedarf), upload_max_filesize darunter halten
• session.upload_progress.enabled=0 – schließt den Upload-Progress-Pfad von CVE-2026-109619, nicht die ganze Lücke
• Request-Limits am Reverse-Proxy/Webserver (Body-Größe, Header- und Multipart-Anzahl)

PHP 7.x, 8.0 und 8.1: Was tun mit End-of-Life-Versionen?

Alte PHP-Versionen sind nicht „sicher, weil alt” – im Gegenteil: Die Schwachstellen reichen bis PHP 5.4 zurück, und PHP 8.1 und älter erhalten vom PHP-Projekt keine offiziellen Releases mehr.

Deine realistischen Optionen:

1. Distributions-/Vendor-Backports prüfen: Das PHP-Security-Team hat Source-Backports für 7.4, 8.0 und 8.1 bereitgestellt, und LTS-Anbieter (Debian mit LTS, Ubuntu mit Extended Security Maintenance, RHEL, spezialisierte PHP-LTS-Anbieter) bauen daraus Pakete. Entscheidend ist die Paketversion im Changelog, nicht die Upstream-Nummer.
2. Auf eine unterstützte Version migrieren (8.2+). Das ist die dauerhaft richtige Antwort: Wer PHP 7.x produktiv betreibt, fährt ohnehin ohne Sicherheitsupdates – PHP2Shell macht das nur besonders sichtbar.
3. Übergangsweise die Mitigationen oben anwenden – bewusst als Lückenbüßer, nicht als Lösung.

War mein Server bereits kompromittiert?

Ein erfolgreich installiertes PHP Update beweist nicht, dass vorher niemand reingekommen ist. Exploitation-Versuche gab es Berichten zufolge bereits vor der Veröffentlichung. Diese Checkliste ist defensiv und für eigene Systeme gedacht:

Im Webserver-/PHP-Log (access.log, error.log, FPM-Log, syslog/journald):

• ungewöhnliche oder ungewöhnlich große HTTP-POST-Requests, besonders mit multipart/form-data
• gehäufte PHP-Out-of-Memory-Fehler („Allowed memory size exhausted”) rund um die Request-Initialisierung
• auffällige Häufung von HTTP-500-Fehlern
• abstürzende oder ständig neu startende PHP-FPM- bzw. Apache-Worker (Segfaults, „child exited”)

Auf dem System:

• neue oder unerwartet veränderte PHP-Dateien im Webroot und in Upload-Verzeichnissen (wp-content/uploads & Co.) – PHP-Dateien in Upload-Ordnern sind fast immer ein Alarmzeichen
• Webshells: Dateien, die Request-Parameter an system, shell_exec, passthru, eval o. ä. weiterreichen
• unbekannte Cronjobs (crontab -l für alle Nutzer, /etc/cron.*) und unbekannte Benutzerkonten (/etc/passwd, last, auth.log)
• PHP-/Webserver-Prozesse, die unerwartet Shells, Interpreter (bash, python) oder Downloadprogramme (curl, wget) starten – sichtbar z. B. über Prozessliste, Audit-Logs oder EDR
• bei WordPress: ungewöhnliche Änderungen an Plugins, Themes, wp-config.php, neue Admin-Accounts

Wenn Du konkrete Funde hast: System isolieren (Netz trennen, nicht einfach löschen/neu installieren), Volatile Daten und Images sichern und forensisch untersuchen – selbst oder über einen Dienstleister. Ein nützlicher Einstieg in Gedankenwelt und Methodik ist der Artikel zu Linux-Penetrationstests und IT-Forensik auf IRC-Security.de; für das Update-Handwerk generell der Beitrag zu Patch-Management unter Linux.

Ist WordPress von PHP2Shell betroffen? (und Joomla, Drupal, TYPO3)

Ja und nein. Ob Du nach PHP2Shell WordPress, PHP2Shell Joomla, PHP2Shell Drupal oder TYPO3 suchst – die Antwort ist dieselbe und braucht eine Präzisierung:

• Das CMS ist nicht die Ursache. Die Lücke steckt im PHP-Core, nicht im WordPress-Core, nicht in Plugins, nicht im Theme.
• Aber: WordPress läuft auf PHP. Läuft Dein WordPress auf einer verwundbaren PHP-Version, ist die WordPress PHP Sicherheitslücke real – Wiz hat unauthentifizierte RCE gegen die offiziellen WordPress-, Drupal- und Joomla-Images demonstriert.
• Ein WordPress-Update hilft nicht. Core-, Theme- oder Plugin-Updates patchen die PHP-Runtime nicht. Nur das PHP Sicherheitsupdate (oder ein Distributions-Backport) schließt die Lücke.

So prüfst Du als WordPress-Betreiber die Version:

• Im Backend: Werkzeuge → Website-Zustand → Bericht → Server → PHP-Version
• Im Hosting-Panel des Anbieters (Plesk „PHP-Einstellungen”, cPanel „MultiPHP Manager” o. ä.)
• Beim Hoster-Support nachfragen, falls nur alte Versionen angeboten werden
• Wer WordPress im Docker-Image wordpress:* betreibt: PHP ist dort mit eingebaut → aktualisiertes Image ziehen und Container neu erstellen (siehe Docker-Abschnitt)

Die eher allgemeinen Angriffsmuster dahinter – etwa wie Schwachstellen in Webanwendungen eingestuft werden – behandelt der Artikel zu den OWASP Top 10; ein Vergleich mit klassischen Injections wie SQL-Injection zeigt, warum PHP2Shell eine andere Liga ist: Hier reicht die Anwendung nicht als Schutzschicht, weil der Angriff schon vor ihr zuschlägt.

Kann eine Firewall oder WAF PHP2Shell verhindern?

Eine Web Application Firewall kann helfen, ist aber kein Ersatz für das Update:

• Cloudflare hat PHP2Shell-Regeln für alle Kunden aktiviert (inkl. Free-Plan) und dafür erstmals „Full Transaction Detection” eingesetzt – Regeln, die Request und Response einer Transaktion gemeinsam auswerten, weil der Request allein nicht immer zwischen Exploit und legitimer Anfrage unterscheidet. Andere Anbieter (Azure WAF, Google Cloud Armor, AWS WAF, Imunify360, Sucuri u. a.) folgten mit eigenen Regeln.
• Requests an einer vorgelagerten Grenze (WAF, Reverse Proxy) blockieren den Angriff, bevor er den verwundbaren Parser erreicht – ein echter Schutzgewinn, solange die Regeln die Payload-Varianten abdecken.
• Aber: Exploits mutieren (Cloudflare beobachtete genau das), interne Angriffswege und Nicht-HTTP(S)-Pfade bleiben, und bei der Memory Disclosure gibt es nicht mal zwingend einen blockbaren Request-Shape.

Fazit: WAF ja – als zusätzliche Schicht (Defense in Depth), nicht als Fix. Wer Reverse Proxys und Gateways vertiefen will: API-Gateway-Grundlagen mit Kong und Nginx.

FAQ: PHP2Shell

Quellen und weiterführende Links

Offizielle Quellen und Advisories:

• PHP-Ankündigung der Sicherheitsreleases (php.net)
• GHSA-w8hw-w9fx-j79w – RCE via OOM corruption (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp – RCE via stale global state (CVE-2026-109619)
• The PHP Foundation: Today’s PHP Security Release
• php2shell.com – Übersichtsseite der Forscher

Behörden:

• BSI-Cybersicherheitswarnung: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit
• CERT-EU Advisory 2026-018: Critical Vulnerabilities in PHP
• NCSC (UK): Critical security issue affecting PHP
• Canadian Centre for Cyber Security: AL26-026
• NCSC-NL: Operative Informationen zum PHP2Shell-Vorfall (GitHub)

Research und Detection:

• Wiz Research: PHP2Shell – AI uncovers critical RCE vulnerabilities
• OpenAI: Patch the Planet – global response coordination
• Datadog Security Labs: PHP2Shell – detection, analysis, and remediation
• Cloudflare: Deploying protections against php2shell

Docker und Plattformen:

• Docker: Security Update on PHP2Shell – Impact for Docker Customers
• Coolify Docs: PHP Security Advisory 2026 (PHP2Shell)
• Coolify GitHub Issue #12266: Update Coolify now for PHP2Shell

Vertiefung auf IRC-Coding.de und IRC-Security.de:

• OWASP Top 10: Sicherheitsrisiken für Webanwendungen
• SQL Injection: Sicherheitsrisiko, Schutzmaßnahmen & Best Practices
• Docker Container: Grundlagen, Images, Dockerfile & Docker Compose
• Linux BASH Tutorial für Einsteiger
• Gängige Programmiersprachen im Überblick (inkl. PHP)
• IRC-Security.de: Linux Patch Management und automatische Updates
• IRC-Security.de: Kali Linux, Penetrationstests und IT-Forensik

Ähnlicher PHP2Shell-Artikel auf IRC-Mania.de:

• PHP2Shell: WordPress, Docker, Coolify und Homeserver – jetzt prüfen und absichern

PHP2Shell aus KI-Perspektive auf BotServ.de:

• Deutsch: PHP2Shell – Kritische PHP-Sicherheitslücke und die neue Rolle der KI
• English: PHP2Shell – Critical PHP Vulnerability and AI’s Role
• Español: PHP2Shell – Vulnerabilidad crítica y el rol de la IA
• Русский: PHP2Shell – критическая уязвимость PHP и роль ИИ

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert