Erfahrungen aus einer in einer Woche durchgeführten Korrekturmaßnahme für unsere gesamte KVM-Flotte basierend auf einer Patching-Strategie, deren zentrales Ziel die Minimierung der Auswirkungen auf die Dienste unserer Kund:innen war.

Eine Schwachstelle im Subsystem der Virtualisierung

Am Dienstag, den 07. Juli, am frühen Nachmittag, wurde eine Sicherheitswarnung bezüglich CVE-2026-53359 gemeldet – eine Use-after-free-Sicherheitslücke, die das Shadow-Paging-Subsystem von x86 KVM im Linux-Kernel betrifft. Die seit mehreren Jahren bestehende Sicherheitslücke wird am 06. Juli öffentlich bekannt gegeben; Blogs anderer Cloud-Anbieter erscheinen bereits ab dem 07.

KVM ist das Virtualisierungsmodul, auf das sich die überwiegende Mehrheit der bei OVHcloud gehosteten Instanzen stützt. Der Mechanismus funktioniert wie folgt: Wenn eine externe Änderung einer Page Directory Entry (PDE) auftritt, kann der RMAP-Eintrag weiterhin auf eine bereits freigegebene Speicherseite verweisen. Der Kernel dereferenziert dann diese veraltete Seite, was zu einem Hypervisor-Crash oder – in den ungünstigsten Szenarien – zu einer Ausweitung der Rechte auf Host-Seite führen kann. Der Exploit ist reproduzierbar: Ein interner Test auf einem nicht gepatchten Host verursacht innerhalb von etwa zwei Minuten einen Absturz.

Alle Linux-x86-Kernel von vor dem Patch-Commit sind betroffen, unabhängig von der Distribution. Der offizielle Patch wird per Backporting auf unsere Debian-Kernels in der Produktion angewendet.

Es sind drei wesentliche Risiken zu beachten:

• Ein VPS-User nutzt den Exploit, um den Host abstürzen zu lassen, auf dem seine virtuelle Maschine läuft: Absturz und unkontrollierter Neustart von mehreren hundert Kunden-VMs.
• Ähnliches Szenario bei den Public-Cloud-Instanzen: Die Auswirkungen sind ähnlich, aber die Anzahl der virtuellen Maschinen pro Host ist begrenzter und die virtuellen Maschinen sind leistungsstärker und werden für sensiblere Systeme (Datenbanken, Warteschlangenmanager, Loadbalancer usw.) verwendet. Diese Systeme kommen oft in zusammengesetzten Anwendungsarchitekturen mit komplexen Abhängigkeiten zum Einsatz.
• Es besteht die Wahrscheinlichkeit der bevorstehenden Veröffentlichung eines Exploits zum Übernehmen der Kontrolle über den Host, was das Risikoniveau aufgrund der Auswirkungen auf die Vertraulichkeit von Kundendaten und die Integrität der Infrastruktur unmittelbar auf ein unannehmbares Level erhöhen würde.

Für OVHcloud reden wir hier von mehreren Zehntausend Hypervisor-Hostservern, die rund eine Million virtuelle Maschinen hosten. Die Frage ist also nicht, ob gepatcht werden muss, sondern wie man das in einer solchen Größenordnung tun kann – in dem Bewusstsein, dass dies ohne jegliche Auswirkungen auf die Kund:innen nicht möglich ist.

Die Optionen zur Risikominderung

1. Warten auf offiziell gepatchte Kernel

Diese Option hätte uns von einer Drittagenda abhängig gemacht, mit der wir für einen unklaren Zeitraum gefährdet geblieben wären. Wir haben sie angesichts des Risikos schnell verworfen.

2. Live-Patch

