php2shell-Attacke - Alle Server gepatcht

PHP2Shell: Was ist passiert?

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt außerplanmäßige Sicherheitsupdates gegen zwei kritische Schwachstellen. Unter dem Namen PHP2Shell sind sie als CVE-2026-109618 und CVE-2026-109619 bekannt. Beide betreffen interne Speicher- und Fehlerbehandlungsmechanismen von PHP. Sie können unter geeigneten Bedingungen Remote Code Execution (RCE) ohne Authentifizierung ermöglichen.

Anders als bei einer Sicherheitslücke in einem WordPress-Plugin liegt der Fehler im PHP-Interpreter. Auch ein korrekt programmiertes CMS oder ein sorgfältig abgesichertes PHP-Skript kann deshalb auf einer verwundbaren PHP-Version laufen. Die konkreten Voraussetzungen unterscheiden sich je nach Serveranbindung und Schwachstelle. Besonders kritisch bewertet das PHP-Sicherheitsteam Apache mit mod_php; auch PHP-FPM ist betroffen.

Die beiden Schwachstellen technisch erklärt

Wichtig: PHP2Shell ist keine gewöhnliche Datei-Upload-Schwachstelle und kein Synonym für eine Webshell-Kampagne. Der Angriffsweg nutzt Fehler in PHP selbst. Deshalb beheben weder ein WordPress-Update noch das Sperren von eval() die Ursache.

Angriffe erkennen: Logs und Indikatoren

Eine einzelne verdächtige Anfrage beweist noch keine Kompromittierung. Achte besonders auf ungewöhnliche Multipart-POSTs, PHP-Abstürze, Speicherfehler, unerwartete Kindprozesse und Änderungen an Webdateien.

