PHP2shell: Kritische Sicherheitslücken

Schallbert — Wed, 21 Oct 2026

Schritt 1 Erkennen: Wir haben ein Problem.

TLDR: PHP hat ganz aktuell zwei kritische Schwachstellen, die Remote Code Execution ermöglichen. Ihre IDs: CVE-2026-109618 und CVE-2026-109619. Da ihre Ursachen nicht im Frontend sondern in der Engine stecken, hilft nur ein Update auf PHP 8.5.12, 8.4.27, 8.3.36, oder 8.2.35.

“PHP nutze ich nicht auf meiner Website”, denke ich, als ich heute Vormittag die folgende Nachricht erhalte:

“Hi, kurzer Hinweis: Gegebenenfalls […] alles was php nutzt, erstmal abklemmen, […] Patch kommt später heute.”

Oder bin ich doch betroffen…? Immerhin nutze ich eine managed Nextcloud-Instanz, und Nextcloud ist doch u.A. in PHP geschrieben…? Während ich diese Zeilen schreibe, wird ein Fix für Nextcloud verfügbar. Alles muss also sehr schnell gehen. Heute werden unter Garantie viele Überstunden gemacht.

Status 21.10.2026, 10:30 MESZ

Spulen wir zehn Stunden zurück. Es gibt noch keinen Fix. Die Information über die CVEs wurde geleakt und ist jetzt selbst bereits ein paar Stunden alt. Laut Wikipedia nutzen 69% aller Websites PHP. Das Ausnutzen einer so hochkritischen Lücke (Score 9.2) bei einer derart weitverbreiteten Technologie hat erwartbar massive Auswirkungen. Entsprechend nervös ist “das Internet”.

“[…] organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified. CERT-EU, pulled 21.10.2026, 10:40

Interessant, die Empfehlung ist also ernsthaft “erstmal vom Netz nehmen”.

Schritt 2 Sofortmaßnahmen: Nextcloud vom Netz trennen

Um einem möglichen Angriff zuvor zu kommen versuche ich folglich, meine Instanz vom Netz zu nehmen. Dafür logge ich mich bei meinem Hoster ein, wechsle auf das Tab “Einstellungen”, und klicke auf den Reiter ownCloud Console. Dies ist Nextclouds command-line interface.

Dort muss ich feststellen, dass kein Befehl zum Abschalten oder de-publishing zur Verfügung steht. Also wähle ich den Nächstbesten:

occ maintenance:mode --on

Ich versetze meine Instanz also in den Wartungsmodus. Dies verhindert neue Logins und friert die Datenbank ein. Anschließend lese ich mich ein wenig in die CVEs ein um herauszufinden, ob mein Schritt genügt.

Tut er wohl nicht.

In verschiedenen Foren und auf HackerNews erfahre ich, dass eine nicht authentisierte Anfrage bereits den Angriff auslösen kann, bevor überhaupt PHP-Code auf der Serverseite ausgeführt wird.

Es ist also egal, in welchen Zustand ich meine Instanz versetze - solange sie am Netz ist, bleibt sie angreifbar.

Schritt 3 Vorläufige Eindämmung: Nextcloud-Instanz deaktivieren lassen

Ich finde auch mit Hilfe diverser Online-Suchanfragen keinen Weg, meine mangaged-Instanz abzuschalten. Ich überlege kurz, die Namensauflösung und das DNS-Routing zu killen. Mir wird aber schnell klar: Bis sich das durchpropagiert, ist der Fix längst draußen.

Status 21.10.2026 11:43 MESZ

Ich schreibe also ein Support-Ticket an meinen Hoster mit der Bitte um Hilfe beim Herunternehmen meiner Instanz.

Status 21.10.2026 12:01 MESZ

Ich erhalte eine Mail vom Hoster!

Tatsache, ich kann die Instanz nicht mehr erreichen und erhalte eine ERR_CERT_COMMON_NAME_INVALID-Meldung. Klicke ich diese weg, erscheint REQUESTED PAGE LOCKED. Gute Arbeit. Die Reaktionszeit meines Anbieters inlusive Rückmeldung an den Kunden betrug 18min.

