Zwei Zeilen aus derselben Update-Liste

Am 11. August 2026 hat Microsoft zwei Schwachstellen veröffentlicht, die zusammen eine Frage beantworten, die in jedem Betrieb auftaucht, sobald die monatliche Liste länger ist als das Wartungsfenster: Womit fängt man an?

Die eine trägt den Schweregrad 9,8 von 10. Die andere 7,0. Wer nur diese beiden Zahlen vergleicht, hat die Reihenfolge scheinbar sofort — und sie steht falsch herum. Angegriffen wird nach Angabe des Herstellers die 7,0, nicht die 9,8.

Dieser Beitrag erklärt an den beiden Fällen, woran das liegt, und leitet daraus eine Regel ab, die auch dann noch gilt, wenn diese beiden Lücken längst geschlossen sind.

Auf einen Blick

  • CVE-2026-62878, „Windows DNS Server Remote Code Execution Vulnerability": Schweregrad 9,8, zeitbezogen 8,5. Ausnutzungsstatus laut Microsoft: Nein.
  • CVE-2026-68820, „Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability": Schweregrad 7,0, zeitbezogen 6,1. Ausnutzungsstatus laut Microsoft: Ja.
  • Beide wurden am 11. August 2026 veröffentlicht und werden mit den August-Updates geschlossen.
  • Die Punktzahl beschreibt die Bauart einer Lücke, nicht die Lage draußen. Sie sagt, wie schwer ein erfolgreicher Angriff wiegt — nicht, ob er stattfindet.
  • Jeder Windows-Domänencontroller ist zugleich DNS-Server. Die Rolle läuft mit, ohne dass sie jemand bewusst eingerichtet hätte.
  • Microsoft widerspricht sich im eigenen Datensatz zu CVE-2026-68820: Der Ausnutzungsstatus steht auf „Ja", der Bewertungsvektor führt zugleich „kein funktionierender Angriffscode bekannt".
  • Die bleibende Regel: Reihenfolge nach Ausnutzungsstatus, nicht nach Punktzahl.

Fall A: die 9,8, die niemand angreift

CVE-2026-62878 betrifft den DNS-Server von Windows und erlaubt nach Microsofts Beschreibung die Ausführung fremden Programmcodes. Der Bewertungsvektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C — im Klartext: über das Netz erreichbar, geringe Komplexität, ohne Anmeldung, ohne Zutun eines Nutzers, mit voller Wirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. Das ist die Bauart, die eine Bewertung nach oben treibt, und sie erklärt die 9,8 vollständig.

Weshalb der Fall Betriebe im Mittelstand angeht, hat einen unscheinbaren Grund: Ein Windows-Domänencontroller ist praktisch immer zugleich DNS-Server. Die Rolle gehört zur Standardeinrichtung einer Active-Directory-Domäne, sie wird bei der Heraufstufung mitinstalliert, und in vielen Häusern hat nie jemand bewusst entschieden, einen DNS-Server zu betreiben. Wer auf die Frage „Betreiben wir DNS?" mit Nein antwortet, meint meist „wir haben nichts dergleichen eingerichtet" — betreiben tut er ihn trotzdem.

Und doch führt Microsoft für diese Lücke den Ausnutzungsstatus „Nein". Es ist kein Fall bekannt, in dem sie angegriffen wurde. Der Vektor enthält passend dazu den Bestandteil E:U für „Exploit Code Maturity: Unproven" — kein funktionierender Angriffscode bekannt. Er enthält daneben den Bestandteil RL:O für „Remediation Level: Official Fix" — ein Herstellerpatch liegt vor. Erst diese beiden Angaben zusammen drücken die zeitbezogene Bewertung von 9,8 auf 8,5; keine von beiden allein trägt den ganzen Abstand.

Das ist keine Entwarnung. Ein Angriffsweg dieser Bauart bleibt attraktiv, und was heute unbewiesen ist, kann in Wochen anders aussehen. Es heißt nur: An diesem Tag rechtfertigt dieser Eintrag kein Notfallfenster.

Fall B: die 7,0, die angegriffen wird

CVE-2026-68820 sitzt im Ancillary Function Driver für WinSock, einem Treiber, den jedes Windows-System für Netzwerkverbindungen mitbringt. Der Vektor lautet CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C — also: nur lokal ausnutzbar, hohe Komplexität, ein bestehendes Benutzerkonto vorausgesetzt. Drei Hürden, die die Zahl auf 7,0 drücken, zeitbezogen 6,1.

Der Schaden am Ende ist trotzdem erheblich: Aus einem gewöhnlichen Benutzerkonto werden Systemrechte. Für einen Angreifer ist das der Schritt, der aus einem Fuß in der Tür die Kontrolle über den Rechner macht — und Rechteausweitungen sind deshalb ein typischer zweiter Baustein nach einer Phishing-Mail oder einem gestohlenen Zugang.

