Microsofts August-Patch-Day behob rund 400 Schwachstellen – und ein echtes Feuer

Microsoft hat am 11. August eines der größten Sicherheitsupdates seiner Geschichte ausgeliefert und rund 400 Schwachstellen in Windows, Office, Azure, Exchange, SharePoint und einer langen Liste weiterer Produkte behoben. Der Patch Tuesday im August 2026 enthält drei Zero-Day-Lücken – eine davon wurde bereits aktiv ausgenutzt – und mindestens eine vollständig dokumentierte, nicht authentifizierte Remote-Code-Ausführungskette.

Zum Weiterlesen: Microsofts Patchday im Oktober 2026 stellt mit 1.407 Korrekturen einen Rekord auf · Microsofts Rekord-Patchday: 974 Schwachstellen, zwei bereits ausgenutzt.

Die Schlagzeilenzahl ist so groß, dass sie selbst zur Geschichte geworden ist. Es ist das zweitgrößte Monatsrelease, das Microsoft je produziert hat, und der Branchenkonsens lautet, dass dieses Volumen keine Spitze, sondern die neue Normalität ist.

Ein Release in Rekordgröße – und ein Zählproblem

Das Erste, was man über einen Patch Tuesday mit 400 CVEs wissen sollte: Niemand ist sich über die genaue Zahl einig.

BleepingComputer zählt 400 am Tag veröffentlichte Schwachstellen, darunter 42 als kritisch eingestufte, 37 davon Remote-Code-Ausführung. Tenable zählt 398 und hat zwei von MITRE zugewiesene CVEs ausgeschlossen. Cisco Talos zählt 421, davon 62 kritisch. Das Zero Day Initiative sieht ebenfalls 398 CVEs, zählt aber 62 kritisch statt 42 – ein Unterschied, der darauf hinausläuft, wie dieselben Advisories klassifiziert werden.

Die Abweichung ist kein Skandal, sondern ein Symptom. Microsofts Advisories umfassen lokale Produkte und Cloud-Dienste, manche Fixes erscheinen außerhalb des Monatszyklus, und Schweregrad-Einstufungen sind ebenso sehr Ermessenssache wie Messung. Die praktische Lehre für Verteidiger: Die Schlagzeilenzahl ist ein grober Indikator, kein Inventar. Entscheidend ist, welche konkreten Lücken die eigene Umgebung betreffen.

Die eine, die zählt: CVE-2026-68820

Unter Hunderten von Funden sticht einer heraus. CVE-2026-68820 ist eine Rechteausweitungslücke im Windows Ancillary Function Driver for WinSock (afd.sys), einer Kernelkomponente, die praktisch auf jedem Windows-System vorhanden ist. Es ist ein Use-after-Free-Fehler, der einem lokal authentifizierten Angreifer ohne Nutzerinteraktion SYSTEM-Rechte verschafft.

Der Schweregrad ist unspektakulär – CVSS 7,0, nur als „Important" eingestuft –, aber die Lücke wurde als Zero-Day aktiv ausgenutzt. Check-Point-Forscher berichteten, dass nordkoreanische Akteure der Gruppe Lazarus sie nutzten, um eine neue Version von FudModule, ihrem Kernel-Mode-Rootkit, in einer neuen Welle der seit Langem laufenden Kampagne Operation Dream Job einzusetzen.

Das Muster ist inzwischen vertraut genug, um als Regel zu gelten: Die aktiv ausgenutzte Lücke ist selten die am höchsten bewertete. In fünf der letzten sechs Patch-Tuesday-Releases war die ausgenutzte Schwachstelle nicht die mit der höchsten Schweregrad-Einstufung. Programme, die allein nach CVSS-Score triagieren, werden die Fixes weiterhin in der falschen Reihenfolge ausrollen.

Die öffentlich gemachten Zero-Days

Zwei weitere Lücken waren öffentlich, bevor Patches existierten.

CVE-2026-62832 ist eine Rechteausweitungslücke im Windows User Profile Service; Microsoft schätzte eine folgende Ausnutzung als wahrscheinlich ein. CVE-2026-72971 ist eine Manipulationslücke im Windows Container Isolation FS Filter Driver (unionfs.sys). Help Net Security merkte zudem an, dass CrowdStrike CVE-2026-62737, eine Rechteausweitungslücke im Windows-Kernel, als vor dem Patch öffentlich gemacht markierte.