Das Anwenden eines Live-Patchs erfordert die Autorisierung dieser Art von Vorgang in der Kernel-Konfiguration, wodurch dessen Verhalten designbedingt on the fly geändert werden kann. Das beeinträchtigt wiederum die Härtung des Systems und damit auch die Detection im Falle einer Kompromittierung. Darüber hinaus ist das Live-Patching ein von Natur aus sensibles Verfahren, das zu einem instabilen Status auf Flottenebene führen kann. Es ist eine Option, um Zeit zu gewinnen, bis eine dauerhafte Lösung gefunden wird. Wir haben beschlossen, diesen Kompromiss nicht einzugehen, denn dieser hätte das Risiko im Falle der Veröffentlichung eines Exploits zur Übernahme der Kontrolle über den Host stark erhöht.

3. Risikominderung durch Deaktivierung der eingebetteten Virtualisierung

Durch Deaktivieren der auf den Hosts eingebetteten Virtualisierung wird der Exploit unwirksam. Wir haben jedoch keinen Einblick in die Nutzung dieser Funktion durch unsere Kund:innen und können demnach die Auswirkungen auf Kundendienste nicht einschätzen. Zudem ist diese Funktion erforderlich, um die Möglichkeit zur Live-Migration einer Instanz von einem physischen Host zu einem anderen zu wahren. Diese Option haben wir also schnell ausgeschlossen.

4. Live-Migration

Unsere vierte Option war die Live-Migration von virtuellen Maschinen von anfälligen Hosts zu leeren Hosts, die in der Zwischenzeit gepatcht wurden. Diese Option ist in Bezug auf die Servicekontinuität sehr zufriedenstellend, da die Migration ohne Auswirkungen auf die virtuellen Maschinen erfolgt, mit Ausnahme der verringerten Leistung während der Migration. Sie ist aber aufgrund des Kopierens der virtuellen Maschinen von einem Host zum anderen sehr zeitaufwendig und demnach keine realistische Alternative für die gesamte Flotte. Außerdem hätten wir damit unsere Kund:innen nicht wie gewünscht innerhalb weniger Tage schützen können, sondern hätten Monate gebraucht. Wir behalten diese Option nur für einige kritische virtuelle Maschinen in der Hinterhand, da jede Live-Migration zu einer erheblichen Verzögerung der Ausführung von Batch-Jobs führt.

5. Backporting des Patches auf unsere Kernel und Reboot aller Hosts

Letztendlich haben wir diese Option gewählt. Diese wird im weiteren Verlauf des Artikels näher erläutert.

Dienstagnachmittag: Zusammenkunft und Organisation des Krisenstabs

Unmittelbar nach Bestätigung der Sicherheitslücke hatte es oberste Priorität, eine strukturierte und koordinierte Reaktion zu erarbeiten. Die mit der ersten Analyse betrauten Analyst:innen waren sich der Tragweite der nächsten Tage schnell bewusst. Am frühen Nachmittag wird die Information intern weitergegeben. Es wurden mehrere Koordinationsbereiche geöffnet: einer für die technische Koordination, einer für die Krisenkoordination, einer für den US-Betrieb und einer für die Kundenkommunikation und den Support. Gleichzeitig bereiteten die Kernel-Teams den Patch vor und kümmerten sich um das Backporting. Der erste gepatchte Kernel stand am Abend bereit.

Am gleichen Abend wurden dann Validierungstests in einer Testumgebung durchgeführt, im Rahmen derer der Patch bestätigt wurde: Der Exploit führte nicht mehr zum Absturz der gepatchten Hypervisoren und die QA-Tests mit dem gepatchten Kernel verliefen positiv.

Der Krisenstab ging zur Überwachung des Deployments über und wurde anschließend vom NOC (Network Operations Center) geleitet, das die Rolle des operativen Koordinators übernahm – unter anderem im Hinblick auf die Überwachung des globalen Fortschritts, die Abwägung der Prioritäten zwischen Regionen und Diensten und den Gesamtüberblick. Um die Ausführung kümmerten sich die Public-Cloud- und VPS-Expert:innen, die sich den Reboots, Live-Migrationen und Anti-Affinitätsangelegenheiten annahmen. Die Trennung zwischen Koordination und Ausführung ist freiwillig: Das NOC koordiniert, die operativen Teams handeln und melden die für die Koordination erforderlichen technischen Metriken und Ereignisse.

