PHP2Shell: Gepatcht ohne Nachtschicht

Am 21. Oktober 2026 um 16 Uhr deutscher Zeit hat das PHP-Team Notfall-Updates für zwei kritische Lücken veröffentlicht. In den Stunden danach waren in Deutschland auffällig viele Websites nicht erreichbar. Städte, Kliniken, Hochschulen, Behörden und Unternehmen nahmen ihre Webserver vorsorglich vom Netz, weil sie nicht schnell genug patchen konnten oder nicht sicher wussten, wo überall PHP läuft.

Bei SecureVibe ging kein System offline. Am Ende waren alle 44 betroffenen Systeme gepatcht und getestet: 15 Nextcloud-Instanzen, WordPress-Seiten, CRM, Zeiterfassung, TYPO3, ein Wiki und weitere PHP-Anwendungen. Die Arbeit hat unser KI-Kollege nordnung gemacht, über sechs Proxmox-Server, 133 LXC- und 243 Docker-Container und jede Installationsart hinweg. Wir Menschen haben rund zwei Stunden investiert, für Regeln, Freigaben und Entscheidungen. Durchgearbeitet hat in dieser Nacht niemand von uns.

Spannend ist dabei nicht das Tempo allein, sondern die Kombination: ein Agent, der über alle Ebenen der Infrastruktur hinweg arbeitet und dabei an jeder Stelle kontrolliert bleibt. Genau das ist für uns autonomer IT-Betrieb.

Die Lücke in zwei Sätzen

PHP2Shell sind zwei Lücken im PHP-Kern (CVE-2026-109618 und CVE-2026-109619), beide mit CVSS 9.2 als kritisch eingestuft. Ein Angreifer braucht weder ein Konto noch eine Aktion des Nutzers, und betroffen ist praktisch alles, was PHP über das Web ausliefert: WordPress, Nextcloud, CRM-Systeme, Wikis. Behoben ist die Lücke in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das BSI hat mit Warnstufe Orange gewarnt.

PHP läuft auf rund 70 % aller Websites mit bekannter Serversprache. Wie verbreitet PHP ist, zeigt auch das BSI: Nach den Patches veröffentlichten sogar Hersteller von Netzwerkkomponenten eigene Hinweise, weil PHP in ihren Produkten steckt.

Teil 1: Systemübergreifend

Patchen heißt in einer echten Umgebung nicht „ein Update einspielen“. Bei SecureVibe betreiben wir sechs Proxmox-Server mit 133 LXC-Containern, in denen 243 Docker-Container laufen. Dort steckt alles, was sich über Jahre ansammelt: PHP direkt aus Debian, Ubuntu oder einer Fremdquelle, Docker-Anwendungen innerhalb der Container, eigene Builds auf offiziellen PHP-Images und einige Altsysteme ohne Herstellerunterstützung.

nordnung hat das in einem durchgehenden Lauf abgedeckt:

• Recherche: die Hinweise des PHP-Teams, der Distributionen und von Sicherheitsforschern ausgewertet und die betroffenen Versionen je Paketquelle bestimmt
• Bestand: alle sechs Server, 133 LXC-Container und die 243 Docker-Container darin aufgenommen, jeweils mit der tatsächlich laufenden PHP-Version
• Abgleich: Paketquellen und Docker-Registries direkt abgefragt, ob es schon einen offiziellen Fix gibt
• Umsetzung: je Installationsart der richtige Weg, ob Distributionspaket, neues Hersteller-Image, Nextcloud-Update oder Neubau auf gepatchtem Basis-Image
• Nachlauf: Wartelisten geführt, nachgesehen, sobald Debian und die Image-Hersteller nachgezogen hatten, und weitergepatcht, bis alle 44 Systeme durch waren
• Bericht: jedes geprüfte System, jeder Snapshot, jedes Testergebnis, dazu eine Liste aller Systeme, die unabhängig von PHP Updates brauchen

Zum Zeitverlauf: Sobald die Debian-Pakete am frühen Abend bereitstanden, lief der Einsatz an. Noch am selben Abend, vor Mitternacht, waren alle 44 Systeme gepatcht. Bei Anwendungen, deren Hersteller noch kein eigenes Update hatte, haben wir bewusst nicht gewartet: Wir haben das System darunter selbst aktualisiert, abgesichert durch Snapshot und Funktionstest.

Dabei hat nordnung auch gefunden, was ein reiner Versionsscanner übersieht:

• Gepatcht, aber nicht aktiv. In mehreren Containern hatte das automatische Update die sichere PHP-Version installiert, Apache lief aber weiter mit der alten Bibliothek im Speicher. Im Paketstand sicher, im Betrieb offen.
• Updates, die nie ankommen. In drei Containern war der Signaturschlüssel einer PHP-Paketquelle abgelaufen. Aus dieser Quelle kamen dort keine Updates mehr an, auch keine Sicherheitsupdates.
• PHP im Image. Bei Docker hilft kein Update im Betriebssystem. Entscheidend ist, welche PHP-Version im Image steckt und ob der Hersteller es schon neu gebaut hat.

Teil 2: Kontrolliert

Einen Agenten auf 133 produktive LXC-Container mit 243 Docker-Containern loszulassen, geht nur, wenn die Kontrolle nicht von seinem guten Willen abhängt. Bei nordnung stehen die Leitplanken im System, nicht in einer Anweisung.

Erst lesen, dann handeln. In der Analysephase hatte nordnung technisch nur Leserechte. Es konnte nachsehen, aber nichts verändern. Erst nach der vollständigen Bestandsaufnahme ging es an die Umsetzung.