Nun wechsle ich den Modus vom Akteur zum Beobachter. Ich sehe erste Exploit-Versuche (oder zumindest Beteuerungen davon) im Web und muss an eine Folie eines Vortrages denken (Zeitstempel 11:24), den ich vor kurzem gesehen habe: Security in the LLM age.

Dort zeigt ein Linux-Kernel Sachverständiger, dass wir in 2026 im Schnitt sieben Tage vor einem Patch in betroffener Software bereits Exploits in freier Wildbahn sehen.

discover --> disclose --> patch --> deploy

Diese traditionelle Ereigniskette funktioniert nur bei “langsamen” Angreifern gut. Wir benötigen etwas, um wieder vor die Lage zu kommen.

Schritt 4 Beobachten der Situation: Verfügbarkeit des Patches, Einspielen erster Betreiber

Laut Hackernews wird der Patch um etwa 16:00 MESZ verfügbar. Ich besorge mir den RSS-Feed meines Hosters und warte auf Meldung.

Status 21.10.2026 14:20 MESZ

Auch das Bundesamt für Sicherheit in der Informationstechnik hat einen BSI-IT-Sicherheitshinweis herausgegeben, wo mit der “Kritikalität 3/Orange” vor der Lücke gewarnt und folgendes angemerkt wird:

“Der Patch für die Schwachstelle ist heute 16 Uhr deutscher Zeit (14:00 UTC) angekündigt und sollte unverzüglich zu diesem Zeitpunkt installiert werden.” - BSI, 21.10.2026

Status 21.10.2026 16:34 MESZ

Mein Hoster meldet, dass die Patches nun verfügbar seien und mit der Implementierung begonnen würde. Betroffen sind nicht nur die Nextcloud-Instanzen, sondern auch seine komplette Administrationsoberfläche sowie sein Webmailer.

Status 21.10.2026 19:52 MESZ

Mein Hoster meldet Vollzug für die von ihm betriebenen Webhosting-Angebote und Managed Servers.

Status 21.10.2026 22:40 MESZ

Die Hetzner-Anwendung KonsoleH, über die ich meine Nextcloud-Instanz verwalte, ist down.

Status 21.10.2026 23:00 MESZ

KonsoleH ist wieder live (und gepatcht).

Schritt 5 Erkenntnis und Schlussfolgerung

Was lerne ich aus den Ereignissen dieses turbulenten Tages? Wie gehe ich in Zukunft mit Sicherheitslücken um? Und wie erkenne ich überhaupt, dass ein Problem vorliegt?

Nicht nur der Service als Ganzes ist angreifbar sondern auch seine Komponenten. –> Kenne alle Komponenten und achte auf Schwachstellen und Patches!
Die Gegenspieler sind (durch LLMs) unglaublich schnell geworden. –> Rechne mit Exploit vor Patch-Verfügbarkeit!

Eine Liste geeigneter Quellen für Verwundbarkeiten, Neuigkeiten und Patches stelle ich mir gerade zusammen. Sobald die Liste stabil ist, werde ich darüber berichten.

Schritt 6 Aktionen

Sensible Daten wenn möglich aus dem Netz nehmen. Gedankengang: Was wäre, wenn das weg kommt? Reicht Verfügbarkeit im LAN/Intranet?
Besseres Monitoring und Abuse detection sind nur konsequent: Früh erkennen, früh sperren, früh melden, früh abschalten, sofort patchen.
Standardbezugsquellen für Informationen zu verwendeter Software besorgen. CVE-List-Scanner bauen? HackerNews-Filter?

Nachtrag: 22.10.2026 09:30 MESZ

Der Hoster hat meine Nextcloud-Instanz gepatcht und wieder online genommen. Alle Systeme normal. Es gibt nun auch einen Wikipedia-Eintrag zum Thema, der sehr aktuell gehalten wird.

Schritt 7 Erste Reflektion

Nun sind ein paar Tage ins Land gegangen, seitdem die beiden Sicherheitslücken öffentlichkeiswirksam bekanntgemacht und Patches bereitgestellt wurden. Werfen wir mal einen Blick in die Netzlandschaft.

Status 24.10.2026 16:30 MESZ

Es gibt inzwischen viele, viele Machbarkeitsnachweise (PoC, Proof of Concept) für und über die Ausnutzung der PHP-Sicherheitslücken, allem voran auf der Plattform Github.

