PHP2Shell: Die kritischen PHP-Lücken vom Oktober 2026 für Selbsthoster erklärt

Kurz gesagt: Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, die inzwischen unter dem Namen PHP2Shell laufen. Sie stecken in PHP selbst — also in dem Programm, das WordPress, Nextcloud, viele Router-Oberflächen und NAS-Apps ausführt — und können Angreifern ohne Anmeldung erlauben, auf deinem Server eigenen Code zu starten. Die Lösung ist unspektakulär, aber dringend: PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bringen, Container neu ziehen, Dienste neu starten. Wer eine PHP-Version ohne Support betreibt, hat jetzt ein echtes Problem.

Was ist passiert? #

Das PHP Security Team hat mit den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 zwei Lücken behoben, die eine Codeausführung aus der Ferne ohne Anmeldung ermöglichen können; betroffen sind alle PHP-Installationen, die Webanfragen beantworten, das höchste Risiko sieht das Team bei Apache mit mod_phpBelegt. Beide Lücken bewertet das Projekt im Bewertungssystem CVSS 4.0 mit 9,2 von 10 Punkten. CVSS (Common Vulnerability Scoring System) ist eine Skala, mit der man die Schwere von Lücken vergleichbar macht; alles ab 9 gilt als kritisch.

Der Ablauf war chaotischer als geplant. Laut PHP Foundation tauchten die CVE-Nummern am 20. Oktober vorzeitig in Foren auf, kurz darauf wurde versehentlich ein Video mit einem funktionierenden Proof of Concept veröffentlicht, und das Release wurde deshalb um einen Tag auf den 21. Oktober vorgezogenBelegt. Ein Proof of Concept (PoC) ist ein Nachweis, dass sich eine Lücke tatsächlich ausnutzen lässt — oft der Ausgangspunkt für echte Angriffswerkzeuge.

Das BSI, die deutsche Cybersicherheitsbehörde, hat ungewöhnlich deutlich reagiert. In seiner Pressemitteilung vom 21. Oktober hielt das BSI eine großflächige Ausnutzung innerhalb weniger Stunden nach Erscheinen der Updates für wahrscheinlich, weil KI-gestützte Werkzeuge das schnelle Analysieren von Patches erleichternBelegt. Im zugehörigen Sicherheitshinweis stuft das BSI die Lage auf Stufe 3 von 4 („Orange“) ein: Maßnahmen müssen unverzüglich ergriffen werden.

Wie funktionieren die Lücken — in einfachen Worten? #

Beide Fehler haben mit der Speicherverwaltung zu tun, nicht mit einer bestimmten Anwendung.

• CVE-2026-109618 („OOM corruption“): PHP bricht eine Anfrage ab, wenn sie das eingestellte Speicherlimit (memory_limit) überschreitet — „OOM“ steht für out of memory. Passiert das genau in einem Moment, in dem interne Datenstrukturen erst halb angelegt sind, kann PHP beim Aufräumen diese ungültigen Daten als gültig behandeln; laut Advisory lässt sich der Speichermangel unter anderem über präparierte Formular-Uploads (Multipart-Anfragen) auslösenBelegt.
• CVE-2026-109619 („stale global state“): PHP-Prozesse bearbeiten nacheinander viele Anfragen. Nach bestimmten fatalen Fehlern kann ein Prozess Verweise auf Speicher einer früheren Anfrage behalten; greift eine spätere Anfrage im selben Prozess darauf zu, entsteht ein sogenannter Use-after-free — Zugriff auf bereits freigegebenen Speicher.

Solche Speicherfehler sind gefährlich, weil ein Angreifer mit viel Geduld den Inhalt dieses „verwaisten“ Speichers beeinflussen und so den Programmablauf umlenken kann. Wichtig für dich: Es ist egal, wie gut dein WordPress oder deine Nextcloud gepflegt ist — die Lücke sitzt eine Ebene darunter.

Warum trifft eine PHP-Lücke so viele Websites? #

PHP ist die Sprache des Webs, ob man sie mag oder nicht. Laut W3Techs nutzen am 26. Oktober 2026 rund 69 Prozent aller Websites, deren serverseitige Sprache erkennbar ist, PHP; von diesen PHP-Seiten laufen etwa 27 Prozent noch auf PHP 7 und knapp 8 Prozent auf PHP 5Belegt — beides Versionen, die das PHP-Projekt längst nicht mehr pflegt.

