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.

Image: Screenshot of the PHP News Archive webpage on 21-Oct-2026 about a critical vulnerability allowing Remote Code Execution if exploited even before any application code runs.

“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.

Image: Screenshot of an E-mail from my hoster, stating that my Nextcloud instance has been deactivated until a patch is available and in place.

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.

Image: A flatscreen showing a 'no entry' symbol, connected to multiple small boxes that look like mini servers. Image caption says 'Requested page locked'.

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

Image: Screenshot of my hoster's notification feed for the PHP vulnerabilities in question. There are multiple entries at different points in time, all dated 21-Oct-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?

  1. Nicht nur der Service als Ganzes ist angreifbar sondern auch seine Komponenten. –> Kenne alle Komponenten und achte auf Schwachstellen und Patches!
  2. 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#

  1. Sensible Daten wenn möglich aus dem Netz nehmen. Gedankengang: Was wäre, wenn das weg kommt? Reicht Verfügbarkeit im LAN/Intranet?
  2. Besseres Monitoring und Abuse detection sind nur konsequent: Früh erkennen, früh sperren, früh melden, früh abschalten, sofort patchen.
  3. 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.