Öffentliche Offenlegung vor einem Fix ist gefährlich, weil sie die Uhr für funktionierenden Exploit-Code startet, bevor Verteidiger handeln können. Sobald eine Lücke öffentlich ist, wetteifern Angreifer und Forscher um die Waffe, und das Fenster zwischen Patch-Verfügbarkeit und erster Ausnutzung kann in Stunden gemessen werden. Diese gehören unabhängig davon, ob Angriffe beobachtet wurden, in die erste Ausrollstufe.

Die SharePoint-Kette und die KI-gestützte Entdeckung

Der technisch bedeutendste Fix ist überhaupt kein Zero-Day. CVE-2026-63520 ist eine unsichere .NET-Typinstanziierungslücke in SharePoint Business Connectivity Services, bewertet mit CVSS 8,1 und gemeinsam von Microsoft und Rapid7 offengelegt. Forscher Stephen Fewer baute die Exploit-Kette für Pwn2Own Berlin.

Verkettet mit der JWT-Authentifizierungsumgehung vom Juli (CVE-2026-55040) ergibt sie vollständige Remote-Code-Ausführung gegen lokale SharePoint-Server 2016, 2019 und Subscription Edition ganz ohne Anmeldedaten. Das ist so schwerwiegend, wie web-exponierte Schwachstellen nur sein können, und es ist die Vollendung einer zweiteiligen Sequenz, die Verteidiger seit dem Vormonat verfolgen.

Bemerkenswert ist, dass die Berichterstattung über die Offenlegung die zugrunde liegende Forschung als KI-gestützt beschreibt – ein Detail, das zum breiteren Trend passt. Sicherheitsforscher setzen zunehmend KI-Werkzeuge ein, um Bugs zu finden, was erklärt, warum das Entdeckungsvolumen explodiert ist, während aktiv ausgenutzte Zero-Days dies nicht taten. Das Wettrüsten der Werkzeuge läuft inzwischen auf beiden Seiten des Offenlegungstisches.

Der Patching-Kapazitätsengpass

Hinter den Zahlen steckt eine schlichte operative Realität: Die meisten Organisationen können 400 Updates im Monat weder installieren noch testen.

Jeder Patch birgt das Risiko, etwas zu beschädigen – einen Treiber, eine Fachanwendung, eine individuelle Integration. Deshalb führen Unternehmen Updates in Stufen ein, validieren sie in einer Testumgebung und rollen sie schrittweise aus. Bei ein paar Dutzend Lücken im Monat ist dieser Prozess handhabbar. Bei 400 wird er zur Warteschlange, und Warteschlangen werden leicht zu Rückständen, die nie abgearbeitet werden.

Das Ergebnis ist, dass Sicherheitsteams gezwungen sind, den Gedanken eines umfassenden Patchings aufzugeben und etwas wie risikobasierte Triage anzunehmen. Statt „haben wir alles installiert?" fragen sie: „haben wir die Dinge installiert, die uns diesen Monat tatsächlich schaden können?" Das ist die richtige Frage, aber ihre Beantwortung erfordert Inventardaten, Expositionsanalyse und Exploit-Informationen – Fähigkeiten, die vielen Organisationen noch fehlen.

Automatisierung absorbiert einen Teil der Last: Patch-Management-Plattformen, Konfigurationsscanner und Endpoint-Tooling können die mechanische Bereitstellung übernehmen. Was Automatisierung nicht leisten kann, ist das Urteilsvermögen. Zu entscheiden, dass eine CVSS-7,0-Lücke in einem Kernel-Treiber wichtiger ist als eine CVSS-9,8-Lücke in einem Dienst, den man gar nicht betreibt, ist eine kontextuelle Entscheidung, und sie ist die knappe Fähigkeit im modernen Schwachstellenmanagement. Bei einem bestätigten Feuer auf vierhundert Funde leistet ein Programm, das diese Trennung nicht automatisch hinbekommt, nicht vierhundert Einheiten nützlicher Arbeit – es leistet eine.

