PHP2Shell: Kritische PHP-Lücken – welche Version jetzt laufen muss und wie Sie eine Kompromittierung prüfen

Vermutlich haben Sie es in den letzten Tagen schon in den Medien gelesen: Unter dem Namen „PHP2Shell“ sind zwei kritische Sicherheitslücken in PHP bekannt geworden, CVE-2026-109618 und CVE-2026-109619. Beide sind mit CVSS 9.2 bewertet und erlauben es Angreifern, ohne Anmeldung eigenen Code auf dem Webserver auszuführen. Das PHP-Projekt hat am 21. Oktober 2026 außerplanmäßige Updates veröffentlicht.

Das Problem: Die Lücken wurden schon am 20. Oktober vorzeitig öffentlich, und erste Angriffsversuche wurden bereits am Morgen des 21. Oktober beobachtet, also noch bevor die Updates verfügbar waren. Nur zu patchen reicht deshalb nicht. Wer einen öffentlich erreichbaren PHP-Server betreibt, sollte auch prüfen, ob in der Zwischenzeit jemand eingedrungen ist.

Wer ist betroffen?

Laut PHP-Projekt alle PHP-Installationen, die Webanfragen bearbeiten: PHP-FPM (z. B. hinter Nginx), Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am kritischsten ist Apache mit mod_php. Dort wurde ein Angriff demonstriert, der greift, bevor überhaupt Code der Anwendung läuft.

Damit sind praktisch alle typischen PHP-Anwendungen betroffen, etwa WordPress, Joomla, Shopware, Nextcloud, Kontaktformulare oder selbst geschriebene Seiten. Nicht betroffen ist PHP, das nur auf der Kommandozeile läuft und keine Webanfragen annimmt.

Webhosting-Kunden (z. B. bei Strato, IONOS oder All-Inkl): Hier ist der Hoster für die Server-Updates zuständig. Prüfen Sie die Statusmeldungen Ihres Anbieters oder lassen Sie sich das Update schriftlich bestätigen. Ihre eigene Anwendung (z. B. WordPress samt Plugins) sollten Sie trotzdem aktuell halten.

Diese Versionen sollten jetzt laufen

Offizielle PHP-Versionen mit Fix:

• PHP 8.5: 8.5.12
• PHP 8.4: 8.4.27
• PHP 8.3: 8.3.36
• PHP 8.2: 8.2.35 (Achtung: PHP 8.2 bekommt nur noch bis 31.12.2026 Sicherheitsupdates)

Linux-Distributionen spielen den Fix in ihre eigenen Pakete ein. Die angezeigte PHP-Version ändert sich dabei teilweise nicht. Entscheidend ist dann die Paketversion:

• Ubuntu 26.04 LTS: php8.5 8.5.4-0ubuntu1.5 oder neuer
• Ubuntu 24.04 LTS: php8.3 8.3.6-0ubuntu0.24.04.13 oder neuer (zeigt weiterhin „8.3.6“ an)
• Ubuntu 22.04 LTS: php8.1 8.1.2-1ubuntu2.28 oder neuer
• Debian 13 (trixie): php8.4 8.4.27-1~deb13u1 oder neuer
• Debian 12 (bookworm): php8.2 8.2.35-1~deb12u1 oder neuer

PHP 8.1 und älter (also auch 7.x und 5.x) bekommt vom PHP-Projekt keine offiziellen Updates mehr. Es gibt nur Rückportierungen von Distributionen und LTS-Anbietern. Läuft bei Ihnen eine solche Version ohne Hersteller-Support, ist jetzt der richtige Zeitpunkt für ein Upgrade.

Schritt-für-Schritt: Patch prüfen und Server auf Einbruch untersuchen

Die folgende Anleitung führt Sie in acht Schritten durch die Prüfung. Alle Befehle lesen nur und verändern nichts, außer in Schritt 2, wo das Update eingespielt wird. Unter jedem Schritt finden Sie aufklappbare Bereiche für die gängigen Linux-Distributionen. Öffnen Sie einfach den Bereich, der zu Ihrem Server passt.