Ich selbst bin leider auf dem Themenfeld nicht sachkundig und muss mich auf die Einschätzung anderer verlassen, was Qualität dieser PoCs angeht, wie die es um die Ausnutzbarkeit in der freien Wildbahn wirklich bestellt ist und was die Hintergründe dazu betrifft, dass ausgerechnet diese Lücke medial so starke Resonanz zu erfahren scheint.

Im Allgemeinen gilt selbstverständlich “Erst patchen, dann nachfragen”. So habe ich es ja auch gemacht. Wenn ich noch einmal Felix von Leitner zitieren darf:

“Eine der Lektionen aus 20 Jahren Arbeit im Security-Umfeld ist, dass wenn einer behauptet, es gibt einen Bug, und der andere behauptet, der sei aber nicht exploitbar, dass sich dann im Nachhinein so gut wie immer raustellt, dass der doch exploitbar war.” - Feliks von Leitner aka Fefe, 12.April 2014, abgerufen am 24.10.2026

Zur Ausnutzbarkeit schreibt die sich selbst als Bedrohungsaufklärungsseite “Threat intelligence” bezeichnende flare.io, dass die meisten PoCs für PHP2shell nur in der Laborumgebung funktionierten. Auf echte Ziele seien sie kaum anwendbar - endweder, weil Betriebsinterna über die angegriffene Systeme erforderlich seien, weil sie andere Schwachstellen wie die Abschaltung von Speicherrandomisierung voraussetzen, oder weil die PoCs selbst “AI-Slop” darstellten: schlecht oder kaum validierte, mieserabel geschriebene Software, die mehr verspreche als sie halte.

Ähnlich äußert sich eliastaylor:

“There isn’t an easy exploit for this PHP vulnerability.” - https://eliastaylor.com/noexploit/, abgerufen am 24.10.2026

Sein Argument ist knapp zehn Stunden nach Veröffentlichung von Angriffsvektor und Patch, dass

keiner der Exploit-PoCs funktioniert, nicht einmal bei einer Standardinstallation und -Konfiguration von Pre-Patch-PHP
die beiden CVEs weit weniger kritisch sind als andere Sicherheitslücken der Geschichte (Heartbleed bei Open SSL wird exemplarisch genannt)
die Exploits alle nicht von echten Leuten handgeschrieben, sondern mit Hilfe von LLMs generiert seien

Der Kern der Argumentation geht dahin, dass Leute ihre Denkarbeit an Sprachmodelle abgäben und selbst gar nicht mehr prüften, ob das System tut was es sagt; geschweige denn den vom System geschriebenen Code läsen, verstünden und verbesserten. Bösartige Botnets würden noch immer von Menschen handgeschrieben, und das brauche seine Zeit, wenn die Lücken nicht offensichtlich und trivial auszunutzen seien.

Als kleine Übung für eine eigene Einschätzung der Lage empfehle ich die Lektüre der “Issue”-Diskussionen, die bei vielen PHP2Shell-PoCs auf Github öffentlich bereitstehen.

Das Große Medienecho hat aber auch etwas Gutes: Die Welt patcht anscheinend schnell. Ich habe mir die Resonanz auf diversen Foren, deutschen und internationalen, überflogen: Überall treiben Menschen ihre Hoster mit Patches vor sich her, diskutieren miteinander die Auswirkungen und welche betroffenen Anbieter bereits Updates herausgebacht haben.

Bleibt die Frage offen, wem das Ganze nützt. Ich habe schon ein paar Vermutungen. Für Schlussfolgerungen und meine Urteilsbildung ist es allderings noch zu früh.

Status 27.10.2026 17:00 MESZ

Die Sicherheitslücke gilt offiziell bestätigt als ausgenutzt.

Schritt 8 Beobachtungen analysieren und Informationskanäle justieren

Ich lege den Fokus nun auf Berichte zur Ausnutzung der Sicherheitslücken. Die Menge an POCs ist für Einzelpersonen unüberschaubar geworden. Erste Privatpersonen und Firmen wie Cloudflare haben begonnen, ein Capture The Flag auszuloben: Sie stellen absichtlich angreifbare PHP-Instanzen online und fordern auf, sie zu knacken und dies zu beweisen.