Die Synchronisation mit dem Kunden-Support (Status des Fortschritts in Echtzeit für die Kommunikation mit betroffenen Kund:innen) und den Sicherheitsteams (Überwachung der Schwachstelle, Validierung des Umfangs und der Kriterien für das Ende des Vorgangs) war kontinuierlich sichergestellt.

Da es sich um eine Follow-the-Sun-Operation handelte, arbeitete der Krisenstab rund um die Uhr, mit einer Rotation nach geografischer Zone. Drei Sychronisationspunkte am Tag sollten die Übergänge zwischen den Zonen abdecken. Mit dabei waren immer das NOC, die operativen Expert:innen sowie das Support- und Sicherheitsteam, um den Fortschritt je nach Region zu teilen, den Staffelstab zwischen den Zonen weiterzugeben (was funktioniert hat, mit Verfahrensanpassungen auf Basis von praktischem Feedback) und die Prioritäten der nächsten Sequenz zu klären.

Der Krisenstab vereinte mit seiner 24/7-Rotation verschiedene Teams: Kernel & Virtualization (Analyse des Patchs, Backporting, Validierung), VPS und Public Cloud (Deployment), NOC (Leitung), Run & SRE (Orchestrierung, Anti-Affinität, Live-Migration), Datacenter Operations (Hardware-Arbeiten), Kunden-Support (Kundenanfragen), Sicherheit (Monitoring, Perimeter, Ende des Vorgangs) und Kommunikation (Transparenz, gezielte Benachrichtigungen).

Das vorgegebene Ziel war klar: die betroffenen Hosts so schnell wie möglich zu patchen und neu zu starten, um die Gefährdungszeit zu verkürzen, und dabei die Auswirkungen auf die Dienste zu minimieren. Die wesentliche Herausforderung war die Größenordnung: Zehntausende von Maschinen auf allen Kontinenten, wodurch eine Handhabung von Fall zu Fall unmöglich war.

Das größte Risiko in dieser Phase war eine potenzielle Ausnutzung der Sicherheitslücke, die zum Absturz des nicht gepatchten Hosts führen würde. Dier Krisenstab beschloss, den Patch vor der Neustartphase global anzuwenden. Im Falle einer Ausnutzung der Sicherheitslücke hätte der Absturz des Hosts dessen Neustart zur Folge, wodurch der Patch automatisch greift. Darüber hinaus bestand das Risiko, dass die CVE für eine böswillige Übernahme der Kontrolle über den Host ausgenutzt wird. Es gibt keinen öffentlich verfügbaren Exploit-Code, aber wir wissen, dass es nur eine Frage der Zeit ist, bis jemand es schafft, die Schwachstelle zu nutzen, um die Kontrolle über den Host zu erlangen. In Anbetracht dieses katastrophalen Szenarios wussten wir, dass jede Minute zählt.

Eine überlegte Entscheidung: einseitiges Patching mit kontrollierten Auswirkungen

Der Exekutivausschuss validierte den Go/No-Go am Abend: Die erste Region sollte am nächsten Vormittag bearbeitet werden. Für diese Anzahl an Maschinen gibt es kein Szenario ohne Auswirkungen. Ein Wartungsfenster mit jeweils allen Kund:innen einzeln verhandeln, jede Abhängigkeit überprüfen, jeden Reboot maßgeschneidert orchestrieren – so viele Schritte, die in Bezug auf das Sicherheitsrisiko nicht in einem akzeptablen Zeitrahmen miteinander vereinbar waren.