Der Unterschied zu Fall A liegt in einem einzigen Feld: Microsoft führt hier den Ausnutzungsstatus „Ja". Die Lücke wird angegriffen. Damit ist sie kein Szenario mehr, sondern ein Vorgang; die drei Hürden im Vektor sind offenbar überwindbar, denn jemand hat sie überwunden.

Genau hier setzt in der Praxis der Fehler an: Eine 7,0 wirkt neben einer 9,8 wie das kleinere Problem und wandert nach unten in der Liste — obwohl sie der einzige der beiden Fälle ist, für den Angriffe belegt sind.

Der Widerspruch, den man kennen sollte

An dieser Stelle wird es unsauber, und wir halten das lieber fest, als es glattzubügeln: Derselbe Microsoft-Datensatz zu CVE-2026-68820 meldet den Ausnutzungsstatus „Ja" und trägt zugleich im Vektor den Bestandteil E:U — „Exploit Code Maturity: Unproven", also kein funktionierender Angriffscode bekannt. Beides steht wörtlich in derselben Quelle, und beides zusammen ergibt keinen widerspruchsfreien Satz.

Wir lösen das hier nicht auf. Wir wissen nicht, welches der beiden Felder den Stand der Dinge trifft, und ein Mittelwert aus zwei einander ausschließenden Angaben wäre eine erfundene Zahl. Für die Praxis gilt die vorsichtigere Lesart: Wo ein Hersteller „wird ausgenutzt" meldet, wird gepatcht — auch wenn ein Nebenfeld dagegen spricht.

Der Fall ist aber aus einem zweiten Grund lehrreich. Er zeigt, warum das Vergleichen von Punktzahlen ein schwacher Ersatz für das Lesen der Herstellerangabe ist. Die 7,0 entsteht aus einer Formel; der Satz „wird ausgenutzt" entsteht aus einer Beobachtung. Wer nur die Zahl in eine Tabelle überträgt, verliert genau die Information, auf die es ankommt — samt ihrer Unschärfen.

Die Regel: Reihenfolge nach Ausnutzungsstatus

Aus den beiden Fällen folgt eine Entscheidungsregel, die den Anlass überdauert:

  • Zuerst alles, was nachweislich angegriffen wird — unabhängig von der Punktzahl. Hier zählt jeder Tag.
  • Danach, was von außen ohne Anmeldung erreichbar ist — die Bauart aus Fall A, sobald sie an einem System hängt, das im Internet steht.
  • Zuletzt der Rest — geordnet im normalen Rhythmus, mit Testring und festem Wartungsfenster.

Die Punktzahl bleibt dabei nützlich, aber sie beantwortet eine andere Frage. Sie sagt, wie schlimm es wäre. Der Ausnutzungsstatus sagt, ob es passiert. Für die Reihenfolge zählt das Zweite.

Wir haben an anderer Stelle beschrieben, dass die Menge der monatlichen Sicherheitsupdates dauerhaft wächst und ein Verfahren nach dem Muster „wir lesen die Liste durch" daran zerbricht. Der Punkt hier ist der andere Teil derselben Aufgabe: Nicht wie viele Sie schaffen, sondern welche zuerst.

Was Sie jetzt tun sollten

  • Die August-Updates einspielen, auf Servern wie auf Arbeitsplätzen. Damit sind beide beschriebenen Lücken geschlossen — die angegriffene aus Fall B zuerst, wenn Sie nicht alles in einem Durchgang schaffen.
  • Prüfen, ob Ihr DNS-Dienst aus dem Internet erreichbar ist. Ein Domänencontroller gehört nicht ins offene Netz. Diese Prüfung dauert Minuten und wirkt über den einzelnen Patch hinaus.
  • Klären, wer bei Ihnen den Ausnutzungsstatus liest. Nicht die Punktzahl, sondern das Feld daneben — und die Frage, was davon Ihren Bestand überhaupt berührt.
  • Ein Notfallfenster definieren, bevor Sie es brauchen. Wer erst im Ernstfall klärt, wer außerhalb der Reihe patchen darf, verliert die Tage, auf die es ankommt.

Unsere Einschätzung

Die beiden Einträge vom 11. August 2026 sind in wenigen Wochen erledigt. Die Verwechslung dahinter bleibt: Eine hohe Punktzahl liest sich wie Dringlichkeit, ist aber eine Beschreibung des Schadens im Erfolgsfall. Was ein Update vorzieht, ist die Beobachtung, dass jemand die Lücke bereits benutzt.

Wenn bei Ihnen niemand die monatliche Bewertung verlässlich vornimmt — oder wenn unklar ist, welche Ihrer Systeme aus dem Internet erreichbar sind —, sehen wir uns das gemeinsam an: Bestandsaufnahme, eine belastbare Reihenfolge und ein Wartungsfenster, das auch den Ausnahmefall trägt.