Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Releases für zwei kritische Lücken veröffentlicht: CVE-2026-109618 und CVE-2026-109619, inzwischen bekannt als PHP2Shell. In Kombination erlauben sie es einem Angreifer, mit einer einzigen präparierten HTTP-Anfrage Code auf einem Server auszuführen. Dafür braucht er weder ein Login noch ein verwundbares Plugin oder eine Fehlkonfiguration. Wenn PHP auf Ihrem Server Web-Anfragen beantwortet, ist er angreifbar, bis er aktualisiert ist.
Angreifer haben die Lücke schon Tage vor dem Fix getestet, und die massenhafte Ausnutzung begann wenige Stunden nach dem Release. Sicherheitsforscher schätzen, dass 1,3 bis 1,9 Millionen aus dem Internet erreichbare Hosts betroffen waren. Diese Anleitung erklärt, worum es bei den Schwachstellen geht, welche Versionen gefixt sind, wie Sie einen eigenen Server Schritt für Schritt patchen und wie Sie prüfen, ob jemand schneller war als Sie.
Das Wichtigste
- PHP2Shell besteht aus zwei kritischen PHP-Fehlern (CVSS 9.2), die eine Remote-Code-Ausführung ohne Authentifizierung mit einer einzigen HTTP-Anfrage ermöglichen.
- Betroffen ist jede PHP-Version ab 5.4, sofern sie Web-Traffic verarbeitet: mod_php, PHP-FPM, CGI, FrankenPHP und LiteSpeed.
- Die gefixten Versionen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Starten Sie nach dem Update alle PHP-Worker neu.
- Alle cPanel- und Managed-WordPress-Server von WebGee sind bereits gepatcht; Kunden müssen nichts unternehmen.
- Die Ausnutzung begann schon vor dem Fix. Prüfen Sie daher auch nach dem Patchen Ihre Logs und Dateien auf Anzeichen einer Kompromittierung.
WebGee-Kunden: Sie sind bereits geschützt Unsere Techniker haben alle cPanel-Shared- und Reseller-Server sowie alle Server für Managed WordPress Hosting von WebGee auf die gefixten PHP-Builds aktualisiert und anschließend sämtliche PHP-Worker neu gestartet. Sie müssen nichts tun. Diese Anleitung richtet sich an Server, die Sie selbst verwalten, etwa einen VPS, einen Dedicated-Server oder einen Cloud-Server mit Root-Zugriff.
Was ist PHP2Shell?
PHP2Shell bezeichnet zwei Speichersicherheitsfehler in der zentralen Request-Verarbeitung von PHP. Beide stecken in Code, der ausgeführt wird, bevor Ihre Anwendung (WordPress, Laravel, Magento oder etwas anderes) die Anfrage überhaupt zu sehen bekommt. Deshalb schützt es Sie hier nicht, Ihr CMS und Ihre Plugins aktuell zu halten.
CVE-2026-109618: Speicherbeschädigung bei Speichermangel während des Request-Parsings
Wenn PHP einen multipart/form-data-Body verarbeitet (das Format für Formulare und Datei-Uploads) und dabei mittendrin der Speicher ausgeht, bleiben interne Strukturen nur halb initialisiert. Der Aufräumcode von PHP behandelt diesen defekten Zustand anschließend als gültig. Eine präparierte Anfrage kann diese Situation selbst auf Servern mit normalen Speicherlimits herbeiführen.
CVE-2026-109619: veralteter globaler Zustand und Use-after-free
PHP behandelt fatale Fehler mit longjmp(), das aus dem fehlerhaften Code herausspringt, ohne ihn ordentlich abzuwickeln. Nach dem oben beschriebenen Speicherfehler kann globaler, an die Anfrage gebundener Zustand auf Speicher verweisen, der bereits freigegeben wurde. Die nächste Anfrage, die derselbe PHP-Worker bearbeitet, kann diesen Speicher dann verwenden. Forscher haben sowohl das Auslesen von Speicherinhalten als auch eine vollständige Remote-Code-Ausführung bestätigt.
Zusammen machen die beiden Fehler aus einer einzigen fehlerhaften POST-Anfrage eine Shell, die unter dem Benutzer Ihres Webservers läuft (www-data, apache oder nobody). Von dort aus kann ein Angreifer Ihre wp-config.php und Ihre Datenbank-Zugangsdaten auslesen, Hintertüren einschleusen, Spam versenden oder tiefer in Ihr Netzwerk vordringen.
Wie gefährlich ist die Lücke?
- Schweregrad: Beide CVEs sind mit CVSS v4.0 9.2 (Kritisch) bewertet. In frühen Sicherheitshinweisen kursierte eine Bewertung von 10.0.
- Authentifizierung: nicht erforderlich. Die Lücke ist über jede URL erreichbar, die PHP verarbeitet.
- Ausnutzung: in freier Wildbahn bestätigt; öffentlicher Proof-of-Concept-Code ist im Umlauf.
- Anwendungen: Code-Ausführung vor der Authentifizierung wurde bei WordPress, Drupal, Joomla und Magento demonstriert.
- Alter: Der verwundbare Codepfad reicht bis PHP 5.4.0 zurück, sodass auch sehr alte Server betroffen sind.
Wer ist betroffen?
Jede PHP-Installation, die Web-Traffic verarbeitet, unabhängig von der verwendeten Server-API:
- Apache mit mod_php: das höchste Risiko, weil das verwundbare Parsing direkt im Apache-Worker läuft.
- PHP-FPM hinter nginx, Apache oder Caddy.
- php-cgi, FrankenPHP und LiteSpeed (LSAPI).
Reines Kommandozeilen-PHP (Cronjobs, Worker, die nie HTTP-Bodys verarbeiten) ist nicht direkt erreichbar, aber in der Regel ist dasselbe Binary auch für das Web installiert. Aktualisieren Sie alles.
Gefixte PHP-Versionen
Aktualisieren Sie mindestens auf das folgende Release Ihres Zweigs:
- PHP 8.5: 8.5.12 oder neuer
- PHP 8.4: 8.4.27 oder neuer
- PHP 8.3: 8.3.36 oder neuer
- PHP 8.2: 8.2.35 oder neuer
- PHP 7.4 bis 8.1: kein offizielles Release. Fixes gibt es nur als Backports im Quellcode und über Anbieter wie CloudLinux (alt-php) sowie einige Linux-Distributionen.
- PHP 5.4 bis 7.3: End of Life, kein Fix verfügbar. Führen Sie ein Upgrade durch oder nehmen Sie die Website vom öffentlichen Internet.
Schritt 1: Prüfen Sie, welche PHP-Version auf Ihrem Server läuft
Prüfen Sie sowohl das Kommandozeilen-Binary als auch die Version, die Ihr Webserver tatsächlich verwendet. Die beiden unterscheiden sich häufig.
# Command-line PHP
php -v
# Every PHP binary installed on the server
ls /usr/bin/php* /usr/sbin/php-fpm* /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php 2>/dev/null
# The version your web server serves: drop a temporary file, fetch it, then delete it
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/v.php >/dev/null
curl -s https://your-domain.com/v.php; echo
sudo rm /var/www/html/v.phpLassen Sie keine phpinfo()-Dateien liegen Wenn Sie zur Prüfung eine phpinfo()- oder Versionsdatei verwenden, löschen Sie sie unmittelbar danach. Angreifer suchen gezielt nach solchen Dateien, um verwundbare Server zu identifizieren.
Schritt 2: PHP auf Ihrem Server patchen
Wählen Sie den Abschnitt für Ihre Plattform. Nach dem Update müssen Sie jeden PHP-Prozess neu starten. Alte Worker führen den verwundbaren Code weiter aus, bis sie ersetzt werden.
Ubuntu und Debian
sudo apt update
sudo apt install --only-upgrade 'php*-common' 'php*-cli' 'php*-fpm' 'libapache2-mod-php*'
# Restart PHP-FPM (repeat for each installed version)
sudo systemctl restart php8.3-fpm
# Using mod_php? Restart Apache instead
sudo systemctl restart apache2
# Confirm
php -vWenn Sie PHP aus dem PPA ondrej/php oder einem ähnlichen Drittanbieter-Repository installieren, vergewissern Sie sich, dass dieses Repository die gefixten Builds bereits veröffentlicht hat, bevor Sie davon ausgehen, gepatcht zu sein.
AlmaLinux, Rocky Linux und RHEL
sudo dnf clean all
sudo dnf upgrade 'php*'
# Restart PHP-FPM and the web server
sudo systemctl restart php-fpm
sudo systemctl restart httpd # or nginx
php -vcPanel- und WHM-Server (EasyApache ea-php)
cPanel liefert PHP als ea-php-Pakete aus. Aktualisieren Sie alle auf einmal:
# CloudLinux / CentOS 7
yum clean all && yum update "ea-php*"
# AlmaLinux / CloudLinux 8, 9 and 10
dnf clean all && dnf upgrade "ea-php*"
# Restart PHP-FPM for all accounts, then Apache or LiteSpeed
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd
# Check each installed version
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo -n "$p: "; $p -r 'echo PHP_VERSION, PHP_EOL;'; doneCloudLinux alt-php (PHP Selector)
CloudLinux portiert den Fix in jeden alt-php-Zweig zurück, auch in End-of-Life-Versionen wie 5.6 und 7.4. Die Versionsnummer ändert sich dabei nicht. Prüfen Sie daher das Changelog des Pakets statt php -v:
yum clean all && yum update 'alt-php*' 'ea-php*' -y
# Confirm the fix is in the installed package (example: alt-php 7.4)
rpm -q --changelog alt-php74 | grep -m1 -i 'CVE-2026-109618'Docker und Container
Container aktualisieren sich nicht von selbst. Laden Sie das gepatchte offizielle Image herunter, bauen Sie neu und deployen Sie erneut:
# Pin to a fixed release (or newer)
FROM php:8.3.36-fpm
# ...your existing build stepsdocker pull php:8.3.36-fpm
docker compose build --pull
docker compose up -d
# Confirm inside the running container
docker compose exec app php -vSchritt 3: Übergangsmaßnahmen, falls Sie heute nicht patchen können
Diese Einstellungen verringern die Angriffsfläche, beheben die Lücke aber nicht. Nutzen Sie sie nur, um Zeit zu gewinnen, bis das Upgrade erfolgt, zum Beispiel unter PHP 7.3 oder älter, wo es keinen Fix gibt.
php.ini härten
Der Exploit setzt voraus, dass während des Parsings das PHP-eigene Speicherlimit erreicht wird. Wenn Sie dieses Limit auf PHP-Ebene deaktivieren (und an anderer Stelle eine harte Grenze erzwingen, siehe unten), schließen Sie den wichtigsten Auslöser. Auch die Fortschrittsverfolgung für Uploads ist ein Weg in den verwundbaren Code.
; /etc/php/8.3/fpm/conf.d/99-php2shell.ini (adjust the path to your version)
; Interim mitigation for CVE-2026-109618 / CVE-2026-109619
memory_limit = -1
session.upload_progress.enabled = 0
post_max_size = 1M
; PHP 8.5 only
fatal_error_backtraces = 0Anwendungen wie WordPress erhöhen memory_limit zur Laufzeit selbst. Fixieren Sie die Werte im PHP-FPM-Pool, damit Code sie nicht überschreiben kann:
; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_flag[session.upload_progress.enabled] = offKombinieren Sie memory_limit = -1 immer mit einer harten Grenze Ohne PHP-Speicherlimit kann ein einziges außer Kontrolle geratenes Skript den gesamten Arbeitsspeicher des Servers belegen. Begrenzen Sie den Speicher stattdessen auf Prozessebene, mit MemoryMax von systemd für den PHP-FPM-Dienst oder einem Speicherlimit für den Container, sodass der Kernel einen ausufernden Worker stoppt statt PHP.
# Cap PHP-FPM memory with systemd
sudo systemctl edit php8.3-fpm
# [Service]
# MemoryMax=2G
# Or, for Docker:
docker update --memory 2g --memory-swap 2g <container>Größe des Request-Bodys am Webserver begrenzen
Weisen Sie übergroße Bodys ab, bevor PHP sie überhaupt zu sehen bekommt. Das blockiert die großen präparierten Payloads aus öffentlichen Exploits, allerdings auch legitime große Uploads. Heben Sie das Limit daher nur für die Pfade an, die es benötigen.
# nginx: inside http {} or server {}
client_max_body_size 1m;
# Allow bigger uploads only where needed, e.g. the WordPress media uploader
location = /wp-admin/async-upload.php {
client_max_body_size 64m;
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}# Apache: in the vhost or .htaccess (bytes)
LimitRequestBody 1048576Starten Sie anschließend alle PHP-Worker neu, damit keiner mehr beschädigten Zustand im Speicher hält:
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx # or: sudo systemctl restart apache2Wenn Ihre Website hinter Cloudflare liegt, aktivieren Sie die verwalteten WAF-Regeln für diese Schwachstelle; Cloudflare stellt den Schutz auch im kostenlosen Tarif bereit. Betrachten Sie eine WAF jedoch als zusätzliche Schutzschicht, nicht als Ersatz für das Patchen. CERT-EU empfiehlt außerdem, aus dem Internet erreichbare PHP-Anwendungen zu isolieren, die sich nicht sofort patchen lassen.
Schritt 4: Prüfen, ob Sie bereits kompromittiert wurden
Die Ausnutzung begann, bevor die meisten patchen konnten. Mit dem Update ist die Arbeit also noch nicht erledigt. Achten Sie auf die folgenden Anzeichen.
Speicherfehler in Zeile 0
Fehlgeschlagene wie erfolgreiche Versuche hinterlassen einen fatalen Speicherfehler ohne echte Datei oder Zeile, meist neben einer ungewöhnlich großen POST-Anfrage:
sudo grep -R "Allowed memory size of .* exhausted .* in Unknown on line 0" \
/var/log/php*-fpm.log /var/log/apache2/error.log /var/log/httpd/error_log \
/var/log/nginx/error.log 2>/dev/null | tail -n 50Abstürze von Workern
# Apache children dying with segfaults
sudo grep -R "AH00052: child pid .* exit signal Segmentation fault" /var/log/apache2/ /var/log/httpd/ 2>/dev/null
# PHP-FPM workers killed by signals
sudo grep -R "exited on signal" /var/log/php*-fpm.log 2>/dev/nullVom Webserver-Benutzer gestartete Shells
# A shell running under apache, www-data or php-fpm is a red flag
ps aux | grep -E "(apache|www-data|php-fpm|nobody)" | grep -E "\b(sh|bash|dash)\b" | grep -v grep
# Unexpected outbound connections from the web user
sudo ss -tunp | grep -E "php|apache|httpd|nginx"Hintertüren und Persistenz
# PHP files changed in the last 7 days
sudo find /var/www -type f -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -n 50
# PHP files in upload folders (they should never be there)
sudo find /var/www -path "*uploads*" -name "*.php"
# Cron jobs added for the web user
sudo crontab -u www-data -l 2>/dev/null; sudo crontab -u apache -l 2>/dev/nullSuchen Sie in Ihren Access-Logs nach POST-Anfragen mit riesigen Formularfeldnamen (über 1 MB), Binär- oder Null-Bytes im Body oder einer Struktur wie =[binary]&a=1&[long field][x]=1.
Ein erfolgreicher Exploit führt nicht immer zu einem Absturz. Ein sauberes Log beweist also nicht, dass Sie sicher sind. Wenn Sie eines dieser Anzeichen finden, gehen Sie von einer Kompromittierung aus:
- Nehmen Sie die Website offline oder schalten Sie den Wartungsmodus ein.
- Erneuern Sie Datenbank-Passwörter, API-Schlüssel und WordPress-Salts.
- Spielen Sie ein Backup ein, das vor dem 17. Oktober 2026 erstellt wurde.
- Patchen Sie, bevor Sie die Website wieder online nehmen.
Checkliste für die Reaktion auf PHP2Shell
- Alle PHP-Versionen auf dem Server ermitteln, CLI und Web
- Auf 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder einen Backport des Anbieters aktualisieren
- PHP-FPM, Apache oder LiteSpeed neu starten, damit keine alten Worker übrig bleiben
- Container aus gepatchten Images neu bauen und deployen
- Vorläufige php.ini-Einstellungen und Body-Größenlimits auf allem anwenden, was sich noch nicht patchen lässt
- Logs nach Speicherfehlern in Zeile 0 und Segfaults durchsuchen
- Nach Shells des Webbenutzers, neuen PHP-Dateien und neuen Cronjobs suchen
- Zugangsdaten erneuern, falls etwas verdächtig wirkt
Warum so etwas immer wieder passiert und wie Managed Hosting hilft
PHP2Shell ging in weniger als einer Woche vom ersten Honeypot-Treffer zur massenhaften Ausnutzung über, und das meiste davon geschah, bevor es überhaupt einen Fix gab. Für ein Unternehmen mit eigenem Server bedeutet die Abwehr, dass jemand rund um die Uhr Sicherheitsmeldungen verfolgt, Updates testet und sie sofort nach Erscheinen auf jede PHP-Version und jeden Worker ausrollt. Oft muss das um 2 Uhr nachts oder am Wochenende geschehen, während öffentliche Exploits bereits eingesetzt werden.
Genau das übernimmt unser Team für WebGee-Kunden. Bei PHP2Shell haben unsere Techniker:
- die gefixten PHP-Builds auf allen cPanel-Shared- und Reseller-Servern eingespielt;
- alle Server für Managed WordPress Hosting auf das neueste gepatchte PHP aktualisiert;
- jeden PHP-Worker neu gestartet, damit kein verwundbarer Prozess weiterläuft;
- all das erledigt, ohne dass Kunden etwas tun mussten.
Zusätzlich zum Patchen umfasst das Hosting von WebGee Malware-Scans auf Serverebene, eine Web Application Firewall und tägliche Backups. Sollte ein Angriff doch einmal irgendwo durchkommen, haben Sie einen sauberen Wiederherstellungspunkt.
Wenn Sie WordPress, WooCommerce oder eine andere PHP-Anwendung auf einem Server betreiben, den Sie selbst patchen müssen, überlegen Sie, uns diese Aufgabe zu überlassen. Wir ziehen Ihre Website kostenlos und ohne Ausfallzeit um.
Sie möchten lieber Ihren eigenen Server behalten?
Wenn Sie Root-Zugriff benötigen, bietet Ihnen ein Cloud-Server von WebGee volle Kontrolle, und unsere Support-Techniker helfen Ihnen beim Patchen, Härten und Überwachen. Für Websites, die einfach schnell und sicher bleiben sollen, halten Managed WordPress Hosting und cPanel-Cloud-Hosting PHP für Sie aktuell. Sie sind unsicher, was am besten passt? Sprechen Sie mit unserem Team.
Häufige Fragen
Meine Website wird bei WebGee gehostet. Muss ich etwas tun?
Nein. Wir haben alle cPanel-Shared- und Reseller-Server sowie alle Server für Managed WordPress Hosting von WebGee auf die gefixten PHP-Builds aktualisiert und jeden PHP-Worker neu gestartet. Wenn Sie einen eigenen Cloud- oder Dedicated-Server mit Root-Zugriff betreiben, folgen Sie den Schritten in dieser Anleitung oder wenden Sie sich an unser Support-Team.
Behebt ein Update von WordPress oder meinen Plugins PHP2Shell?
Nein. Die Schwachstellen liegen in PHP selbst und werden ausgelöst, bevor WordPress oder anderer Anwendungscode ausgeführt wird. Sie müssen die PHP-Pakete auf dem Server aktualisieren und PHP neu starten.
Welche PHP-Versionen beheben CVE-2026-109618 und CVE-2026-109619?
PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 sowie alle neueren Releases. Für PHP 7.4 bis 8.1 gibt es nur Backports im Quellcode und Hersteller-Builds wie CloudLinux alt-php. Für PHP 5.4 bis 7.3 gibt es keinen Fix.
Ich nutze eine alte PHP-Version, für die es keinen Fix gibt. Was soll ich tun?
Wechseln Sie so schnell wie möglich auf einen unterstützten PHP-Zweig. Bis dahin sollten Sie die vorläufigen php.ini-Einstellungen und Größenlimits für Anfragen aus dieser Anleitung anwenden, die Website hinter eine WAF stellen oder sie vom öffentlichen Internet trennen. CloudLinux alt-php enthält außerdem zurückportierte Fixes für viele End-of-Life-Versionen.
Reicht eine Web Application Firewall aus?
Nein. Eine WAF kann bekannte Exploit-Muster blockieren und verschafft Ihnen Zeit, aber Angreifer passen ihre Payloads an. Die einzige echte Lösung ist, PHP zu patchen.
Wie erkenne ich, ob mein Server gehackt wurde?
Achten Sie auf Fehlermeldungen wie „Allowed memory size ... in Unknown on line 0“, abstürzende Worker (Segfaults), Shells, die unter dem Benutzer des Webservers laufen, kürzlich geänderte PHP-Dateien, PHP-Dateien in Upload-Ordnern und neue Cronjobs. Ein erfolgreicher Angriff hinterlässt unter Umständen keinen Absturz. Im Zweifel sollten Sie daher Zugangsdaten erneuern und ein Backup einspielen, das vor dem 17. Oktober 2026 erstellt wurde.