Dier Krisenstab traf also eine wohlüberlegte Entscheidung: einseitiges Patching mit kontrollierten Auswirkungen, das ohne auf die individuelle Zustimmung der Kund:innen zu warten angewendet wird, in dem Bewusstsein, dass es zu Unterbrechungen einiger Dienste kommen wird. Die Argumentation beruht auf drei Punkten:

• Nicht zu patchen würde die gesamte Flotte einem hohen Risiko aussetzen.
• Eine Einzellfallhandhabung würde die Wartezeiten verlängern und die Mehrheit der Hosts wäre über Wochen gefährdet.
• Durch schnelles und umfassendes Handeln wird der Großteil geschützt, auch wenn einige wenige temporär beeinträchtigt werden.

Die Priorität war dann nicht mehr, Auswirkungen zu vermeiden, sondern sie zu minimieren, abzuschwächen und vorhersehbar zu machen. Dieser Ansatz strukturierte den gesamten Vorgang: Follow the Sun, Priorisierung der Regionen und Anti-Affinitätsplanung.

Mittwoch, 08. Juli: Start in Sydney

Die Wahl von Sydney für das Testen der Bereitstellung war einleuchtend: Die Anzahl der Hosts ist begrenzt und der Bereitstellungszeitraum außerhalb der lokalen Geschäftszeiten (nachts) entspricht den Bürozeiten der Teams in Europa. Der Start mit der am weitesten östlich gelegenen Region ermöglichte Folgendes:

• In der am wenigsten ausgelastete Zone handeln
• Das Verfahren unter realen Bedingungen im kleineren Maßstab validieren, bevor es industrialisiert wird
• Erstes Feedback sammeln, bevor die europäischen und nordamerikanischen Regionen gestartet werden

Die ersten Patches + Reboots wurden auf VPS-Hosts in Australien angewendet. Die Region SYD2 war ohne Zwischenfälle zum frühen Nachmittag (MEZ) abgeschlossen. Die Verfahren wurden basierend auf Feedback aus der Praxis angepasst.

Unmittelbar nach der Stabilisierung des Verfahrens begann das Follow the Sun: Die Regionen übernehmen nacheinander am jeweiligen Morgen und geben die nötigen Informationen an die nächste Region weiter. Die erste europäische Welle (RBX, GRA6, WAW, DE, SBG, MIL, UK) wurde am selben Abend um 18:30 MEZ gestartet.

Zwei Bereiche mit unterschiedlicher Nutzung: zuerst VPS, danach Public Cloud

Die Bereitstellung ist nicht homogen. VPS und Public Cloud unterscheiden sich in ihrer Architektur und in ihrer Nutzung durch die Kund:innen. Die Anzahl der virtuellen Maschinen auf VPS-Hosts ist höher und viele Unternehmen und Einzelpersonen nutzen VPS für Testinfrastrukturen. Die Wahrscheinlichkeit eines Kunden-Tests des Exploit-Codes auf seiner virtuellen Maschine ist sehr hoch, genau wie die Auswirkungen in Anbetracht der Anzahl an VMs auf jedem Host.

Auf dem VPS ist der Perimeter pro Host begrenzt und die Auswirkungen auf die Kund:innen durch einen Reboot bleiben mäßig. Die Batches können schnell hintereinander geschaltet werden, wodurch bereits in den ersten 24 Stunden ein großer Teil der Flotte abgesichert werden konnte.

Bei der Public Cloud sieht die Sache anders aus. Eine Region umfasst Tausende von Kund:innen und ein Host kann kritische Instanzen beherbergen. Die wichtigsten Regionen umfassen Hunderte oder Tausende von Hosts mit komplexen virtuellen Kundeninfrastrukturen. Wir entschieden uns für folgende Priorisierung:

• Nach Größe der Region: Regionen mit geringerer Dichte werden zuerst bearbeitet, um die Robustheit des Verfahrens im größeren Maßstab zu validieren.
• Nach Anzahl der exponierten Kund:innen: Regionen mit hohem Volumen werden mit höherer Granularität – Batch für Batch – orchestriert, um das Risiko zu verringern.