# Apache-Access-Logs nach Upload-Progress-Indikatoren durchsuchen
grep -R -i 'PHP_SESSION_UPLOAD_PROGRESS' /var/log/httpd/*access* 2>/dev/null

# PHP-FPM- und Apache-Fehler seit dem 17.10.2026 prüfen
journalctl --since '2026-10-17' -u php-fpm -u httpd --no-pager | grep -Ei 'memory|segfault|signal|fatal|crash'

# Kürzlich geänderte PHP-Dateien im Webroot suchen
find /home/httpd -type f -name '*.php' -newermt '2026-10-17' -print

Die erste Suche erkennt nur Anfragen, deren relevante Zeichenfolge tatsächlich im protokollierten Teil des Requests steht; gewöhnliche Apache-Access-Logs speichern POST-Bodys normalerweise nicht. Fehlende Treffer sind deshalb kein Entwarnungssignal. Prüfe ergänzend ModSecurity-Audit-Logs und Prozess-/Dateiüberwachung.

Welche PHP-Installationen sind betroffen?

Betroffen sind ungepatchte PHP-Versionen, die Webanfragen verarbeiten, darunter Installationen mit Apache mod_php, PHP-FPM, php-cgi, LiteSpeed oder FrankenPHP. Die PHP-Version und die tatsächliche Laufzeitkonfiguration sind entscheidend – nicht, welches CMS eingesetzt wird.

• PHP 8.5 vor 8.5.12
• PHP 8.4 vor 8.4.27
• PHP 8.3 vor 8.3.36
• PHP 8.2 vor 8.2.35
• PHP 8.1 und ältere Upstream-Zweige: End of Life; auf einen unterstützten Zweig migrieren oder nachweislich vom Betriebssystemanbieter gepflegte Sicherheits-Backports prüfen.

Achtung bei RHEL/Rocky Linux: Ein Distributor kann Sicherheitskorrekturen zurückportieren, ohne die PHP-Upstream-Versionsnummer anzuheben. Prüfe deshalb Paket-Release und Hersteller-Sicherheitsmeldung; php -v allein reicht nicht immer aus.

Sofort Hilfe: PHP-Konfiguration und ModSecurity

Wenn das Update noch nicht eingespielt werden kann, solltest du die öffentlich erreichbare Angriffsfläche vorübergehend verkleinern. Die folgenden Maßnahmen sind zusätzliche Risikoreduktion, keine vollständige Behebung. Teste sie zunächst in einer Staging-Umgebung.

session.upload_progress.enabled = Off

; z. B. /etc/php-fpm.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off

# Nur aktivieren, wenn Multipart-Formulare vorübergehend entbehrlich sind.
SecRule REQUEST_HEADERS:Content-Type "@rx (?i)^multipart/" \
 "id:1002101,phase:1,deny,status:403,log,msg:'Temporary PHP2Shell multipart restriction'"

; PHP-Konfiguration – Werte an die Anwendung anpassen
post_max_size = 8M
upload_max_filesize = 4M
max_file_uploads = 5

Bei Verdacht auf einen erfolgreichen Angriff

1. Betroffenen Dienst isolieren, ohne vorhandene Beweismittel unnötig zu verändern.
2. Access-, Error-, PHP-FPM-, ModSecurity-Audit- und Systemlogs sichern; nach Möglichkeit Snapshot und Speicherabbild erstellen.
3. Ab mindestens 17. Oktober 2026 auf verdächtige Anfragen, Prozessstarts, Abstürze und Dateiveränderungen prüfen. Ein fehlender Treffer schließt einen Angriff nicht aus.
4. System aus vertrauenswürdigen Quellen mit gepatchtem PHP neu aufbauen beziehungsweise wiederherstellen; Persistenz, Zugangsdaten und mögliche Datenabflüsse untersuchen.
5. Betroffene Zugangsdaten und Geheimnisse nach Eindämmung des Vorfalls rotieren und gegebenenfalls Meldepflichten prüfen.

Wichtigste Maßnahme: PHP sicher aktualisieren

Nur ein korrigierter PHP-Build behebt beide Schwachstellen vollständig. Das PHP-Projekt hat folgende Versionen veröffentlicht:

• PHP 8.5.12 oder neuer
• PHP 8.4.27 oder neuer
• PHP 8.3.36 oder neuer
• PHP 8.2.35 oder neuer

Für RPM-basierte Systeme wie Rocky Linux und RHEL zunächst verfügbare Updates und installierte Pakete prüfen:

# Installierte PHP-Pakete und verfügbare Updates prüfen
rpm -qa | grep -E '^php([0-9.]|-)' | sort
dnf check-update 'php*'

# Falls ein passendes, vom Distributor gepatchtes Update vorliegt:
dnf upgrade 'php*'

# Konfiguration prüfen und die tatsächlich genutzten Dienste neu starten
php-fpm -t
apachectl configtest
systemctl restart php-fpm
systemctl restart httpd

Wichtig: Die Dienstnamen und Paketnamen können abweichen, insbesondere bei parallel installierten PHP-Versionen oder separaten PHP-FPM-Instanzen. Ein dnf upgrade garantiert nur dann Schutz, wenn das Repository bereits korrigierte Pakete anbietet. Überprüfe Hersteller-Advisories und die tatsächlich vom Webserver verwendete PHP-Version. Bei externen oder eigenen PHP-Builds muss der Patch dort separat eingespielt werden.

Prüfe anschließend die Versions- und Paketinformationen sowie den Status der Worker:

php -v
rpm -qi php-cli php-fpm 2>/dev/null
systemctl status php-fpm httpd --no-pager

Die CLI-Version kann von der PHP-Version der Website abweichen. Bei mehreren Pools oder PHP-Installationen muss jede produktiv verwendete Runtime kontrolliert und neu gestartet werden. Für eine sichere Kontrolle eignet sich ein kurzfristiger, nur lokal erreichbarer PHP-Endpunkt, der PHP_VERSION ausgibt; anschließend wieder entfernen.

Fazit

PHP2Shell ist eine kritische Schwachstelle im PHP-Kern – keine gewöhnliche Webshell- oder Plugin-Lücke. Selbst sorgfältig entwickelte PHP-Anwendungen können auf einem ungepatchten Interpreter betroffen sein. Die wirksamste Sofortmaßnahme ist daher das unverzügliche Update auf eine korrigierte PHP-Version beziehungsweise einen verifizierten Distributor-Backport.

Weiterführende Quellen: PHP Security Advisory: CVE-2026-109618, PHP Security Advisory: CVE-2026-109619, offizielle PHP-Releases und AWS-Analyse zur aktiven Ausnutzung.