Welche Distribution läuft bei Ihnen? Das verrät dieser Befehl:

cat /etc/os-release

Typische Fallstricke vorab: php -v prüft nur das Kommandozeilen-PHP, nicht das PHP des Webservers. Ubuntu und Debian zeigen nach dem Fix teilweise dieselbe Versionsnummer wie vorher. Und ohne Neustart der PHP-Dienste bleibt der alte, verwundbare Code im Speicher aktiv.

Schritt 1: Vorbereitung

Melden Sie sich als root an (oder stellen Sie sudo voran) und legen Sie den Prüfzeitraum fest. Alle weiteren Befehle nutzen diese Variable. Mit script wird zusätzlich alles in eine Datei mitgeschrieben, die Sie später weitergeben oder archivieren können.

script -a /root/php2shell-pruefung-$(date +%F).log
SEIT="2026-10-20"

Nach der Prüfung beenden Sie die Aufzeichnung mit exit.

Schritt 2: Update einspielen und Patch nachweisen

Am sichersten ist der Nachweis über das Änderungsprotokoll (Changelog) des Pakets: Dort müssen beide CVE-Nummern auftauchen. Das funktioniert unabhängig davon, welche Versionsnummer angezeigt wird.

apt update && apt upgrade
apt list --upgradable 2>/dev/null | grep -i php
dpkg -l | grep -E 'php[0-9.]+-(fpm|cgi|cli)|libapache2-mod-php'
zgrep -h -E 'CVE-2026-10961[89]' /usr/share/doc/php*/changelog.Debian.gz | sort -u

dnf upgrade --refresh 'php*'
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
rpm -qa 'php*' | sort
rpm -q --changelog php-fpm php-cli php-common 2>/dev/null | grep -E 'CVE-2026-10961[89]' | sort -u

zypper refresh
zypper list-patches --cve=CVE-2026-109618,CVE-2026-109619
zypper patch --cve=CVE-2026-109618,CVE-2026-109619
rpm -qa 'php*' | sort
rpm -q --changelog php8 php8-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]' | sort -u

apk update && apk upgrade
apk info -v 2>/dev/null | grep -E '^php[0-9]+-'

docker ps --format '{{.Names}}\t{{.Image}}\t{{.CreatedAt}}'
docker exec <container> php -v
docker compose pull && docker compose up -d --force-recreate
docker compose ps

Schritt 3: PHP-Dienste neu starten und Neustart nachweisen

Erst nach dem Neustart arbeitet der Server mit dem gepatchten Code. Prüfen Sie anschließend, dass die PHP-Prozesse nach dem Update gestartet wurden.

systemctl list-units --type=service | grep -E 'php.*fpm|apache2|nginx'
systemctl restart php8.3-fpm
systemctl restart apache2
ps -eo pid,lstart,user,cmd | grep -E '[p]hp-fpm|[a]pache2'

systemctl restart php-fpm
systemctl restart httpd
ps -eo pid,lstart,user,cmd | grep -E '[p]hp-fpm|[h]ttpd'

systemctl restart php-fpm
systemctl restart apache2
ps -eo pid,lstart,user,cmd | grep -E '[p]hp-fpm|[h]ttpd'

rc-service php-fpm83 restart
rc-service nginx restart
ps -o pid,user,args | grep -E '[p]hp-fpm'

Schritt 4: Logs auf Abstürze und Auffälligkeiten prüfen

Beide Lücken hängen mit Speicherfehlern zusammen. Abgestürzte PHP-Worker (Segfaults) sind ein typischer Hinweis auf Angriffsversuche. Ein einzelner Absturz bedeutet nicht automatisch einen Einbruch, eine Häufung ab dem 20. Oktober sollte aber genauer untersucht werden.

grep -iE 'SIGSEGV|signal 11|exited on signal' /var/log/php*-fpm.log*
grep -iE 'segfault|exit signal' /var/log/apache2/error.log*
journalctl --since "$SEIT" | grep -iE 'php.*(segfault|SIGSEGV)'

