Wie wir am 21. Oktober 2026 eine kritische Schwachstelle in der PHP-Sprache neutralisiert haben.
Teil 1 unserer Serie über Sicherheit und Souveränität in der politischen IT.
02:07 Uhr. Die Alarmglocken schrillen
Die Meldung erreicht unser Infrastruktur-Team in den frühen Morgenstunden: Das PHP-Projekt kündigt für den Folgenachmittag einen außerplanmäßigen Notfall-Patch an. Grund sind zwei Sicherheitslücken mit höchster Kritikalitätsstufe (CVE-2026-109618 & CVE-2026-109619), die Remote Code Execution (RCE) ermöglichen – das heißt Angriffe aus dem Netzwerk, ohne dass eine Authentifizierung erforderlich ist. Die Lücke wird später unter dem Namen PHP2Shell bekannt.
Ein Mitarbeiter schlägt im verdigado-Chat Alarm:
„🚨 Patches für zwei kritische PHP RCE CVEs werden heute (21.10) um 16:00 deutscher Zeit released!“
Die Situation ist ernst: Da PHP das Fundament für einen Großteil des modernen Webs und auch für viele unserer betreuten Infrastrukturen bildet, ist die Angriffsfläche enorm. Das Tückische: Die Lücke steckt nicht in einer Anwendung, die man flickt. Sie sitzt eine Ebene tiefer, in der Sprache selbst, im Fundament, auf dem alle Anwendungen stehen. Ein Angreifer braucht keinen Zugang oder eine Lücke in den Anwendungen – er braucht nur das Fundament PHP. Politische Organisationen sind aufgrund ihrer Sichtbarkeit oft bevorzugte Ziele für solche Angriffe.
Vor uns liegt nun ein riskantes Zeitfenster von 14 Stunden
bis zum offiziellen Release des Sicherheitspatches.
08:00 Schnelle Reaktion und erste Schutzmaßnahmen
Unsere Technik-Teams analysieren im Eiltempo die verfügbaren Informationen. Da Details zur Lücke bereits im Netz kursieren, ist die Gefahr einer aktiven Ausnutzung groß. In der IT-Sicherheit gilt: Wenn der finale Patch noch nicht verfügbar ist, müssen temporäre Schutzmaßnahmen (Mitigations) implementiert werden.
Wir identifizieren eine mögliche Einstellung in der php.ini (session.upload_progress.enabled = Off), die den Angriffsweg erschweren kann. Über unser zentrales Konfigurationsmanagement rollen wir diese Änderung automatisiert über unsere gesamte Flotte aus: von WordPress-Instanzen über Redaktionssysteme bis hin zu internen Cloud-Diensten.
Kurz darauf melden die PHP-Entwickler, dass diese spezifische Lösung nicht in allen Fällen zuverlässig schützt. Wir behalten die Einstellung dennoch bei – nach dem Prinzip der „Defense in Depth“: Jede zusätzliche Hürde für einen Angreifer ist ein Gewinn, solange sie die Funktion der Systeme nicht beeinträchtigt.
09:00 Uhr. Risikoanalyse und technische Grenzen
Parallel prüfen wir weitreichendere Optionen. Ein Read-Only-Zustand der Server oder eine zusätzliche Härtung der Dateisysteme werden diskutiert, erweisen sich jedoch in der Praxis als zu instabil oder unzureichend.
„Beide CVEs sind noch nicht im Debian Security Tracker. 😮“
Wir stellen fest: Es gibt keine saubere Teillösung. Die Wahl liegt zwischen einer unsicheren temporären Mitigation oder der vollständigen Deaktivierung der betroffenen Dienste. Erschwerend kommt hinzu, dass die offiziellen CVE-Datenbanken (wie der Debian Security Tracker) zu diesem Zeitpunkt noch keine Einträge führen. Wer sich blind auf automatisierte Update-Tracker verlässt, würde hier zu spät reagieren.
10:37 Uhr. Die Entscheidung: Safety first
Die Empfehlungen des EU-CERT und der Fachpresse bestätigen unsere Analyse: Die Mitigation reicht nicht aus, eine Isolation der Systeme wird empfohlen.
„Ich schlage vor, dass wir alle PHP Dienste abschalten, bis Fixes für CVE-2026-109618 & CVE-2026-109619 existieren. Das ist aktuell die Empfehlung von Heise und EU-CERT. Das betrifft alle WordPress, TYPO3, Nextclouds, Passbolt, Drupal.“
Wir stehen vor einer klassischen Abwägung: Akzeptieren wir das Risiko einer Systemübernahme, während wir auf den Patch warten, oder nehmen wir einen kurzzeitigen Ausfall der Dienste in Kauf? Wir entscheiden uns für die sicherste Variante: Die betroffenen PHP-Dienste werden heruntergefahren, bis verifizierte Fixes vorliegen. Denn: Ein kontrollierter Offline-Zustand ist definitiv besser als ein kompromittiertes System.
11:00 Uhr. Zeit gewinnen, statt nur ausschalten.
Ein Totalausfall ist für viele Nutzer*innen problematisch. Im Hintergrund braucht immer jemand dringend ein Dokument aus einer Cloud, weil beispielsweise eine Frist abläuft, und eine Geschäftsstelle muss akut weiterarbeiten.
Wir verfeinern daher die Strategie: Statt eines harten „Aus“ reduzieren wir die Angriffsfläche schrittweise.
- Zugriffsbeschränkung: Wir beschränken den Zugriff auf bekannte, vertrauenswürdige Quellen.
- Wartungsmodus: Alle anderen Nutzer sehen eine Wartungsseite.
- VPN/Verschlüsselung: Für dringende administrative Aufgaben halten wir gesicherte Zugänge offen.
- Geoblocking: Wir implementieren einen Filter für Anfragen aus dem Ausland, um die Masse der automatisierten Scans effektiv zu reduzieren.
Diese Maßnahmen sind handwerkliche Kompromisse, die wir intern offen diskutieren und abwägen. Das Ziel ist es, die Verfügbarkeit für kritische Prozesse zu erhalten, ohne die Sicherheit zu gefährden.
„Jetzt haben wir uns erst mal Zeit verschafft, die Lage in Ruhe zu bewerten.“
12:30 Uhr. Das Rennen.
Ab der Mittagszeit beobachten wir die Paket-Repositories sehr genau. Woher kommt der PHP-Fix zuerst?
„Mal sehen, ob Sury oder das Debian-Sicherheitsteam schneller sind.“
In der PHP-Welt ist das Sury-Repository eine anerkannte Institution, die oft schneller reagiert als die offiziellen Distributionen. Wir bereiten die Update-Pipelines vor, um sofort reagieren zu können, sobald der Fix verfügbar ist. Alle sind gespannt, ob Sury oder das Debian-Sicherheitsteam schneller sind.
15:45 Uhr. Der Fix ist da!
Sury gewinnt das Rennen. Kurz nach Ablauf des üblichen Embargos tauchen die korrigierten PHP-Versionen dort auf. Eine davon, 8.4.27, löst die Version ab, die bis eben verwundbar war.
Jetzt geht alles schnell: Updates werden ausgerollt, Dienst für Dienst wieder angefahren.
Dabei sind wir transparent: Das war kein einfacher Knopfdruck.
Um bloß nichts zu übersehen, läuft ein großflächiges Update über die gesamte Infrastruktur – und erwischt dabei auch Dienste, die mit PHP gar nichts zu tun haben. Für ein paar Minuten ist das Ticketsystem weg, dann ruckelt es beim Videokonferenz-Dienst.
Die Techniker*innen jagen den Nachwirkungen einzeln nach, bis alles wieder steht. Sicherheit unter Zeitdruck über viele Systeme hinweg ist Handarbeit, mit Umwegen und Nachbessern. Jeder, der so etwas schon gemacht hat, kennt dieses letzte, zähe Stück.
16:19 Uhr. Sicherheitslücke geschlossen
Kurz nach 16 Uhr wird der Vorfall im Monitoring auf gelöst gesetzt. Ein, zwei Dienste brauchen noch etwas, bis sie wieder regulär ihren Dienst tun. Am frühen Abend läuft alles wieder — auf gepatchten Versionen, kontrolliert hochgefahren. Von der ersten Meldung um 02:07 bis hierher vergingen vierzehn Stunden unter Hochdruck für die Daten- und Systemsicherheit.
Unser Fazit: Der Vorteil echter IT-Souveränität
Der Punkt an dieser Geschichte ist nicht allein, dass wir schnell reagiert haben.
Es geht auch darum, dass wir in jedem Moment selbst entscheiden konnten — und das Wissen dafür im eigenen Haus hatten. Wir konnten sehen, welche Systeme betroffen sind. Wir konnten abschalten, ohne einen externen Anbieter um Erlaubnis zu fragen oder auf dessen Reaktionszeit zu warten. Wir konnten auf eigene Verantwortung vorsichtig sein und früh patchen – in unserem Zeitplan und mit Werkzeugen, die wir kennen und beherrschen. Niemand musste erst jemanden beauftragen und hoffen, dass der rechtzeitig reagiert.
Die volle Kontrolle über die Systeme ermöglichte es uns, unsere gesamten Kapazitäten direkt und ohne Umwege dort einzusetzen, wo sie benötigt wurden.
Genau das meinen wir mit digitaler Souveränität. Nicht, dass nie etwas passiert — denn das kann niemand seriös zusagen. Sondern dass man im Ernstfall die nötige Kontrolle und Kompetenz hat, selbst zu handeln – statt zusehen zu müssen, wie andere für einen entscheiden.
Insbesondere für Organisationen, deren Daten ein begehrtes Angriffsziel sind, ist digitale Souveränität kein Luxus. Sie ist die Voraussetzung, um bei Krisen überhaupt handlungsfähig zu bleiben.