Dustin Childs von Trend Micros Zero Day Initiative eröffnete seine Analyse des Juli-Patchdays mit einem Satz, den man von einem der nüchternsten Beobachter der Branche so nicht erwartet hätte: „The bug apocalypse has fully descended upon us." Die Zahl dahinter: 621 neue Microsoft-CVEs in einem einzigen Monat — der mit Abstand größte Patch Tuesday der Firmengeschichte. Dazu kommen rund 480 weitere Fixes in Chromium und Edge, die in dieser Zahl noch gar nicht enthalten sind.
Wer im Juli einen Windows-Fuhrpark, eine SharePoint-Farm oder Oracle-Produkte betreibt, hat den Effekt direkt gespürt: Das Patch-Backlog wächst schneller, als das Team es abarbeiten kann. Dieser Artikel erklärt, warum das kein vorübergehender Ausreißer ist, warum das klassische „alles innerhalb von 30 Tagen"-Modell rechnerisch nicht mehr aufgeht — und wie ein risikobasiertes Patch-Management aussieht, das mit diesen Volumina umgehen kann.
Der Juli 2026 in Zahlen: Warum ZDI von „Bug-Apokalypse" spricht
Die nackten Fakten des Monats, jeweils aus den offiziellen Advisories und den Analysen von ZDI, Tenable und Qualys:
- 621 Microsoft-CVEs am Juli-Patchday (14. Juli) — Rekord. 63 davon als „Critical" eingestuft, zwei Zero-Days unter aktiver Ausnutzung, eine Lücke vorab öffentlich bekannt.
- Oracle CPU vom 21. Juli: 1449 Sicherheitsupdates für 1235 einzelne CVEs über 32 Produktfamilien — ebenfalls die größte Critical-Patch-Update-Runde aller Zeiten. 18 % der Patches kritisch, 52,7 % hoch. Allein E-Business Suite: 410 Patches, Fusion Middleware: 355.
- Halbjahresbilanz: Die Microsoft-CVE-Zahl des ersten Halbjahres 2026 übertrifft laut ZDI bereits jedes komplette Vorjahr.
- Jahresprognose: Das FIRST-Konsortium (Betreiber des EPSS) hat seine Februar-Prognose von rund 59.400 CVEs für 2026 im Juni auf rund 66.000 angehoben — die tatsächlichen Veröffentlichungen lagen 46 % über der ursprünglichen Schätzung. 2026 wird das erste Jahr mit mehr als 50.000 veröffentlichten CVEs.
Der Treiber ist kein Geheimnis: Microsoft selbst hat seine Kunden am 9. Juli darauf vorbereitet, dass KI-gestützte Schwachstellensuche künftig dauerhaft höhere Patch-Volumina produziert. Was Microsofts interne Tools finden, finden vergleichbare Werkzeuge auch bei Oracle, in Open-Source-Projekten und — das ist die unbequeme Seite — bei Angreifern. Die Juli-Zahlen sind keine Anomalie, sie sind die neue Grundlast.
Die kritischen Lücken im Detail
Im Juli-Paket stecken mehrere Lücken, die für typische Mittelstands-Infrastrukturen unmittelbar relevant sind:
- AD FS (CVE-2026-56155): Privilegien-Eskalation in Active Directory Federation Services, aktiv ausgenutzt, im CISA-KEV-Katalog mit Behörden-Frist 28. Juli.
- SharePoint (CVE-2026-56164): Fehlende Authentifizierung an einer kritischen Funktion, aktiv ausgenutzt, KEV-Frist 17. Juli. Dazu das Paar CVE-2026-50522 / CVE-2026-58644: zwei unauthentifizierte Deserialisierungs-RCEs, beide CVSS 9.8.
- RDP (CVE-2026-56190): Unauthentifizierte Remote Code Execution im RDP-Server, CVSS 9.8 — die gefährlichste Sorte Lücke für jeden, der RDP auch nur intern breit einsetzt.
- Hyper-V: Use-after-free mit VM-Escape-Potenzial — ein Angreifer mit niedrigen Rechten in einer VM kann auf den Host durchgreifen. Für jeden Virtualisierungsbetreiber ein Pflicht-Patch der ersten Stunde.
Das Wichtigste in einem Satz: Bei 621 CVEs in einem Monat ist nicht mehr die Frage, ob Sie alles patchen — das schaffen Sie nicht —, sondern ob Sie die zwei aktiv ausgenutzten und die vier bis fünf wirklich kritischen Lücken innerhalb von 24 bis 72 Stunden von den 600 anderen unterscheiden können. Wer diese Unterscheidung nicht systematisch trifft, patcht entweder zu langsam das Falsche oder gar nichts.
Warum „alles sofort patchen" rechnerisch nicht mehr aufgeht
Das klassische Modell im Mittelstand sieht so aus: Am Patchday werden alle Updates in WSUS oder ein Nachfolgewerkzeug übernommen, eine Woche auf einer Handvoll Testsysteme beobachtet, dann flächig ausgerollt. Bei 80 bis 120 CVEs pro Monat hat das funktioniert. Bei 600+ funktioniert es aus drei Gründen nicht mehr:
- Bewertungsaufwand: Selbst wenn die Triage pro CVE nur zwei Minuten kostet (Betroffenheit prüfen, Kritikalität einordnen), sind 621 CVEs über 20 Personenstunden — pro Monat, nur für Microsoft, ohne Oracle, VMware, Linux, Netzwerk-Appliances und die 480 Browser-Fixes.
- Wartungsfenster: Reboots von Domain Controllern, Datenbank- und ERP-Servern brauchen abgestimmte Fenster. Die Zahl der Fenster wächst nicht mit — nachts und am Wochenende ist die Zeit endlich, und jedes Fenster hat ein Regressionsrisiko.
- Exploit-Geschwindigkeit: Die Zeit zwischen Patch-Veröffentlichung und aktiver Ausnutzung liegt bei attraktiven Lücken (Exchange, SharePoint, Firewalls, VPN-Gateways) inzwischen bei Stunden bis wenigen Tagen. Ein 30-Tage-Zyklus für alles bedeutet: Für die fünf Lücken, die zählen, sind Sie 28 Tage zu langsam — und für die 600, die nie ausgenutzt werden, unnötig schnell.
Die Gegenposition muss man fairerweise nennen: „Einfach alles automatisch und sofort" ist theoretisch die sicherste Strategie — wenn man die Betriebsrisiken ignoriert. In der Praxis hat jeder Admin schon einen Patchday erlebt, der Druckdienste, Authentifizierung oder eine Fachanwendung zerlegt hat. Der April 2026 war so ein Fall: Die RDP-Trust-Verschärfung hat flächig „Unbekannter Herausgeber"-Warnungen ausgelöst und Helpdesks tagelang beschäftigt — wir haben das im Artikel zum April-Patchday und der RDP-Signaturpflicht im Detail beschrieben. Ungetestetes Sofort-Patchen tauscht ein Sicherheitsrisiko gegen ein Verfügbarkeitsrisiko. Die Antwort ist nicht „schneller alles", sondern „schneller das Richtige".
Priorisierung: CVSS allein reicht nicht — KEV und EPSS im Vergleich
Die meisten KMU priorisieren heute — wenn überhaupt — nach CVSS-Score: alles ab 9.0 zuerst, dann abwärts. Das Problem: CVSS misst die theoretische Schwere einer Lücke, nicht die Wahrscheinlichkeit, dass sie jemand ausnutzt. Von den zehntausenden CVEs eines Jahres wird historisch nur ein einstelliger Prozentsatz jemals in freier Wildbahn angegriffen — die FIRST-Daten zeigen zudem, dass dieser Anteil trotz explodierender Gesamtzahlen weitgehend konstant bleibt. Wer stur nach CVSS arbeitet, verbrennt Kapazität auf hunderten „kritischen" Lücken, die nie ein Angreifer anfasst, während eine „mittlere" Lücke mit öffentlichem Exploit-Kit offen bleibt.
Dafür gibt es zwei ergänzende, kostenlose Datenquellen: den KEV-Katalog der US-Cybersicherheitsbehörde CISA (Known Exploited Vulnerabilities — Stand Juli 2026 rund 1.266 Einträge, ausschließlich nachweislich aktiv ausgenutzte Lücken) und den EPSS-Score von FIRST (Exploit Prediction Scoring System — eine täglich aktualisierte, datengetriebene Wahrscheinlichkeit zwischen 0 und 1, dass eine CVE in den nächsten 30 Tagen ausgenutzt wird).
| CVSS | EPSS | CISA KEV | |
|---|---|---|---|
| Misst | Theoretische Schwere (0–10) | Ausnutzungswahrscheinlichkeit in 30 Tagen (0–1) | Nachgewiesene aktive Ausnutzung (ja/nein) |
| Quelle | Hersteller / NVD | FIRST, ML-Modell, täglich aktualisiert | CISA, kuratiert, mit Fix-Fristen |
| Umfang | Praktisch jede CVE | Praktisch jede CVE | ~1.266 Einträge (07/2026) |
| Stärke | Vergleichbarkeit, überall verfügbar | Sortiert 600 CVEs in Minuten nach echtem Risiko | Null Fehlalarme — Ausnutzung ist belegt |
| Schwäche | Ignoriert Ausnutzungsrealität; zu viele 9.8er | Wahrscheinlichkeit, kein Beweis; Kontext fehlt | Reaktiv — Eintrag kommt erst nach Ausnutzungsbeginn |
| Rolle in der Praxis | Zweitkriterium (Schadenshöhe) | Erstkriterium für die Masse | Sofort-Patch-Liste, keine Diskussion |
In der Praxis kombiniert man die drei: KEV-Eintrag = sofort patchen, unabhängig vom Score. EPSS über ~0,1 (10 %) plus CVSS hoch/kritisch = diese Woche. Der Rest wandert in den regulären Monatszyklus. Auf den Juli angewandt heißt das: Von 621 CVEs bleiben zwei KEV-Einträge (AD FS, SharePoint) plus eine Handvoll 9.8er mit hohem EPSS für die 72-Stunden-Spur — der Rest ist planbare Routinearbeit. Aus einem unlösbaren Problem wird ein sortierbares.
Exposition schlägt Score: Das Asset-Kriterium
Scores beschreiben die Lücke — aber nicht Ihr System. Dieselbe SharePoint-RCE ist auf einem aus dem Internet erreichbaren Server ein Notfall und auf einer rein internen, per Firewall segmentierten Instanz ein dringlicher, aber planbarer Fall. Risikobasiertes Patchen heißt deshalb immer: Score × Exposition × Kritikalität des Systems. Dazu brauchen Sie drei Dinge, die unbequemerweise vor jedem Tooling kommen:
- Ein aktuelles Asset-Inventar: Welche Systeme existieren, welche Software läuft darauf, wer ist verantwortlich? Ohne Inventar können Sie die Frage „sind wir betroffen?" für keine einzige CVE seriös beantworten.
- Expositions-Klassen: Internet-exponiert (Webserver, VPN-Gateway, Mailserver, RDP-Zugänge, Firewall-Management) / intern erreichbar / isoliert. Internet-exponierte Systeme sind die Einstiegspunkte für Ransomware-Gruppen und werden binnen Stunden nach Exploit-Veröffentlichung gescannt — sie bekommen immer die kürzeste Frist.
- Geschäftskritikalität: Domain Controller, ERP, Produktionssteuerung, Backup-Infrastruktur — Systeme, deren Kompromittierung den Betrieb stoppt, rangieren vor Komfortsystemen.
In der Praxis: Die häufigste Lücke, die wir bei Erstaufnahmen sehen, ist nicht ein fehlender Patch, sondern ein fehlendes Inventar. Die zweithäufigste: Internet-Exposition, von der niemand mehr wusste — der alte RDP-Zugang „für den Dienstleister", das vergessene Test-Portal. Ein Schwachstellenscanner plus externe Angriffsflächenprüfung deckt beides in wenigen Tagen auf. Erst danach lohnt die Diskussion über Scores.
Patch-SLAs: Die Matrix nach Systemklasse
Damit Priorisierung nicht bei jedem Patchday neu ausdiskutiert wird, gehört sie in feste Patch-SLAs: verbindliche Fristen je Kombination aus Risikostufe und Systemklasse, inklusive definierter Wartungsfenster. Eine bewährte Matrix für mittelständische Umgebungen:
| Risikostufe | Internet-exponiert | Intern kritisch (DC, ERP, Backup) | Intern Standard |
|---|---|---|---|
| KEV / aktiv ausgenutzt | 24 h, notfalls außerhalb des Fensters | 72 h, Notfall-Fenster | 7 Tage |
| Kritisch + EPSS ≥ 0,1 | 72 h | 7 Tage | 14 Tage |
| Kritisch, EPSS niedrig | 7 Tage | 14 Tage | 30 Tage |
| Hoch | 14 Tage | 30 Tage | 30 Tage |
| Mittel / Niedrig | 30 Tage | Nächster Regelzyklus | Nächster Regelzyklus |
Zwei Anmerkungen dazu. Erstens: Die 24-Stunden-Zeile funktioniert nur, wenn vorab geklärt ist, wer außerhalb der Geschäftszeiten patchen darf und wer den Geschäftsleitungs-Anruf für ein ungeplantes Wartungsfenster führt — sonst ist die Frist Papier. Zweitens: Wo ein Patch kurzfristig nicht möglich ist (Herstellerfreigabe der Fachanwendung fehlt, Produktionsanlage), braucht es eine dokumentierte kompensierende Maßnahme — Netzsegmentierung, Abschalten des Dienstes, virtuelles Patchen an der Firewall — plus ein Ablaufdatum für die Ausnahme. Eine unbefristete Ausnahmeliste ist nur ein anderes Wort für Schatten-Backlog.
Test-Ringe: Schnell patchen, ohne blind zu fliegen
Der klassische Einwand gegen kurze Fristen lautet: „Wir müssen erst testen." Richtig — aber Testen und Geschwindigkeit schließen sich nicht aus, wenn man in Ringen ausrollt statt in einem Big Bang:
- Ring 0 (Tag 0–1): IT-eigene Systeme und dedizierte Testmaschinen, die die Produktions-Softwarelandschaft repräsentieren. Hier fallen Bluescreens, Treiber- und Agentenkonflikte auf, bevor sie Anwender treffen.
- Ring 1 (Tag 2–5): 5–10 % der Clients und unkritische Server, quer durch Abteilungen und Hardware-Generationen. Monitoring auf Eventlog-Fehler, Dienstabstürze, Login-Zeiten.
- Ring 2 (ab Tag 5–7): Breiter Rollout auf die Fläche, kritische Server in geplanten Fenstern zum Schluss — mit getestetem Rollback-Stand (Snapshot, Backup) für den Fall der Fälle.
Wichtig: KEV-Lücken auf exponierten Systemen überspringen die Ringe. Ein aktiv angegriffener SharePoint wartet nicht auf Ring 2 — dort ist das Restrisiko eines Patch-Fehlers kleiner als das sichere Risiko der offenen Lücke. Genau diese Ausnahme gehört explizit ins SLA-Dokument, damit sie im Ernstfall niemand erst genehmigen lassen muss. Werkzeugseitig bilden moderne Plattformen wie Intune/Autopatch, Azure Update Manager oder Drittanbieter Ringe nativ ab — welcher WSUS-Nachfolger für welche Umgebung passt, haben wir im Beitrag „Was kommt nach WSUS?" verglichen.
Windows Server 2025 Hotpatching: Weniger Reboots — inzwischen ohne Aufpreis
Das Wartungsfenster-Problem entschärft Microsoft für Windows Server 2025 mit Hotpatching: Sicherheitsupdates werden in den laufenden Prozess-Speicher eingespielt, ohne Neustart. Statt zwölf Reboot-Patchdays pro Jahr bleiben vier sogenannte Baseline-Monate (Januar, April, Juli, Oktober) mit klassischem kumulativem Update samt Neustart — bis zu acht Monate dazwischen laufen rebootfrei.
Zur Kostenfrage hat sich 2026 Wesentliches geändert: Gestartet war Hotpatching für Server außerhalb von Azure im Juli 2025 als kostenpflichtiges Abo für 1,50 US-Dollar pro CPU-Kern und Monat. Seit Mitte Mai 2026 bietet Microsoft es für Azure-Arc-verbundene Maschinen mit Windows Server 2025 Standard oder Datacenter ohne Zusatzkosten an — auch on-premises und in Fremd-Clouds. Der Haken ist kein Preis mehr, sondern eine Abhängigkeit: Die Server müssen per Azure Arc mit Microsofts Cloud-Management verbunden sein, was Governance- und Datenschutzfragen aufwirft, die man vorher klären sollte. Und: Hotpatching ersetzt die Priorisierung nicht — es verkleinert nur den Reboot-Engpass. Nicht jedes Update ist hotpatch-fähig, ältere Server-Versionen bleiben außen vor, und Applikations-Patches (Oracle, Fachanwendungen) betrifft es gar nicht.
NIS2: Schwachstellenmanagement ist keine Kür mehr
Seit Dezember 2025 ist die NIS2-Umsetzung in Deutschland in Kraft. Für die betroffenen Unternehmen — ab 50 Mitarbeitern bzw. 10 Mio. € Umsatz in 18 Sektoren — gehört der Umgang mit Schwachstellen ausdrücklich zum Pflichtkatalog der Risikomanagementmaßnahmen: Konzepte für die Bewältigung von Sicherheitsvorfällen, Sicherheit bei Erwerb, Entwicklung und Wartung von IT-Systemen einschließlich Management und Offenlegung von Schwachstellen, plus Wirksamkeitsbewertung der Maßnahmen. Bußgeldrahmen: bis 10 Mio. € oder 2 % des weltweiten Umsatzes, dazu die persönliche Verantwortung der Geschäftsleitung.
Konkret heißt das: „Wir patchen halt monatlich" genügt als Nachweis nicht. Erwartet wird ein dokumentierter Prozess — Inventar, Schwachstellenerkennung, Risikobewertung, definierte Fristen, Ausnahmenbehandlung, Erfolgskontrolle. Die gute Nachricht: Genau das ist das risikobasierte Modell aus diesem Artikel. Wer die SLA-Matrix, das Inventar und die Reports aufsetzt, erledigt die NIS2-Anforderung nebenbei — und umgekehrt liefert NIS2 das Management-Argument für die nötigen Ressourcen. Ergänzend gilt: Patchen wirkt nur gegen bekannte Lücken. Für die Tage zwischen Ausnutzungsbeginn und Patch braucht es Detektion — EDR/XDR auf den Endpunkten und ein SIEM, das Anomalien auf exponierten Systemen meldet, bevor der Verschlüsselungs-Job läuft.
Fazit: Sortieren statt ertrinken
Ehrlich: Die Zahlen werden nicht wieder sinken. FIRST prognostiziert auch für 2027 und 2028 weiteres Wachstum, Microsoft hat dauerhaft höhere Volumina angekündigt, und KI-gestützte Schwachstellensuche arbeitet auf beiden Seiten. Ein Patch-Prozess, der 2024 solide war, ist 2026 rechnerisch überfordert — das ist keine Schuldfrage des Admin-Teams, sondern Arithmetik.
Die Antwort ist unspektakulär und funktioniert: ein gepflegtes Inventar mit Expositions-Klassen, KEV als Sofort-Liste, EPSS plus CVSS als Sortierung für den Rest, eine verbindliche SLA-Matrix mit Wartungsfenstern und Ausnahmen-Regeln, Ringe für die Fläche, Hotpatching gegen den Reboot-Engpass — und Detektion für die Lücke zwischen Exploit und Patch. Die meisten KMU können das mit Bordmitteln zu 80 % selbst aufbauen; was intern regelmäßig fehlt, sind die tägliche Triage der Feeds und die Nacht- und Wochenendfähigkeit für die 24-Stunden-Fälle. Genau dafür gibt es Managed-Service-Modelle mit definierten Patch-SLAs — und einen Partner, bei dem die 621 CVEs nicht auf dem Schreibtisch eines einzelnen Admins landen.