grep -iE 'SIGSEGV|signal 11|exited on signal' /var/log/php-fpm/*.log*
grep -iE 'segfault|exit signal' /var/log/httpd/error_log*
journalctl --since "$SEIT" | grep -iE 'php.*(segfault|SIGSEGV)'

grep -iE 'SIGSEGV|signal 11|exited on signal' /var/log/php-fpm.log*
grep -iE 'segfault|exit signal' /var/log/apache2/error_log*
journalctl --since "$SEIT" | grep -iE 'php.*(segfault|SIGSEGV)'

grep -iE 'SIGSEGV|signal 11|exited on signal' /var/log/php*/error.log*
dmesg | grep -i segfault

docker logs --since "$SEIT" <container> 2>&1 | grep -iE 'SIGSEGV|signal 11|segfault|exited on signal'

Werfen Sie zusätzlich einen Blick in die Zugriffslogs des Webservers (Debian/Ubuntu/SUSE: /var/log/apache2/ bzw. /var/log/nginx/, RHEL: /var/log/httpd/ bzw. /var/log/nginx/). Diese Auswertung zeigt, welche Adressen am häufigsten per POST aufgerufen wurden und welche Anfragen Serverfehler ausgelöst haben:

zgrep -h '"POST ' /var/log/nginx/access.log* | awk '{print $7, $9}' | sort | uniq -c | sort -rn | head -30
zgrep -h '" 50[0-9] ' /var/log/nginx/access.log* | awk '{print $4, $1, $7}' | tail -50

Den Pfad bitte an Ihren Webserver anpassen. Auffällig sind POST-Anfragen an PHP-Dateien, die zu Ihrer Anwendung gar nicht gehören, und gehäufte 502/503-Fehler, weil abstürzende Worker sich so bemerkbar machen.

Schritt 5: Neue oder veränderte Dateien suchen

Nach einem erfolgreichen Angriff wird häufig eine Webshell abgelegt, eine kleine PHP-Datei, über die der Angreifer den Server fernsteuert. Suchen Sie nach PHP-Dateien, die seit dem Stichtag neu sind oder verändert wurden, und nach Dateien in temporären Ordnern.

find /var/www -type f -name '*.php*' -newermt "$SEIT" -ls
find /tmp /var/tmp /dev/shm -newermt "$SEIT" -ls

find /var/www /usr/share/nginx -type f -name '*.php*' -newermt "$SEIT" -ls
find /tmp /var/tmp /dev/shm -newermt "$SEIT" -ls

find /srv/www -type f -name '*.php*' -newermt "$SEIT" -ls
find /tmp /var/tmp /dev/shm -newermt "$SEIT" -ls

docker diff <container>

Zusätzlich lohnt sich die Suche nach typischen Webshell-Mustern im Webroot. Treffer sind nicht automatisch bösartig, manche Plugins nutzen diese Funktionen legitim, sie sollten aber angesehen werden:

grep -rlE 'eval\(base64_decode|eval\(gzinflate|assert\(\$_(POST|GET|REQUEST)|system\(\$_(POST|GET|REQUEST)' /var/www

Geänderte Dateien finden Sie auch außerhalb des Webroots, etwa neue SSH-Schlüssel, Cronjobs oder Systemdienste:

find / -xdev -name authorized_keys -newermt "$SEIT" -ls 2>/dev/null
find /etc/cron* /var/spool/cron* /etc/systemd/system -newermt "$SEIT" -ls 2>/dev/null

Schritt 6: Prozesse, Cronjobs und Verbindungen des Web-Benutzers

PHP läuft unter einem eigenen Benutzer. Unter diesem Benutzer dürfen nur PHP- bzw. Webserver-Prozesse laufen, keine Shells (sh, bash), kein curl, wget, python, perl oder nc.

WEBUSER=www-data
ps -u "$WEBUSER" -f
crontab -u "$WEBUSER" -l
find / -xdev -user "$WEBUSER" -newermt "$SEIT" 2>/dev/null | grep -vE '/cache/|/sessions?/|/uploads/'
ss -tnp | grep -v ':22 '