Freigabe vor jeder Wirkung. Jeder verändernde Schritt lief über eine Freigabe, festgehalten mit Urheber und Zeitpunkt. Die rund zwei Stunden, die wir investiert haben, waren genau das: Freigaben erteilen und Entscheidungen treffen.

Vier Augen, auch bei der KI. Ein zweiter KI-Prüfer hat die Schritte kontrolliert, bevor sie ausgeführt wurden. Wie beim Vier-Augen-Prinzip unter Menschen prüft nicht derselbe, der arbeitet.

Alles im Protokoll. Jeder Aufruf ist protokolliert und für ein Audit abrufbar. Wer später wissen will, was in einem bestimmten Container um 19:42 Uhr passiert ist, findet es.

Rückweg vor jedem Eingriff. Vor jeder Änderung hat nordnung einen Snapshot angelegt, und nach jedem Update hat es geprüft, ob die Anwendung genauso antwortet wie vorher. Bei einer Nextcloud-Instanz hat das große Versionsupdate eine Zusatzkomponente deaktiviert. Das stand im Bericht, zusammen mit dem Hinweis, wie man sie wieder aktiviert.

Grenzen, die eingehalten werden. Auf den Servern selbst wurden keine Pakete installiert und keine Updates eingespielt. Wo nordnung an eine Grenze kam, hat es angehalten:

• Eine Umstellung der Docker-Installation in einem Container hat es erst nach ausdrücklicher Freigabe gemacht.
• Als der Nextcloud-App-Store unsere IP-Adresse gedrosselt hat, hat es keinen Umweg gesucht. Es hat gemeldet, welche Netzwerkregel wir anpassen müssen, und gewartet.

Gute Bremsen machen ein Auto nicht langsamer. Sie sind der Grund, warum man schnell fahren kann. Ohne diese Kontrollen hätten wir nordnung nie so weit laufen lassen.

Was hätte das von Hand gekostet?

Das ist unsere Schätzung für einen erfahrenen Admin. Gemessen ist sie nicht, denn wir haben es ja nicht von Hand gemacht.

Mit nordnung lag der Aufwand von Menschen bei rund zwei Stunden. Am Ende stand nicht nur ein gepatchter Bestand, sondern ein vollständiger, prüfbarer Nachweis.

Wichtiger als die gesparten Stunden: Erst mit nordnung konnten wir im laufenden Betrieb patchen. Von Hand hätten wir die Systeme nicht schnell genug geschafft und sie bis zum Patch offline nehmen müssen, so wie viele andere an diesem Abend. Mit nordnung blieb alles online.

Offline nehmen ist sicher. Aber dann steht das Geschäft.

Viele Organisationen hatten am 21. Oktober praktisch nur zwei Möglichkeiten: mit erheblichem Risiko weiterlaufen oder abschalten. Abschalten war oft richtig, aber es kostet. Shops nehmen keine Bestellungen an, Kunden kommen nicht an ihre Anwendungen, Bürgerinnen und Bürger nicht an digitale Dienste.

Dazu kommt: Die Zeit zwischen Update und Angriff wird kürzer. Die Angriffswege für PHP2Shell wurden mit KI-Unterstützung gefunden. Was Forscher mit KI in einer Woche schaffen, schaffen Angreifer bald auch. Wenn die Angreifer KI nutzen, braucht die Verteidigung sie auch. Wir meinen damit nicht einen Scanner mehr, der Lücken meldet, sondern einen Kollegen, der sie behebt.

Für eure Systeme: die Kurz-Checkliste

1. PHP überall finden, auch in Docker-Containern: docker exec <container> php -v.
2. Version abgleichen: 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder das gepatchte Paket eurer Distribution.
3. Vorher sichern, nachher Apache bzw. PHP-FPM neu starten und mit needrestart gegenprüfen.
4. Funktion testen: Login, Startseite, ein typischer Ablauf.
5. Paketquellen prüfen: Abgelaufene Schlüssel stoppen Updates, ohne dass es auffällt.
6. Was nicht gepatcht werden kann, abschotten und die Migration planen.

Fazit

PHP2Shell war kein schwieriger Patch. Schwierig war die Breite: viele Systeme, viele Installationsarten, an jeder Stelle ein Detail. Ein KI-Kollege, der über all diese Ebenen hinweg arbeitet, nimmt euch diese Breite ab. Dass wir ihn dabei laufen lassen konnten, lag an der Kontrolle: nur lesend in der Analyse, Freigabe vor jeder Wirkung, ein zweiter Prüfer und ein lückenloses Protokoll.

Autonomer IT-Betrieb heißt für uns nicht, die Kontrolle abzugeben. Es heißt, sie dorthin zu legen, wo sie wirkt.

Wie lange hat PHP2Shell euch beschäftigt? Lasst uns ansehen, welche Arbeit in eurem IT-Betrieb so ablaufen könnte: Kostenlose Ticketanalyse anfragen · Demo vereinbaren

Lukas Schwenkau ist CEO der SecureVibe IT Solutions GmbH.

Quellen

• BSI, Cybersicherheitswarnung „PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit“, Version 1.2 vom 22.10.2026
• heise online, 22.10.2026, „php2shell: Updates trudeln ein, viele Webseiten offline, Angriffe laufen“
• iX/heise, 26.10.2026, „PHP2Shell: The grace period is over“
• W3Techs, Nutzung von PHP, Stand November 2026

Lukas SchwenkauCEO @ SecureVibe IT Solutions GmbH