38 Sekunden. So lange dauerte es im Video der Sicherheitsfirma Calif, bis auf einem Laravel-Server fremde Systembefehle liefen. Kein Passwort, kein Login, nur HTTP-Anfragen an eine ganz normale PHP-Seite. Die Lücke dahinter heißt php2shell, und sie steckt nicht in Laravel, nicht in WordPress, nicht in Nextcloud. Sie steckt in PHP selbst. Also in dem Programm, das bei rund 70 Prozent aller Websites die Seiten baut, und bei dir vermutlich im Nextcloud-Container.

Was bei php2shell kaputt ist
PHP bearbeitet Anfragen in Arbeitern, kleinen Prozessen, die nacheinander viele Anfragen abarbeiten. Stell dir eine Werkbank vor, die nach jedem Auftrag abgeräumt wird. Beide Fehler haben damit zu tun, dass das Abräumen nicht immer klappt.
Beim ersten Fehler, CVE-2026-109618, lässt ein Angreifer den Speicher absichtlich volllaufen, zum Beispiel mit einem Formular-Upload, der aus Tausenden Teilen besteht. PHP bricht dann ab, räumt aber einen Zustand auf, den es nie fertig aufgebaut hat. Beim zweiten, CVE-2026-109619, bleibt nach einem fatalen Fehler Zustand auf der Werkbank liegen und die nächste Anfrage greift hinein. Laut Advisory braucht der zweite Weg mindestens zwei Anfragen: eine, die den Fehler auslöst, und eine, die ihn ausnutzt.
In beiden Fällen ist das Ergebnis dasselbe: Ein Fremder führt Code mit den Rechten des Webservers aus. Das PHP-Team bewertet beide Lücken mit 9,2 von 10. Und die Anwendung darüber spielt keine Rolle. Wiz schreibt, schon ein „Hello World“ auf einer betroffenen Version kann angreifbar sein. Sansec hat die Lücke gegen WordPress, Drupal, Magento und ausdrücklich Nextcloud bestätigt.
Was mich an der Sache beruhigt und beunruhigt zugleich: Ein Angriff braucht laut Heise meist Tausende bis Zehntausende Anfragen. Das ist kein Klick, das ist ein Skript. Aber Skripte sind billig, und genau deshalb erwartet Sansec Massenangriffe.
Bist du betroffen? Vermutlich ja
Die ehrliche Antwort: Wenn irgendwo bei dir PHP läuft und aus dem Internet erreichbar ist, dann ja. Die Liste ist lang, deshalb nur die Fälle, die im Homelab typisch sind:
- Nextcloud, egal ob per Docker, Snap oder von Hand installiert. Das offizielle Docker-Image baut auf dem offiziellen PHP-Image auf, also steckt die Lücke mit drin.
- WordPress und alles andere, was auf einem Webhoster oder einem eigenen Server in PHP läuft: Shops, Foren, Wikis.
- Router- und NAS-Oberflächen. Heise listet unter anderem pfSense, OPNsense, Synology und QNAP als Kandidaten, weil ihre Weboberflächen PHP nutzen. Herstelleraussagen dazu habe ich noch keine gesehen. Solange die fehlen, gilt: Die Verwaltungsoberfläche gehört nicht ins Internet, das war sie vorher schon nicht.
Am stärksten gefährdet ist laut php.net der Betrieb als Apache-Modul, mod_php. Das ist genau die Variante, die das normale nextcloud-Image ohne Zusatz verwendet. PHP-FPM stuft das Advisory als wahrscheinlich anfällig ein, ohne einen fertigen Angriffsweg zu zeigen. Ich würde daraus keine Entwarnung lesen. „Wahrscheinlich anfällig“ heißt updaten.
Und dann ist da noch die Versionsfrage. Updates gibt es nur für PHP 8.2 bis 8.5. Wer noch 8.1 oder älter fährt, bekommt von PHP selbst nichts mehr. php.net nennt Backports für 7.4, 8.0 und 8.1, Heise schreibt, die seien noch nicht da. Debian und Ubuntu haben die Patches laut php.net vorab bekommen und pflegen ihre Pakete selbst, ein altes Paket mit neuem Fix ist dort also normal. Was ohne Pakete und ohne Backport dasteht, ist ab heute ein Risiko ohne Ablaufdatum. Ich würde den Umstieg nicht mehr verschieben.
So prüfst und updatest du
Erst nachsehen, welche Version läuft. Auf dem Server direkt:
php -vIm Container fragst du den Container, nicht den Host. Bei Nextcloud per Compose heißt der Dienst meist app:
docker compose exec app php -vSteht da 8.2.35, 8.3.36, 8.4.27 oder 8.5.12, bist du durch. Alles darunter ist offen. Der Weg zum Update hängt davon ab, wie PHP bei dir hinkam:
- Docker: Ein Neustart des Containers ändert nichts, der nimmt dasselbe alte Image. Du brauchst ein neues Image und einen Neubau:
docker compose pull && docker compose up -d. Das offizielle Nextcloud-Image wurde heute aktualisiert, ob der Fix schon drin ist, sagt dir danach wiederphp -v. Ist er es nicht, prüf morgen noch mal. - Debian, Ubuntu und Co.:
sudo apt update && sudo apt upgrade, danach Webserver oder PHP-FPM neu starten. Bei Distributionen zählt nicht die Versionsnummer, sondern der Changelog des Pakets. - Webhoster: Du kannst nichts selbst tun außer nachfragen. Uberspace hat laut Heise PHP für einige Stunden ganz abgeschaltet, bis die Pakete da waren. Ein Hoster, der so etwas tut, denkt mit.
Backup vorher, du kennst das. Ein PHP-Update ist selten das Problem, aber falls doch, willst du nicht an einem Tag ohne Nextcloud rumraten.
Wenn du nicht sofort updaten kannst, nennen Advisory und php.net ein paar Einstellungen, die den Angriff erschweren: memory_limit=-1 gegen den ersten Fehler, session.upload_progress.enabled=0 gegen den zweiten, auf PHP 8.5 zusätzlich fatal_error_backtraces=0. Das PHP-Team selbst schreibt dazu, man solle das nicht als mehr betrachten als eine „vorübergehende Krücke“. Das ist eine ungewöhnlich deutliche Formulierung für ein Advisory, und ich nehme sie beim Wort. Cloudflare hat Regeln gegen bekannte Angriffsmuster auch im kostenlosen Tarif ausgerollt und nennt sie selbst nur einen „temporary fix“. Nützlich, wenn du eh dahinter stehst. Ein Grund, dich jetzt dahinter zu stellen, ist es nicht.
Wie die Lücke gefunden wurde
Der Teil, der mich an der Geschichte am meisten beschäftigt, ist die Zeitleiste. Wiz hat die Fehler laut eigener Angabe am 19. August gefunden und am 24. August gemeldet, Calif war laut Sansec schon am 11. August dran. Die Veröffentlichung war für den 22. Oktober geplant. Dann sickerte etwas durch, und das PHP-Team zog die Veröffentlichung um einen Tag vor. Cloudflare meldete die ersten Angriffe am 21. Oktober um 7:43 Uhr UTC. Der Patch kam um 14 Uhr. Sechs Stunden, in denen jeder PHP-Server im Netz offen war, ohne dass seine Betreiber davon wussten.
Und dann ist da noch, wie gefunden wurde. Wiz schreibt, ein einzelner Forscher habe den Exploit in etwa einer Woche gebaut, mit Hilfe von Gemini 4 Argon und GPT-5.6 Sol, die die Angriffe an verschiedene PHP-Versionen und Speicherlayouts anpassten. Ohne KI, schreibt Wiz, wäre das für ein ganzes Team kaum machbar gewesen. Die Modelle, über die ich vor einer Woche noch wegen ihrer Chat-Abos geschrieben habe, machen jetzt also Speicherfehler-Forschung. Eine Woche statt Monate, und das gilt in beide Richtungen: Dieselben Werkzeuge, die den Fix beschleunigen, beschleunigen den Angriff. Dass PHP seit Mai ein eigenes Sicherheitsteam mit drei Leuten hat und dieser Fund aus einer von OpenAI bezahlten Prüfung kam, rechne ich den Beteiligten hoch an. Das Gegenmodell, ein Audit von 2024 mit ähnlichen Funden, über deren Fix sich die Entwickler nicht einig wurden, steht bei Heise gleich daneben.
Was bleibt
Zwei Dinge würde ich aus dem Tag mitnehmen. Erstens: Versionen prüfen ist heute Pflicht, nicht Kür. Wer seine Nextcloud per Compose betreibt, ist mit zwei Befehlen durch. Zweitens: Alles, was nicht aus dem Internet erreichbar sein muss, gehört hinter ein VPN. Die Lücke trifft nur, was von außen Anfragen annimmt. Eine Nextcloud, die nur im Heimnetz und per WireGuard erreichbar ist, muss zwar genauso updaten, aber sie steht nicht in der Shodan-Liste mit den 1,9 Millionen Treffern, die Tenable zitiert.
Welche PHP-Version hat dir dein php -v heute gezeigt, und war das Update bei dir ein Zweizeiler oder ein Nachmittag? Schreib's in die Kommentare.
Wie du dich vor dem nächsten Update absicherst, steht Schritt für Schritt im Beitrag Nextcloud Backup erstellen; und wer solche Meldungen lieber sonntags gesammelt bekommt, trägt sich unten in den Newsletter ein.
Quellen
- php.net: Security advisory und Release-Ankündigungen 8.5.12, 8.4.27, 8.3.36, 8.2.35 (21. Oktober 2026)
- PHP Advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
- PHP Advisory GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
- heise online: php2shell, kritische Sicherheitslücken erlauben Codeeinschleusung in PHP
- Wiz Research: PHP2Shell
- Sansec: Critical PHP RCE CVE-2026-109618 and CVE-2026-109619
- Tenable: php2shell FAQ
- Docker Hub: offizielles Nextcloud-Image