Dazu kommt PHP an Stellen, an die man nicht sofort denkt. Das BSI nennt WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense als Beispiele für PHP-basierte Projekte und führt unter anderem QNAP-, Synology-, OPNsense- und pfSense-Produkte als mindestens teilweise betroffen aufBelegt. Gerade Weboberflächen von Firewalls, Routern und NAS-Systemen bringen oft ihr eigenes PHP mit.

Wie viele Systeme noch offen sind, lässt sich nur schätzen. SecurityWeek fasst Zählungen mehrerer Firmen zusammen: Censys sah am 21. Oktober von rund 1,58 Millionen Internet-Hosts mit erkennbarer PHP-Version etwa 1,57 Millionen ungepatcht, VulnCheck zählte mindestens eine Million Hosts mit PHP-Versionen ohne SupportBelegt. Solche Scans erfassen nur Server, die ihre Version verraten — die tatsächliche Zahl kann höher oder niedriger liegen.

Wird die Lücke schon ausgenutzt? #

Hier lohnt sich genaues Lesen, denn die Quellen widersprechen sich nicht, messen aber Unterschiedliches. Amazon berichtet, in seinem Köder-Netz (Honeypots) schon am 17. Oktober einen ersten Ausnutzungsversuch gesehen zu haben, also vier Tage vor der Veröffentlichung; nach der Freigabe der Updates seien binnen Stunden weitere Proof-of-Concept-Exploits aufgetaucht und gegen die Köder-Systeme eingesetzt wordenHerstellerangabe. Ein Honeypot ist ein absichtlich verwundbar wirkendes System, das Angriffe anlockt und protokolliert. Ein Versuch ist aber noch kein erfolgreicher Einbruch. Das BSI schrieb am 22. Oktober, ihm sei noch keine erfolgreiche Ausnutzung in der Breite bekannt; automatisierte Angriffsversuche zeigten aber großes Interesse der AngreiferBelegt. In den Katalog der US-Behörde CISA für nachweislich ausgenutzte Lücken (Known Exploited Vulnerabilities, KEV) waren die beiden CVEs bis zur Ausgabe vom 23. Oktober nicht aufgenommen. Diese Lage kann sich täglich ändern.

Kurz: Gehe davon aus, dass jede öffentlich erreichbare, ungepatchte PHP-Installation gescannt und angegriffen wird.

Welche PHP-Versionen haben noch Support? #

Das PHP-Projekt versorgt im Oktober 2026 nur noch die Zweige 8.2 (Sicherheitsupdates bis 31.12.2026), 8.3 (bis 31.12.2027), 8.4 (bis 31.12.2028) und 8.5 (bis 31.12.2029)Belegt. Jeder Zweig bekommt zwei Jahre aktive Pflege und zwei weitere Jahre nur Sicherheitskorrekturen. PHP 8.1 und älter sind End of Life (EOL): keine offiziellen Updates mehr. Für 7.4, 8.0 und 8.1 hat das Sicherheitsteam diesmal ausnahmsweise minimale Quellcode-Patches bereitgestellt — das sind aber keine offiziellen Releases, sondern eine Notlösung für alle, die selbst kompilieren.

Zwei Dinge sind für Selbsthoster wichtig:

1. Distributionen zählen anders. Debian und Ubuntu liefern ihre eigene PHP-Version und übertragen Sicherheitskorrekturen zurück (Backport). Debian führt die Korrektur für Debian 13 („trixie“) als Paket 8.4.27 (DSA-6574-1) und für Debian 12 („bookworm“) als Paket 8.2.35 über das Langzeit-Team (DLA-4848-1)Belegt. Entscheidend ist also, ob das Paket deiner Distribution aktualisiert ist — nicht nur die nackte Versionsnummer.
2. PHP 8.2 läuft Ende 2026 aus. Wer jetzt auf 8.2 patcht, sollte den Umstieg auf 8.3 oder neuer gleich mit einplanen. WordPress empfiehlt PHP 8.3 oder neuer und warnt, dass ältere Versionen ihr Lebensende erreicht haben.