Stopp-Schwellenwerte und Kontrolle des Tempos

Für jede Reboot-Welle gab es Stopp-Schwellenwerte: Überschreitet die Anzahl der gleichzeitig fehlerhaften Hosts einen bestimmten Wert, wird die Welle angehalten. Dieser Schwellenwert lag für Regionen mit hoher Dichte (GRA, RBX, BHS) bei 15 Hosts und für die anderen bei 5 Hosts. Ebenso wurde um 06:00 Uhr oder auf Anfrage des lokalen Rechenzentrums ein Anhalten ausgelöst.

Diese Maßnahme verhindert, dass eine Hardwareausfallsituation verschlimmert wird, indem weiter Hosts neu gestartet werden, die die DC-Techniker noch nicht bearbeiten konnten. So wurde auch ein gewisser Regulierungspunkt zwischen der Software-Automatisierung und der physischen Realität vor Ort eingeführt.

Nicht zwei Instanzen desselben Projekts gleichzeitig rebooten: Anti-Affinität als Schutzmechanismus

Bei einem solchen Vorgang ist das Hauptrisiko für unsere Kund:innen nicht der Reboot selbst, sondern das gleichzeitige Aussetzen mehrerer Instanzen desselben Projekts, die der Gewährleistung der Anwendungsresilienz bei anbieterseitigen Ausfällen dienen. Wenn Kund:innen ihre Workloads über mehrere Hosts verteilt haben, um eine hohe Verfügbarkeit zu gewährleisten, sollten wir nicht alle ihre Instanzen gleichzeitig rebooten. Es wurde beschlossen, über die Einhaltung der in den Kundenimplementierungen definierten Anti-Affinitätsregeln hinauszugehen.

Daher berechneten unsere Orchestrator für jedes Kundenprojekt mit Instanzen auf mehreren Hosts ein Co-Location-Graph, damit zwei Hosts mit Instanzen desselben Projekts niemals im selben Zeitfenster neu gestartet werden. So wurden sich gegenseitig ausschließende Wellen definiert und der Grundsatz übernommen, dass ein Host wieder in Betrieb sein muss, bevor der nächste in derselben Anti-Affinitätsklasse rebootet wird.

Diese Anti-Affinität wurde nach Best Effort angewendet: Sie wurde in den meisten Fällen eingehalten, konnte aber nicht zu 100 % für die gesamte Flotte garantiert werden. Das Ziel war weiterhin, die Auswirkungen zu sequenzieren, damit sie auf Anwendungsebene zu bewältigen sind. Für Kund:innen, deren Instanzen alle auf einem einzigen Host basieren, kam es zu einer punktuellen Unterbrechung, deren Zeitfenster angekündigt wurde.

Vorrangige Live-Migration von sensiblen Diensten und Workloads

Hinter jeder Kundeninstanz befinden sich Controller, APIs, Data Planes, interne Datenbanken. Ein unkontrollierter Reboot der Hosts, die diese Dienste beherbergen, würde zu Deadlocks führen: Ein nicht verfügbarer interner Dienst blockiert die Folge von Reboots, was das Patching blockiert. Zudem basieren einige OVHcloud Dienste auf virtuellen Maschinen, die auf Public-Cloud-Instanzen gehostet sind. Auch diese Abhängigkeiten müssen berücksichtigt werden, um die Auswirkungen auf Kund:innen so gering wie möglich zu halten.

Um eine solche Kettenreaktion zu vermeiden, wurde die Priorität umgekehrt: Vor jedem Neustart einer Region werden die Abhängigkeiten der internen Dienste eingehend analysiert. Bestimmte interne Dienste werden live migriert. Ihre virtuellen Maschinen werden im laufenden Betrieb auf bereits gepatchte Hosts verschoben. Dadurch bleibt die Abhängigkeitskette erhalten und der ursprüngliche Host kann anschließend für den Reboot freigegeben werden.

