
php2shell: Kritische PHP-Lücken werden aktiv angegriffen
Zwei kritische Lücken im PHP-Kern erlauben die Übernahme von Webservern ohne Login und werden bereits ausgenutzt. Betroffen sind Websites, Nextcloud, Webshops und Portale. Wir zeigen, was jetzt zu tun ist.
Stand: 27. Oktober 2026
Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates für zwei kritische Sicherheitslücken veröffentlicht. Sie tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und werden unter dem Namen „php2shell“ geführt. Angreifer können damit ohne Login einen Webserver übernehmen. Laut The Hacker News meldeten Cloudflare und watchTowr schon am 21. Oktober aktive Angriffsversuche. Die US-Behörde CISA hat beide Lücken am 26. Oktober in ihren Katalog bekannt ausgenutzter Schwachstellen aufgenommen und fordert sofortiges Patchen (siehe CISA-Hinweis). Nach einer heise-Meldung vom 27. Oktober, von der uns nur der Teaser vorlag, gab es am Wochenende erste bestätigte Angriffe, und viele Server sind noch ungepatcht.
Was bedeutet das für Ihr Unternehmen?
Betroffen ist PHP selbst, also die Software, die auf dem Server Webseiten erzeugt. Laut PHP-Sicherheitshinweis gilt das für alle Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei Apache mit mod_php: Dort genügt eine einzige Anfrage von außen, und der Angriff läuft, bevor Ihr eigener Code überhaupt startet.
Typische Fälle sind:
- die Website Ihrer Praxis oder Kanzlei (WordPress, Joomla, TYPO3)
- Nextcloud, Intranet oder Kundenportal
- ein Webshop
- ein selbst betriebener PHP-Server
Auch wenn Ihre Website bei einem Hoster oder einer Agentur liegt, sind Sie betroffen, denn dort muss das Update eingespielt sein. Wichtig: Ein Update von WordPress oder einem anderen System ersetzt das PHP-Update nicht. Auch Seiten mit fehlerfreiem eigenem Code sind angreifbar.
Beide Lücken sind nach CVSS 4.0 mit 9,2 bewertet (kritisch). Bei CVE-2026-109618 handelt es sich laut GitHub-Advisory um das Einschleusen von Programmcode aus der Ferne durch Speicherkorruption bei erschöpftem Arbeitsspeicher. CVE-2026-109619 ermöglicht dies laut PHP über veralteten globalen Zustand (Use-after-free). Zusätzlich können Angreifer laut The Hacker News Arbeitsspeicher des PHP-Prozesses auslesen. Dort können Passwörter, Zugriffstokens, API-Schlüssel und Zertifikate liegen.
Betroffen sind alle Versionen unter 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Laut The Hacker News reichen die Lücken bis zu PHP 5.4 zurück. Einige Organisationen haben Dienste vorsorglich vom Netz genommen, darunter BambooHR und niederländische Behörden-Portale.

PHP 8.1 und älter bekommen offiziell keine Updates mehr. Linux-Distributionen und LTS-Anbieter liefern teils eigene Korrekturen (Backports), und PHP stellt Quell-Backports für 7.4, 8.0 und 8.1 bereit. PHP 8.2 erreicht am 31. Dezember 2026 das Support-Ende.
Was Sie jetzt tun sollten

- Bestandsaufnahme: Listen Sie alle Systeme mit PHP auf, also Website und CMS, Nextcloud, Webshop, Intranet, Portale sowie Geräte mit Weboberfläche, etwa ein NAS. Fragen Sie bei Hoster oder Webagentur schriftlich nach, welche PHP-Version läuft und ob der Fix eingespielt ist.
- Sofort updaten: Aktualisieren Sie auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder spielen Sie das Paket Ihrer Distribution mit CVE-Fix ein. Paketversionen können alt aussehen und trotzdem den Fix enthalten. Prüfen Sie dazu das Changelog auf die CVE-Nummer. Starten Sie danach Apache bzw. PHP-FPM und alle langlaufenden Worker neu, sonst läuft der alte Code weiter.
- Veraltetes PHP ablösen: Bei PHP 8.1 und älter, ebenso bei 8.2 bis zum Support-Ende, planen Sie die Migration auf PHP 8.3 oder höher. Bis dahin brauchen Sie einen Backport vom Distributor oder LTS-Anbieter. Fragen Sie Ihren Hoster, ob er gepatchte Pakete liefert.
- Falls ein Update heute nicht geht: Nehmen Sie den Webdienst vorübergehend vom Netz oder stellen Sie ihn hinter eine Web Application Firewall bzw. einen Reverse-Proxy. Setzen Sie zusätzlich die Workarounds von PHP:
memory_limit=-1serverseitig erzwingen,post_max_sizeniedrig halten (8M ohne, 32M mit Uploads) undsession.upload_progress.enabled=0setzen, danach alle Worker neu starten. Auf PHP 8.5 kommtfatal_error_backtraces=0hinzu. PHP betont: Nur das Update schützt vollständig, die Workarounds verringern einzelne Angriffspfade. - Auf Einbruch prüfen: Suchen Sie in den Webserver-Logs nach ungewöhnlichen Multipart-Anfragen mit anschließenden Memory-Limit-Fehlern oder wiederholten HTTP-500-Antworten. Auffällig sind außerdem sehr große PHPSESSID-Cookies und unerklärte Worker-Neustarts. Suchen Sie im Webverzeichnis nach unbekannten PHP-Dateien (Webshells). Bei Verdacht sollten Sie Passwörter, API-Schlüssel und Zugangsdaten ändern, die auf dem Server liegen oder über ihn liefen. Wegen der möglichen Speicherauslese ist das sinnvoll, auch ohne bewiesenen Einbruch.
- Datenschutz klären: Liegen Patienten- oder Mandantendaten auf einem betroffenen Server, prüfen Sie nach DSGVO, ob ein Datenabfluss vorliegen könnte. Binden Sie dann Ihren Datenschutzbeauftragten ein und beachten Sie die Meldefristen.
- Dauerhaft vorsorgen: Nehmen Sie Webserver in die regelmäßige Patch-Überwachung auf und prüfen Sie Ihre Backups, damit sich ein kompromittierter Server aus einem sauberen Stand wiederherstellen lässt.
Häufige Fragen
Reicht es, mein WordPress oder TYPO3 zu aktualisieren?
Nein. Die Lücken stecken in PHP selbst. Das CMS-Update ersetzt das PHP-Update nicht, beides muss separat geprüft werden.
Was ändert sich nach dem Update?
Laut The Hacker News führt das Update ein neues hartes Speicherlimit ein. Prüfen Sie memory_limit und post_max_size danach gegen den Bedarf Ihrer Anwendung, damit etwa Uploads weiterhin funktionieren.
Gibt es noch weitere Lücken?
Zu CVE-2026-115560 rät PHP seit dem 23. Oktober ebenfalls zu session.upload_progress.enabled=0. Diese Lücke gilt als unwahrscheinlich ausnutzbar, ein vollständiges Advisory soll mit dem nächsten regulären Release folgen.
So unterstützt Sie comgie
Wir von comgie aus Münster klären mit Ihnen im Münsterland, wo PHP bei Ihnen läuft, und spielen Updates ein. Wir prüfen Logs auf Spuren und nehmen Webserver in unsere Managed IT-Services mit laufender Patch-Überwachung auf. Ein geprüftes Backup mit Notfallplan hilft, wenn ein Server doch betroffen ist. Sprechen Sie uns über die Kontaktseite an, wir melden uns zeitnah.