WEBUSER bitte passend zu Ihrer Distribution setzen. Bei ss achten Sie auf ausgehende Verbindungen von PHP- oder Webserver-Prozessen zu unbekannten Adressen, besonders auf ungewöhnliche Ports.

Schritt 7: Die Anwendung prüfen

Viele Angriffe zielen am Ende auf die Anwendung: zusätzliche Administratoren, eingeschleuste Plugins oder Weiterleitungen auf fremde Seiten. Prüfen Sie im Backend Ihres CMS oder Shops die Benutzerliste, installierte Erweiterungen und die .htaccess-Dateien.

cd /var/www/IHRE-SEITE
wp user list --role=administrator --allow-root
wp core verify-checksums --allow-root
wp plugin verify-checksums --all --allow-root
find . -name '.htaccess' -newermt "$SEIT" -ls

Schritt 8: Ergebnis bewerten

Unauffällig ist Ihr Server, wenn alle folgenden Punkte zutreffen:

• Beide CVE-Nummern stehen im Changelog bzw. die Version ist aktuell, und die PHP-Prozesse wurden nach dem Update neu gestartet
• Keine Häufung von Abstürzen in den Logs
• Nur erwartete Dateiänderungen, z. B. Caches oder Uploads Ihrer Nutzer
• Unter dem Web-Benutzer laufen nur PHP- bzw. Webserver-Prozesse, ohne Crontab und ohne unbekannte ausgehende Verbindungen
• Keine fremden Administratoren, Plugins oder Weiterleitungen

Gibt es auch nur einen Punkt, den Sie sich nicht erklären können, behandeln Sie den Server als möglicherweise kompromittiert und gehen Sie wie im nächsten Abschnitt beschrieben vor.

Und wenn etwas auffällt?

• Server vom Netz nehmen, aber nicht sofort löschen. Logs und Zustand sichern, damit sich nachvollziehen lässt, was passiert ist.
• Einen kompromittierten Server nicht „reparieren“, sondern aus einem sauberen Backup von vor dem 20. Oktober oder komplett neu aufsetzen.
• Alle Zugangsdaten tauschen, die der Server kannte: Datenbank-Passwörter, API-Schlüssel, .env-Dateien, SMTP-Zugänge, Admin-Passwörter.
• Prüfen, ob personenbezogene Daten betroffen sein könnten. Dann greifen die Meldepflichten der DSGVO (in der Regel 72 Stunden).

Wenn Sie noch nicht patchen können

Das PHP-Projekt nennt Übergangsmaßnahmen, die einen Teil der bekannten Angriffswege blockieren. Sie ersetzen das Update nicht.

• session.upload_progress.enabled = 0 in der php.ini oder im FPM-Pool setzen (nicht per .user.ini oder ini_set()) und alle Worker neu starten
• post_max_size begrenzen: 8M ohne Datei-Uploads, sonst 32M, upload_max_filesize jeweils darunter
• Bei PHP 8.5 zusätzlich fatal_error_backtraces = 0 setzen
• Zugriff einschränken, z. B. nur per VPN oder über eine Web Application Firewall. Am sichersten ist es, den Dienst bis zum Update ganz vom Netz zu nehmen.

Nützlich für die Zukunft

• Automatische Sicherheitsupdates einschalten, unter Debian und Ubuntu z. B. mit unattended-upgrades, und danach Neustarts der Dienste einplanen.
• Bestand kennen: Wissen Sie, auf welchen Systemen überall PHP läuft? Gerade Zusatzsoftware wie Monitoring-Tools, Wikis oder alte Testsysteme werden gern vergessen.
• Logs aufbewahren und zentral sammeln. Ohne Logs lässt sich ein Einbruch im Nachhinein kaum nachweisen oder ausschließen.
• Vorsicht bei „Exploits“ aus dem Netz: Nach solchen Lücken tauchen schnell angebliche Test-Skripte auf GitHub auf, die selbst Schadsoftware enthalten. Nicht ungeprüft ausführen.

Sie sind unsicher, ob Ihre Website oder Ihr Server betroffen ist? Wir prüfen das gerne mit Ihnen, spielen die Updates ein und sehen uns die Spuren an. Sprechen Sie uns an.