Dieser Prozess ist langwierig und erfordert erhebliche Hardware- und Personalressourcen. Daher musste die Anzahl der auf diese Weise zu migrierenden VMs beschränkt werden, damit die Migration innerhalb des vorgesehenen Zeitrahmens abgeschlossen werden kann.

Einige Workloads erfordern besondere Aufmerksamkeit, insbesondere Cloud Databases (DBaaS) Dienste, der interne Data Lake und Observability-Funktionen. Hier wurde immer nur eine VM nach der anderen migriert, ohne mehr als eine Maschine gleichzeitig abzuschalten, und die Aktualisierung ihrer Hosts so lange wie möglich hinausgezögert. Durch diese schrittweise Migration konnten kaskadierende Ausfälle der Dienste verhindert und sichergestellt werden, dass die für den Betrieb erforderlichen Tools verfügbar bleiben.

Technische Probleme und Anpassungen während der Durchführung

Ein Vorgang dieser Größenordnung läuft nicht ohne Zwischenfälle ab. Während der Kampagne wurden mehrere technische Probleme festgestellt und behoben.

VMs starten nach Host-Reboot nicht neu

Der erste größere Zwischenfall trat bereits während der ersten europäischen Welle auf: Einige virtuelle Maschinen starteten nach dem Reboot ihres Hypervisors nicht neu. Nova Compute meldete „Instance shutdown by itself“ ohne Synchronisierung. Die Ursache wurde am zweiten Tag identifiziert: Der libvirt-guests-Dienst geriet mit Nova Compute in Konflikt und stoppte die Instanzen beim Reboot ohne API-seitige Sync. Als Lösung wurde libvirt-guests.service vor dem Reboot auf den Hosts deaktiviert und maskiert. Ab diesem Fix funktionierten die automatischen Neustarts der VMs.

Datenkorruption bei synchronen Diensten

Am Abend des zweiten Tages meldete das interne Monitoring-System beschädigte Daten auf mehreren VMs in 3 Clustern. Als wahrscheinliche Ursache wurde ein erzwungener Reboot während laufender Festplatten-Schreibvorgänge identifiziert. Daraufhin wurde die Zeit für einen Graceful Shutdown vor einem erzwungenen Kill auf 60 Sekunden verlängert, damit ausstehende Schreibvorgänge abgeschlossen werden können. Zusätzlich wurde ein Skript zum automatischen Neustarten nach wie vor abgeschalteter VMs implementiert.

API-Deadlock in Paris

In der Nacht vom zweiten auf den dritten Tag gerieten die Nova- und Neutron-APIs in Paris in einen gegenseitigen Deadlock. Die auf 10 Prozesse begrenzte Neutron-API wurde durch eine hohe Anzahl von Nova-Anfragen überlastet und gab rund zwei Stunden lang HTTP-503-Fehler zurück. Der Fix bestand darin, die Anzahl der Neutron-Worker von 10 auf 30 und die Anzahl der Apache-Prozesse von 10 auf 32 zu erhöhen. Die B-Zonen in Paris und Mailand wurden für die Dauer der Stabilisierung zurückgestellt.

Überlastung des Supports in BHS

Am Standort BHS in Kanada erreichte der API-Traffic das Zehnfache des üblichen Spitzenwerts und führte zu einer Überlastung des Managers und des Supports. Einige Kund:innen bemerkten die Auswirkungen, bevor sie über die Situation informiert werden konnten. Dieser Fall zeigt sehr anschaulich, wie sich innerhalb der Infrastruktur Kettenreaktionen entwickeln können.

Alle aufgetretenen Bugs und Probleme wurden im Rahmen der Operationen bearbeitet. Gleichzeitig werden die gewonnenen Erkenntnisse berücksichtigt, um geeignete und nachhaltige Verbesserungen umzusetzen.

