Patch-Frist: Nicht der Patchday startet die Uhr, sondern der Exploit

Die Frage lautet nicht ob, sondern wie schnell

Ob man Sicherheitsupdates einspielt, wird in keinem Betrieb ernsthaft diskutiert. Diskutiert wird etwas anderes, meistens am Telefon und in zwei Sätzen: Kann das bis zum nächsten Wartungsfenster warten? Der Server läuft, die Leute arbeiten, ein Neustart am Dienstagvormittag ist teuer.

Beantwortet wird diese Frage fast überall nach Gefühl. Dabei gibt es aus dem Sommer 2026 einen Fall, der sie mit Datumsangaben beantwortet: Vier Wochen passierte nichts, dann ging es in Stunden. Die Antwort ist unbequemer, als sie klingt.

Eine Zeitachse, kein Einzelfall

Die Abfolge im Fall der SharePoint-Schwachstelle CVE-2026-55040 ist lückenlos dokumentiert:

• 14. Juli 2026: Microsoft veröffentlicht das Update, das die Lücke schließt.
• Die folgenden vier Wochen: keine beobachteten Angriffe. Wer in dieser Zeit nachgesehen hat, fand nichts.
• 11. August 2026: Der Sicherheitsdienstleister Rapid7 veröffentlicht eine technische Analyse der Lücke, einschließlich eines lauffähigen Demonstrationscodes — im Fachjargon ein Exploit, also ein fertiges Stück Software, das die Lücke nachweislich ausnutzt.
• Innerhalb von Stunden danach: die ersten Angriffe auf ungepatchte Server.
• 18. August 2026: Die US-Behörde CISA nimmt die Lücke in ihren Katalog nachweislich ausgenutzter Schwachstellen auf.

Der letzte Punkt ist der, der am häufigsten falsch gelesen wird. Der Katalogeintrag war nicht der Startschuss, sondern die Nachricht vom bereits Geschehenen. Die Angriffswelle lief zu diesem Zeitpunkt eine Woche.

Die Lücke selbst — eine Anmeldeprüfung in selbst betriebenen SharePoint-Servern, die sich umgehen lässt — haben wir ausführlich beschrieben, samt der Merkwürdigkeit, dass die Herstellerseite zu diesem Zeitpunkt noch entwarnte; der Beitrag trägt den Titel SharePoint: Anmeldung ohne Passwort – und die Herstellerseite meldet am 28. August 2026 „nicht ausgenutzt". Hier geht es nicht um die Lücke. Hier geht es um die Abstände zwischen diesen fünf Daten.

Warum der Patchtag der falsche Startpunkt ist

Ein Patch verrät, wo die Schwachstelle sitzt. Die Arbeit, daraus einen zuverlässig funktionierenden Angriff zu bauen, bleibt aber beim Angreifer, und sie kostet Können und Zeit. Genau das erklärt die vier ruhigen Wochen: Die Information war öffentlich, die Fertigkeit nicht.

Am 11. August 2026 hat sich diese Hürde aufgelöst. Von dem Moment an, in dem eine ausgearbeitete Anleitung samt Beispielcode öffentlich steht, braucht ein Angriff kein Spezialwissen mehr, sondern nur noch eine Liste erreichbarer Server. Deshalb dauerte es Stunden und nicht wieder vier Wochen.

Damit steht die eigentliche Lehre: Der Zeitdruck hängt nicht am Patch-Datum, sondern an dem Tag, an dem der Exploit öffentlich wird — an dem also öffentlich steht, wie die Lücke auszunutzen ist. Dieser Tag ist nicht vorhersehbar. Er kann eine Woche nach dem Update kommen, vier Wochen danach, oder nie.

Die vier ruhigen Wochen waren kein Befund, sondern eine Frist

Stellen Sie sich einen Blick auf die Lage am 20. Juli 2026 vor. Update verfügbar, keine Angriffe bekannt, Herstellerseite unauffällig. Alles daran war richtig — und die Schlussfolgerung „dann hat das Zeit" trotzdem falsch.

Die vier Wochen waren keine Aussage über die Gefahr. Sie waren schlicht die Zeit, die man hatte, und man erfährt ihre Länge erst hinterher. Wer sie genutzt hat, war am 11. August 2026 fertig. Wer den Patch für den September vorgesehen hatte, stand am 12. August 2026 mit einem aus dem Internet erreichbaren, angreifbaren Server da.

Warum „wir warten, bis es ausgenutzt wird" nicht funktioniert

In unserem Beitrag „Patchday-Reihenfolge: Warum die 7,0 vor der 9,8 kommt" haben wir beschrieben, dass der Ausnutzungsstatus die Reihenfolge bestimmen sollte und nicht die Punktzahl der Bewertung: Was nachweislich angegriffen wird, kommt zuerst. Das bleibt richtig.

