PHP2Shell: Kritische PHP-Lücken gefährden Webserver weltweit

Am 21. Oktober 2026 hat das PHP-Team Notfall-Updates für zwei kritische PHP-Sicherheitslücken im PHP-Kern veröffentlicht. Unter dem Namen „PHP2Shell“ – in Anlehnung an Log4Shell – erlauben sie Angreifern, ohne Anmeldung eigenen Code auf Webservern auszuführen. Das BSI warnt mit Stufe 3 (orange).

Das Brisante: PHP läuft auf einem Großteil aller Websites weltweit. WordPress, Shopware, Nextcloud, Drupal, Laravel-Anwendungen – sie alle sind betroffen, egal wie aktuell die Anwendung selbst ist. Die Lücke steckt im Interpreter, nicht im CMS.

1) Was steckt hinter PHP2Shell?

• CVE-2026-109618 (CVSS 4.0: 9.2): Bricht PHP eine Anfrage ab, etwa weil der Speicher ausgeht, arbeitet es beim Aufräumen mit bereits freigegebenen Daten weiter. Angreifer lösen das gezielt mit präparierten Multipart-Requests aus. Zusätzlich kann Prozessspeicher ausgelesen werden – inklusive Passwörtern, Session-Tokens oder API-Keys.
• CVE-2026-109619 (CVSS 4.0: 9.2): Ein Use-after-free über Requests hinweg. Reste einer vorherigen Anfrage werden von der nächsten Anfrage im selben PHP-Prozess weiterverwendet, u. a. über die Funktion Session Upload Progress.

Warum das fürs Business kritisch ist: Der Code läuft mit den Rechten des Webserver-Benutzers. Typische Folge sind Webshells, über die Angreifer dauerhaft Zugriff behalten, Daten abziehen oder Malware an Website-Besucher ausliefern.

2) Angriffe laufen bereits

Die Details sind bereits am 20. Oktober vor dem geplanten Patch-Termin durchgesickert. Amazon Threat Intelligence beobachtete erste Angriffsversuche in Honeypots sogar schon am 17. Oktober. Cloudflare, watchTowr und Patchstack melden Angriffsverkehr, ein öffentliches Video zeigt erfolgreiche Angriffe auf Testinstallationen von WordPress, Drupal, Joomla und Laravel. Erste Proof-of-Concept-Exploits kursieren.

Business-Takeaway: Hier gilt nicht „beim nächsten Wartungsfenster“, sondern heute. Und: Wer seit dem 17. Oktober ungepatcht im Internet stand, sollte auch auf Spuren eines Einbruchs prüfen.

3) Welche Versionen und Systeme sind betroffen?

Behoben sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Alle älteren Stände dieser Zweige sind verwundbar.

• PHP 8.1 und älter: Kein offizielles Release mehr. Für 7.4 bis 8.1 gibt es nur Quellcode-Korrekturen, Backports einzelner Distributionen oder Anbieter mit Langzeitsupport. Betroffen sind laut BSI und Wiz Versionen bis mindestens zurück zu PHP 5.
• mod_php (Apache): höchstes Risiko, ein Angriff funktioniert hier unabhängig von der Anwendung
• FrankenPHP: verhält sich laut PHP-Team wie mod_php
• PHP-FPM, php-cgi, LiteSpeed: ebenfalls betroffen, je nach Anwendung ausnutzbar
• Oft übersehen: NAS-Systeme, Firewall-Oberflächen und Appliances mit PHP-basierter Weboberfläche

Wichtig: Distributionen wie Debian, Ubuntu oder RHEL patchen häufig per Backport. Dort zählt der Paketstand laut Security-Hinweis der Distribution, nicht die PHP-Versionsnummer.

4) Bin ich betroffen? So prüfen Sie es

• Paketstand prüfen: unter Debian/Ubuntu z. B. apt list --upgradable | grep -i php, unter RHEL & Co. dnf check-update 'php*'
• Laufende Version im Web-Kontext prüfen: php -v zeigt nur die Kommandozeilen-Version. Entscheidend ist, welche Version der Webserver tatsächlich ausführt.
• Hosting: Bei Shared Hosting oder Managed Servern liegt das Update beim Anbieter. Patchstand schriftlich bestätigen lassen.

5) So reduzieren Sie das Risiko

1. Inventur: Alle PHP-Systeme mit Version, Betriebsart (FPM, mod_php, …) und Paketquelle erfassen
2. Update einspielen und anschließend alle PHP-Prozesse neu starten (PHP-FPM, Apache). Laufende Prozesse behalten sonst den alten Code. Bei Containern: neues Image bauen und ausrollen.
3. Verifizieren: Laufende Version im Web-Kontext prüfen und dokumentieren
4. Nicht sofort patchbar? System vom Internet trennen oder nur per VPN/IP-Freigabe erreichbar machen
5. Übergangsmaßnahmen wie session.upload_progress.enabled = Off, session.use_strict_mode = 1 oder WAF-Regeln verschaffen nur Zeit – sie ersetzen das Update nicht
6. Auf Kompromittierung prüfen: neue oder veränderte PHP-Dateien in Web- und Upload-Verzeichnissen, neue Cronjobs, neue Benutzer oder WordPress-Admins, Shells oder curl/wget-Aufrufe aus PHP-Prozessen heraus. Bei Verdacht Datenbank- und API-Zugangsdaten tauschen.

Der rote Faden

PHP2Shell zeigt einmal mehr: Die gefährlichsten Lücken stecken oft nicht in der Anwendung, sondern in der Plattform darunter. Wer nur WordPress und Plugins aktuell hält, ist hier nicht geschützt. Und wie schon beim Rekord-Patchday von Microsoft gilt: Je schneller Schwachstellen gefunden werden, desto wichtiger sind eine vollständige Inventur und ein eingespielter Notfall-Patchprozess.

Executive-Checkliste

• Wissen wir, wo überall PHP läuft – inklusive Hosting, NAS und Appliances?
• Ist auf allen Systemen ein gepatchter Stand aktiv und wurden die Dienste neu gestartet?
• Haben unsere Dienstleister und Hoster den Patch bestätigt?
• Wurden exponierte Systeme seit dem 17. Oktober auf Webshells und Auffälligkeiten geprüft?
• Gibt es einen Plan für veraltete PHP-Versionen ohne offiziellen Support?

Ebenfalls lesenswert: Welche Microsoft-Updates jetzt Vorrang haben, zeigt unser Beitrag Patchday Oktober 2026: Über 1.400 Lücken – und jetzt?

Quellen: BSI-Cybersicherheitswarnung, Borns IT- und Windows-Blog, CMS ADMINS, INSYS