Warum das Volumen die eigentliche Geschichte ist

Die schiere Zahl der Funde verdeckt den wichtigeren Trend: Die Entdeckung ist explodiert, doch die Ausnutzung ist ihr nicht gefolgt.

Über die fünf Releases seit der „Glasswing"-Ankündigung lief das Monatsvolumen nach einer von Brinqa zusammengestellten Analyse bei rund 167, 120, 200, 570 und 400 CVEs. Aktiv ausgenutzte Zero-Days lagen in denselben Releases bei zwei, null, eins, zwei und eins. Es werden mehr Bugs gefunden und behoben als je zuvor; die Zahl der als Zero-Day bewaffneten bleibt etwa gleich.

Das Problem ist nicht mehr, dass Schwachstellen schneller ausgenutzt werden. Es ist, dass es mehr von ihnen gibt, als irgendein Team sinnvoll triagieren kann.

Das ordnet die Herausforderung neu. Wenn ein typisches Unternehmen 400 Funde im Monat sieht und nur eine Handvoll ein echtes, ausnutzbares Risiko in seiner konkreten Umgebung darstellt, ist der Engpass nicht die Patching-Kapazität an sich, sondern die Fähigkeit, die wenigen wichtigen von den vielen unwichtigen zu trennen. Schweregrad-Scores allein können das nicht leisten. Kontext – ist das Asset internetexponiert? ist die Lücke erreichbar? gibt es einen öffentlichen Exploit? ist die Komponente überhaupt im Einsatz? – unterscheidet einen echten Notfall von einer Position auf der Liste.

Vorbehalte und was zu beobachten ist

Einige Vorbehalte sind angebracht. Die Zählungsmeinungsverschiedenheit ist real, ändert aber nichts an der Verteidigungspriorität: Die Spitze der Liste ist dieselbe, egal ob die Summe 398 oder 421 lautet. Auch die Deutung „KI-gestützte Entdeckung" sollte sorgfältig behandelt werden – sie ist eine plausible und zunehmend zitierte Erklärung für das steigende Volumen, aber keine formale Messung, und Anbieter haben Anreize, Wachstum aufregenden Ursachen zuzuschreiben.

Separat berichtete Help Net Security, dass ein Forscher einen Proof-of-Concept-Exploit namens „ShieldBreak" veröffentlichte, der den Juli-Fix von Microsoft für die Defender-Lücke CVE-2026-50656 („RoguePlanet") umgehen soll. Der Sicherheitsanalyst Will Dormann wurde zitiert, er habe bestätigt, dass der PoC bei aktiviertem Defender funktioniert, wobei der behauptete Umfang noch geprüft wird. Hält das stand, ist der Juli-Patch unvollständig – eine Erinnerung daran, dass ein Fix nur so lange ein Fix ist, bis jemand das Gegenteil beweist.

Es lohnt sich zudem, ehrlich zu sein, was „gepatcht" in einem Monat wie diesem bedeutet. Das Update zu installieren ist notwendig, aber nicht ausreichend; Angreifer verketten häufig eine frisch gepatchte Lücke mit einer älteren, ungepatchten, oder nutzen die Lücke zwischen Patch-Veröffentlichung und flächendeckendem Rollout. Die Zeit von der Veröffentlichung bis zur vollständigen Bereitstellung zu messen – nicht den Tag, an dem das Update genehmigt wurde – ist die Kennzahl, die Exposition tatsächlich reduziert, und bei diesem Volumen dehnen selbst gut geführte Teams dieses Fenster.

Zu beobachten ist als Nächstes, ob Microsoft den Rhythmus selbst ändert. Bei diesem Volumen gerät das monatliche Modell unter Druck; einige Sicherheitsverantwortliche fordern kontinuierliche oder bedarfsgesteuerte Updates für die schwerwiegendsten Lücken statt eines einmal monatlichen Auslieferungsstoßes. Steigt die Entdeckung weiter, wird aus der Frage, ob Patch Tuesday seinen eigenen Erfolg überleben kann, ein Planungsproblem statt eines Gedankenexperiments – und die Antwort wird prägen, wie jede Organisation auf Jahre hinaus patcht.