Reboots und Hardware-Interventionen

Der Reboot von mehreren Zehntausend Maschinen bringt auch eine Hardware-Komponente mit sich. Bei jedem Server-Reboot besteht ein inhärentes Ausfallrisiko. Während der ersten Nacht kamen etwa 20 bis 30 von 6.000 Hosts nicht selbstständig wieder online. Die Ursachen waren unter anderem defekte Speichermodule, BIOS-Konfigurationen oder inaktive Netzwerkschnittstellen. In den USA mussten bei mehreren Hosts die CMOS-Batterie entfernt und ein Power-Drain durchgeführt werden, bevor sie wieder eingeschaltet werden konnten – ein wiederkehrendes Hardware-Fehlerbild.

An jedem Standort wurden während der Kampagne Datacenter-Techniker als Verstärkung mobilisiert. Ihre Rolle:

• Sofortige Intervention bei Hosts, deren Reboot von den Orchestratorn als fehlgeschlagen gemeldet wird
• Austausch defekter Teile (Festplatten, RAM-Module, Netzteile)
• Durchführung physischer Maßnahmen, die nicht automatisiert werden können: Hard Reboot, Kontrolle der Status-LEDs und Eingriffe direkt am Rack

Die Datacenter-Techniker bearbeiteten fehlgeschlagene Hosts nach einer priorisierten Interventionslogik. Die Priorisierung erfolgte in Abstimmung mit den Run-/SRE-Teams und richtete sich nach den Kundenauswirkungen des jeweiligen Hosts. Ein Host mit kritischen Instanzen, der nach dem Reboot nicht wieder verfügbar ist, wird gegenüber einem ungenutzten Host bevorzugt behandelt. Durch diese kombinierte Priorisierung auf Software- und Hardware-Ebene konnte sichergestellt werden, dass der Vorgang nicht ins Stocken gerät.

Kommunikation und Support: betroffene Kund:innen informieren

Ein einseitiges Patching mit kontrollierten Auswirkungen setzt einen entsprechend abgestimmten Kommunikationsaufwand voraus.

Gezielte und schrittweise Kommunikation

Angesichts der „Follow-the-Sun“-Dynamik wäre eine globale und undifferenzierte Kommunikation nicht zielführend gewesen. Daher wurde eine gezielte, progressive Kommunikationsstrategie umgesetzt. Benachrichtigt wurden ausschließlich Kunden, deren Instanzen auf Hosts betrieben werden, die für einen Reboot eingeplant waren. Die Benachrichtigungen wurden parallel zum Fortschritt des Vorgangs ausgelöst – Region für Region und Welle für Welle.

Zu Beginn wurde entschieden, keine öffentliche Statusseite zu aktivieren, um die Abfolge des Deployments nicht offenzulegen. Die Kommunikation erfolgte stattdessen über gezielte Mitteilungen über unser Support-Portal. Kund:innen mit einem Business oder Enterprise Support-Level erhielten entsprechende E-Mails.

Feststellung: einige Nachrichten wurden nicht zugestellt

Die Kommunikationstools haben technische Grenzen. In Regionen mit besonders hohem Volumen wie GRA6 – wo fast 90.000 Kund:innen nicht direkt kontaktiert wurden – wurde auf den massenhaften Versand von E-Mails verzichtet, um eine Flut zusätzlicher Support-Tickets zu vermeiden.

Basierend auf dieser Erkenntnis wurde am zweiten Tag die Strategie angepasst: Im Manager wurde über ein Feature Flipping ein bedingtes Banner implementiert. Ist der angemeldete User in der Liste der betroffenen Kunden-Accounts (NICs) enthalten, wird ihm eine entsprechende Informationsmeldung angezeigt. Die Entwicklung wurde noch am selben Tag durchgeführt, das Banner am dritten Tag ausgerollt. Gleichzeitig wurde eine Public-Cloud-Statusseite eingerichtet.