Was heißt das für dich? #

Für Selbsthoster mit Nextcloud, WordPress, Webmail oder einer Firewall mit PHP-Oberfläche gilt diese Reihenfolge:

1. Inventur machen. Wo läuft bei dir PHP? Typische Kandidaten im Homelab: Nextcloud, WordPress, Matomo, phpMyAdmin, Webmail, die Oberfläche von OPNsense oder pfSense, Apps auf dem NAS. Die laufende Version zeigt php -v auf dem Host oder docker exec <container> php -v im Container.
2. Paketquellen aktualisieren. Auf Debian/Ubuntu reicht sudo apt update && sudo apt upgrade. Prüfe danach im Changelog oder Security-Tracker deiner Distribution, ob die Korrektur für beide CVEs enthalten ist.
3. Container neu ziehen, nicht nur neu starten. Das BSI weist ausdrücklich darauf hin, dass Anwendungen in Docker-Containern unabhängig vom Host aktualisiert oder neu gebaut werden müssen. Mit Docker Compose heißt das: docker compose pull, dann docker compose up -d — vorausgesetzt, der Anbieter des Images hat schon eine korrigierte Fassung veröffentlicht. Prüfe deshalb danach noch einmal mit php -v. Eigene Images mit FROM php:… musst du neu bauen. Ein reiner Neustart lädt dasselbe alte Image.
4. Alle PHP-Prozesse neu starten. PHP-FPM, Apache und Worker laufen sonst mit dem alten Code im Speicher weiter.
5. NAS und Firewall aktualisieren. QNAP hat für QTS, QuTS hero und QuTScloud korrigierte Builds vom 23. Oktober veröffentlicht; für einige Apps wie Notes Station 3 stand ein Fix am 24. Oktober noch ausHerstellerangabe. Synology stuft seine PHP-Pakete für DSM als kritisch ein und nennt korrigierte Versionen; für das Paket PHP 7.3 gibt es keinen Fix mehr. Das im Betriebssystem eingebaute PHP hält Synology dagegen für kaum von außen angreifbar. OPNsense hat Hotfixes mit PHP 8.3.36 beziehungsweise 8.5.12 veröffentlicht.
6. Nichts unnötig ins Internet stellen. Die Weboberfläche von NAS, Router oder Firewall gehört nie per Portweiterleitung ins Internet. Für den Fernzugriff ist ein VPN der bessere Weg — etwa mit WireGuard auf OPNsense.
7. Wenn du nicht sofort patchen kannst: vom Netz nehmen. Das PHP-Advisory nennt Übergangsmaßnahmen wie session.upload_progress.enabled=0 oder eine niedrige post_max_size, betont aber, dass keine davon eine Installation sicher macht. Auch das BSI empfiehlt in diesem Fall, eine vorübergehende Trennung vom Internet zu erwägen.
8. Auf Spuren achten. Unbekannte neue PHP-Dateien im Webverzeichnis, neue Admin-Konten oder ungewöhnliche Prozesse, die der Webserver startet, sind Warnzeichen. Bei Verdacht: Instanz isolieren, aus einem sauberen Backup neu aufsetzen und Passwörter wechseln.

Wenn du deine Nextcloud ohnehin gerade aufsetzt: Im Guide Nextcloud selbst hosten steckt die Grundlage für einen sauberen Update-Weg.

Einordnung: War es das jetzt? #

Wahrscheinlich nicht ganz. Am 23. Oktober hat das PHP-Projekt bereits einen weiteren, informativen Hinweis nachgeschoben: In einer ungewöhnlichen Konfiguration der Sitzungsverwaltung gibt es ein zusätzliches Problem (CVE-2026-115560), Details sollen mit dem nächsten Release folgen; bis dahin empfiehlt das Projekt session.upload_progress.enabled=0. Das BSI hält es für möglich, dass die gestiegene Aufmerksamkeit für PHP und der Einsatz von KI bei der Fehlersuche weitere Lücken ans Licht bringen. Das ist eine Einschätzung, keine Gewissheit — aber ein guter Grund, die Update-Routine fürs Homelab nicht nur für diesen einen Fall aufzusetzen.