Ein sehr kluger Schritt, um die Spreu vom Weizen zu trennen. Auf diese Weise müssen die Leute ihre POCs gegen Sparringspartner ins Feld führen, die ihren Stack nicht offenlegen. Als zusätzliche Schwierigkeit fordern einige Anbieter auf, dass vorher außerdem andere ihrer Standard-Abwehrmechanismen wie Web Application Firewalls überwunden werden müssen. Schafft es ein POC hindurch, kann er als als unter realistischen Bedingungen durchgeführte Schwachstellenausnutzung gelten.

Den POC verstehen

Ich habe (dank an eliastaylor) den POC gefunden, welcher die “StealMyBitcoin” PHP2Shell-CTF gelöst hat. Interessant sind sowohl die Kommentare in der Python-Datei über den Mechanismus des Exploits als auch die Diskussion auf Github zu Modellvariante, Prompt und Konfiguration des verwendeten LLM.

Ich verstehe die Quellen und Kommentare rund um diesen POC so, dass er die Probleme der vorigen Versuche elegant löst:

PHP beim Multipart-Upload effektiv in die Speicherklemme bringen: Anstatt tausende Anfragen in kürzester Zeit zu senden (und zu hoffen, dass er den “richtigen” Worker-Thread trifft), verwendet diese Attacke “deeply nested field names”¹, welche die Payload gering, jedoch den Speicheraufwand mit nur einer Anfrage serverseitig explodieren lassen.

Dies geht gegen die Lücke CVE-2026-109618 “out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid”. Ziel des heap_consumer ist es nun, die herumliegenden, durch den Speicherüberlauf abgelaufene Daten zu manipulieren.

ASLR, randomisiertes Ablegen im Speicher umgehen: Anstatt ASLR im Feld zu ignorieren (oder in der Laborumgebung schlicht abzuschalten) müssen Speicherüberlauf, Manipulation und erneute Anfrage zum Einlesen der manipulierten Daten zwingend in derselben Session und auf demselben, überlasteten Worker geschehen². Ansonsten ist der betroffene Speicherbereich kaum wiederzufinden und wird irgendwann durch das System, welches den gestoppten Worker entdeckt, zurückgesetzt. Daher muss der Exploit den Schadcode bereits platziert haben, wenn PHP den zugehörigen Destruktor aufruft und damit schließlich die RCE ausführt.

Dies geht dann gegen die Zweite CVE im Bunde: CVE-2026-109619 “request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.”

Wäre jetzt cool hierzu mal eine PHP-Engine-Sachverständige zu hören :)

Damit steht auch der dunklen Seite in der Breite ein Exploit zur Verfügung, der bei “einfachen Zielen” ohne Härtung eine (automatisierte) Ausnutzung machbar erscheinen lässt.

Härtung

Lösen kann das Problem nur der Patch. Folgende Härtungsmaßnahmen können gegen diesen speziellen Angriffsvektor zumindest den Widerstand erhöhen:

Das Kommando PHP_SESSION_UPLOAD_PROGRESS, durch den der Angriff durchgeführt wird, gar nicht erst anbieten oder aber keine Anfragen in sehr kurzer Abfolge, in derselben Session, oder von derselben Maschine zulassen.
Die Anzahl Worker auf Maximum drehen, auch wenn dies auf die Leistung der Maschine geht. Dies macht das Wiedereinfangen und Ausnutzen desjenigen Workers schwieriger, welcher zuvor korrumpiert wurde.

Später am selben Tag

The Hacker News bestätigt die Ausnutzung und zählt betroffene Firmen bzw. Großkonzerne und Lieferanten auf. Der Tenor: Patchen, patchen, patchen!

Status 28.10.2026 21:30 MESZ

Cloudflare hat inzwischen neue Firewall-Regeln für ihre WAF veröffentlicht, die Angreifende schon vor Erreichen der Zielserver abfangen soll. Hackernews berichtet über konkrete Vorfälle mit ersten Schäden. Threat intelligence Firmen bestätigen dies.

Zum Abrunden des Status hier noch eine nette Sammlungsseite mit Informationen über x-2-shell-Schwachstellen.

Nextcloud on Schallberts Blog