Trotz dieser Maßnahmen erreichten einige Nachrichten ihre Empfänger:innen nicht, z. B. aufgrund veralteter Kontaktadressen, gefilterter Benachrichtigungen oder einer zeitlichen Verschiebung zwischen dem geplanten Reboot und dem Versand der Nachricht. Einige Kund:innen bemerkten die Auswirkungen, ohne zuvor darüber informiert worden zu sein. Diese Problempunkte wurden nach Abschluss des ursprünglichen Mitigationsplans als prioritäre Verbesserungsbereiche identifiziert.

Der Support als letzte Rettung

Für Kund:innen, die nicht informiert worden waren oder weitere Informationen benötigten, wurde der Kunden-Support verstärkt und gezielt vorbereitet: durch ein Briefing zum Hintergrund der Vorgangs, Echtzeitzugriff auf den Fortschritt nach Region und Host sowie eine beschleunigte Bearbeitung der mit der Kampagne verbundenen Tickets über einen eigenen Prozess.

Der Support fängt das auf, was die automatisierten Benachrichtigungen nicht abdecken konnten. Er ersetzt die Kommunikation nicht, sondern kompensiert einige ihrer Mängel.

Zeitlicher Ablauf des Vorgangs

Ausblick

Die CVE-2026-53359 stellte ein Risiko für unsere Kund:innen und unsere Infrastruktur dar. Der daraufhin eingeleitete Maßnahmenplan zur Risikominderung hatte Auswirkungen auf die Kund:innen. Sie waren zwar begrenzt, sequenziert und angekündigt, aber dennoch real. Eine detailliertere Kommunikation während der Umsetzung des Maßnahmenplans, solange die Infrastruktur noch nicht vollständig gepatcht war, hätte das Risiko für unsere Kund:innen deutlich erhöht, da dies einige von ihnen hätte dazu verleiten können, den öffentlich verfügbaren Exploit selbst zu testen.

Der Reboot einer globalen Maschinenflotte dieser Größenordnung ohne jegliche Auswirkungen war kein erreichbares Ziel. Unser Ziel bestand daher darin, die geringstmöglichen Auswirkungen zu erreichen, die mit der Sicherheit der gesamten Flotte vereinbar waren.

Das Patchen und anschließende Rebooten sämtlicher Public-Cloud- und VPS-Hosts in einem derart engen Zeitfenster war zuvor noch nie durchgeführt worden. Dieses Notfallverfahren wurde aufgrund des mit der Schwachstelle verbundenen Risikos eingeführt. Frühere Fälle waren stets über schrittweise Reboots abgearbeitet worden, wobei die natürliche Rotation der virtuellen Maschinen innerhalb der Infrastruktur genutzt und durch über einen längeren Zeitraum geplante Ad-hoc-Live-Migrationen ergänzt wurde.

Gemessen an der Größe des Vorhabens haben die beteiligten Teams den Vorgang mit einer sehr überschaubaren Anzahl an Ausfällen und Kundenauswirkungen durchgeführt. Gleichzeitig ist uns bewusst, dass in den kommenden Monaten weitere Kernel-Schwachstellen veröffentlicht werden könnten. Damit steht fest, dass dieses Notfallverfahren möglicherweise erneut zum Einsatz kommen muss. Beim nächsten Mal müssen wir besser vorbereitet sein – sowohl bei der Begrenzung der direkten Auswirkungen der Reboots als auch bei der frühzeitigen Information unserer Kund:innen und bei der Begleitung betroffener Kund:innen während der Prozesse. Deshalb werden wir in den kommenden Tagen und Wochen die wesentlichen Auswirkungen bei Kund:innen untersuchen, die von komplexeren Ausfällen betroffen waren. Zudem werden wir die während des Vorgangs intern aufgetretenen Probleme im Rahmen von Post-Mortems analysieren, um unsere Verfahren für die Zukunft weiter zu verbessern.