Für den Zeitpunkt taugt derselbe Status jedoch nicht, und der Grund steht oben in der Zeitachse. Ein Katalogeintrag ist eine Rückmeldung. Er entsteht, weil jemand Angriffe beobachtet und ausgewertet hat, und das braucht Tage. Wer sein Patchen daran ausrichtet, kommt strukturell zu spät — nicht aus Nachlässigkeit, sondern weil die Information erst existiert, wenn das Ereignis vorbei ist, auf das man reagieren wollte.

Es geht auch andersherum

Ein zweiter Fall aus demselben Sommer zeigt, dass der Auslöser nicht immer eine Veröffentlichung ist. In der VoIP-Telefonanlage Sangoma Switchvox schloss der Hersteller am 14. Juli 2026 eine Lücke. Angriffe wurden ab dem 30. August 2026 beobachtet — sechs Wochen später. Die technische Analyse dazu erschien am 1. September 2026, also nach den Angriffen.

Hier lief es in umgekehrter Reihenfolge, und das Ergebnis ist dasselbe: Der Abstand zwischen Patch und Angriff ist nicht planbar. Er betrug einmal vier Wochen und einmal sechs, und beide Male hätte nur der geholfen, der nicht auf ein Signal gewartet hat.

Die Regel, die ohne Sicherheitsabteilung funktioniert

Aus beiden Fällen folgt eine Frist, die man sich merken kann und die kein Werkzeug voraussetzt:

• Alles, was aus dem Internet erreichbar ist, wird innerhalb von zwei Wochen aktualisiert — unabhängig von der Punktzahl, unabhängig davon, ob schon jemand angreift.
• Alles andere läuft im normalen Monatsrhythmus, mit Testlauf und festem Wartungsfenster.

Die zwei Wochen sind kein Naturgesetz, und wir behaupten nicht, dass sie immer reichen. Sie sind der Abstand, der zu den beobachteten Verläufen passt: Im SharePoint-Fall lagen vier Wochen zwischen Update und Angriff, im Telefonanlagen-Fall sechs. In beiden Fällen wäre eine Zwei-Wochen-Frist rechtzeitig gewesen — mit Reserve für den Fall, dass es einmal schneller geht.

Der Gewinn liegt darin, dass diese Regel keine Lagebeurteilung verlangt. Niemand muss täglich Meldungen lesen oder einschätzen, ob eine Lücke „die gefährliche" ist. Es zählt nur eine Eigenschaft des Systems, und die ändert sich selten.

Die Voraussetzung, an der es meistens scheitert

Beide Fristen setzen dasselbe voraus: Sie müssen wissen, welche Ihrer Systeme von außen erreichbar sind. Genau diese Liste existiert in vielen Betrieben nicht, und wenn man sie erstellt, ist sie fast immer länger als erwartet.

Typische Funde: ein Fernwartungszugang, den ein Dienstleister irgendwann freigeschaltet hat, die Weboberfläche einer Anlage, die niemand als Server wahrnimmt, ein Testsystem, das produktiv wurde, ohne dass jemand die Firewall-Regel zurücknahm.

Zur Liste gehört eine zweite Spalte, die oft schwerer zu füllen ist als die erste: Wer aktualisiert das? Bei Geräten, die ein externer Dienstleister betreut, ist diese Frage in vielen Verträgen schlicht nicht geregelt. Ungeklärte Zuständigkeit führt zuverlässig zu ungepatchten Systemen, und sie fällt erst auf, wenn es zu spät ist.

Unsere Einschätzung

Beide Fälle sind datiert, dokumentiert und mit einem Update zu erledigen. Was bleibt, ist der Denkfehler dahinter: Ruhe nach einem Patch wird als Entwarnung gelesen, obwohl sie nur die Vorlaufzeit ist, die man gerade verbraucht. Und der öffentliche Startschuss, der diese Ruhe beendet, kommt ohne Vorwarnung — im SharePoint-Fall an einem gewöhnlichen Dienstag im August.

Deshalb ist eine feste Frist die praktikablere Antwort als jede Einzelfallbewertung: zwei Wochen für alles, was von außen erreichbar ist, der Rest im Monatsrhythmus. Das ist weniger Aufwand als tägliche Lagebeobachtung und deutlich mehr Schutz als ein Quartalsfenster.

Wenn bei Ihnen unklar ist, welche Systeme aus dem Internet erreichbar sind und wer für deren Updates zuständig ist, sehen wir uns das gemeinsam an — Bestandsaufnahme, eine belastbare Frist und eine klare Zuordnung, wer sie einhält.