CVE-2026-69524 CVE-2026-69546 AD-RCE: Patchkontrolle

Zusammenfassung: CVE-2026-69524 CVE-2026-69546 AD-RCE Patchkontrolle

CVE-2026-69524 und CVE-2026-69546 sind zwei eigenständige Schwachstellen zur Remotecodeausführung in Active Directory Domain Services (AD DS), die am 8. September 2026 veröffentlicht wurden. Beide haben einen CVSS-3.1-Basiswert von 8.1, erfordern laut ihren CVSS-Vektoren weder Berechtigungen noch Benutzerinteraktion und betreffen eine Use-after-free-Schwäche. Laut Microsoft setzt eine erfolgreiche Ausnutzung voraus, dass der Angreifer eine Race Condition für sich entscheidet. Diese zusätzliche Schwierigkeit sollte bei der Patchplanung berücksichtigt werden, ohne eine der Schwachstellen aus der Behebungsliste für Domänencontroller zu entfernen. Es handelt sich um September-Updates, die im Oktober geprüft werden, nicht um neu angekündigte Oktober-Schwachstellen. Microsofts September-CVRF ist die Quelle für die folgenden CVE-Fakten.

Für Verteidiger besteht die unmittelbare Priorität darin, jedem Domänencontroller das passende Update zuzuordnen, die Installation und den abgeschlossenen Neustart zu überprüfen und nützliche Telemetrie zu sichern. Das öffentliche CVRF liefert weder eine CVE-spezifische Ereignissignatur noch einen Kompromittierungsindikator. Allgemeine Warnungen zu Verzeichnisänderungen oder zum Zustand von Diensten sollten die Untersuchung unterstützen, ohne als Beweis für die Ausnutzung einer dieser Schwachstellen dargestellt zu werden.

CVE-2026-69524 und CVE-2026-69546 im Vergleich

Die folgenden Werte stammen aus dem September-CVRF, das am 3. Oktober 2026 abgerufen wurde. Microsoft stuft beide Schwachstellen als Important ein. Die Zeichenfolgen zur Ausnutzung werden unverändert wiedergegeben; die unterschiedlichen Bewertungen der Ausnutzungswahrscheinlichkeit müssen voneinander getrennt bleiben.

Keine der beiden CVEs war im JSON-Katalog bekannter ausgenutzter Schwachstellen der CISA enthalten, der am 3. Oktober 2026 geprüft wurde; die abgerufene Katalogversion war 2026.10.02. Das Fehlen an diesem Datum und Microsofts Felder Exploited:No sind separate Beobachtungen. Keine davon garantiert, dass eine Ausnutzung unmöglich ist oder sämtliche Aktivitäten beobachtet wurden.

Funktionsweise: Use-after-free und eine Race Condition

Use-after-free tritt auf, wenn Software auf Speicher zugreift, nachdem dieser freigegeben wurde. Die Folgen hängen von der Implementierung ab; Abstürze und unbefugte Codeausführung gehören zu den in MITREs Definition von CWE-416 beschriebenen Möglichkeiten. Dies erklärt die Schwachstellenklasse, ohne die verwundbare Funktion oder das genaue Paketformat einer der beiden CVEs zu bestimmen.

Microsofts FAQ zu CVE-2026-69524 beschreibt einen nicht authentifizierten Angreifer, der ein speziell präpariertes Paket an einen betroffenen Netzwerkdienst sendet. Die FAQ zu CVE-2026-69546 beschreibt einen Angreifer innerhalb des Netzwerks, der beliebige Endpunkte aufruft. Beide FAQs erklären, dass zur Ausnutzung eine Race Condition gewonnen werden muss. Das CVRF benennt weder die betroffenen Endpunkte noch eine zuverlässige Exploit-Abfolge oder einen gemeinsamen zugrunde liegenden Codefehler. Die gemeinsame Behandlung hier ergibt sich aus ihrer gemeinsamen Komponente, Schwachstellenklasse und Update-Zuordnung.

Warum AC:H weiterhin Maßnahmen erfordert

AC:H kennzeichnet ein zusätzliches Hindernis für die Ausnutzung. Dadurch wird PR:N nicht zu einer Authentifizierungsanforderung und UI:N nicht zur Voraussetzung, dass jemand einen Link anklickt. Unsere operative Empfehlung lautet, betroffene Domänencontroller zu priorisieren, weil sie die Identitätsinfrastruktur bereitstellen, und dabei Microsofts tatsächliche Wahrscheinlichkeitsbewertungen beizubehalten. Erfinden Sie keine Erfolgsquote, bezeichnen Sie diese Schwachstellen nicht als wurmfähig und setzen Sie Netzwerkzugriff nicht mit öffentlicher Erreichbarkeit aus dem Internet gleich.

Die Analyse der Domänencontroller-RCEs vom August erklärt, warum Teams DC-bezogene Rollen inventarisieren und die Patchkonformität für alle diese Rollen prüfen. Sie behandelt eine andere Veröffentlichung und andere CVEs; ihre Angriffsbeschreibungen sollten nicht auf dieses Schwachstellenpaar übertragen werden.

Das richtige Update auf jedem Domänencontroller prüfen

Das September-CVRF ordnet beiden CVEs die folgenden Windows-Server-Korrekturen zu, einschließlich der entsprechenden Server-Core-Produkte. Diese Tabelle dokumentiert die ursprüngliche Update-Zuordnung und ist keine Anweisung, ein älteres Paket über ein neueres anwendbares kumulatives Update zu installieren.

Gleichen Sie Produkt und Installationsvariante ab, bevor Sie ein Update auswählen. Die Aufnahme in diese CVRF-Tabelle sagt nichts über den Supportanspruch eines Servers aus. Für Server 2025 bestätigt der Supportartikel zu KB5122871 unabhängig den Betriebssystem-Build 26100.33438 und beschreibt die unterstützten Installationskanäle. Konsultieren Sie die jeweilige Veröffentlichungsdokumentation zu Voraussetzungen, bekannten Problemen und späteren Updates.

Microsofts Get-HotFix-Dokumentation enthält genau diesen Befehl zur lokalen Bestandsaufnahme:

Get-HotFix

Die dokumentierten Parameter -Id und -ComputerName lassen sich wie folgt auf die Server-2025-Zuordnung anwenden. DC01 ist ein Platzhalter; verwenden Sie den tatsächlichen Namen des Controllers. Diese Befehle sind Beispiele auf Grundlage der Dokumentation, keine Ergebnisse aus einer Kundenumgebung.

Get-HotFix -Id KB5122871 -ComputerName DC01

Bewahren Sie die zurückgegebenen Installationsnachweise zusammen mit der genauen Betriebssystemversion, dem laufenden Build und dem Neustartstatus aus Ihren Verwaltungstools auf. Get-HotFix verwendet die Klasse Win32_QuickFixEngineering, deren Update-Abdeckung begrenzt ist. Ein fehlender Eintrag muss untersucht werden; allein belegt er keine Verwundbarkeit, insbesondere wenn ein späteres Update das ursprüngliche KB ersetzt. Bestätigen Sie Anwendbarkeit und Ersetzung, bevor Sie den Vorgang abschließen.

Erkennung: Kontext sammeln und anschließend untersuchen

Trennen Sie die Gefährdung durch fehlende Patches von einem vermuteten Sicherheitsvorfall. Erstere erfordert eine verlässliche Update-Inventarisierung. Letzterer erfordert korrelierte Aktivitäten und eine Untersuchung. Keine der folgenden Ereignis-IDs identifiziert eindeutig die Ausnutzung von CVE-2026-69524 oder CVE-2026-69546.

Microsoft dokumentiert die AD-DS-Diagnoseprotokollierung, einschließlich der standardmäßigen Erfassung kritischer Ereignisse und Fehler. Erhöhen Sie die Diagnosedetailstufe nur für eine zeitlich begrenzte Untersuchung und setzen Sie sie danach auf die normale Einstellung zurück; zusätzliche Details können die Leistung beeinträchtigen. Leiten Sie die Protokolle Security und Directory Service zentral weiter und prüfen Sie die Funktionsfähigkeit der Erfassung, bevor Sie aus fehlenden Einträgen Schlüsse ziehen.

Die primären Ereignisreferenzen sind 5136: Verzeichnisobjekt geändert und 1102: Überwachungsprotokoll gelöscht. Sichern Sie für 5136 die Felder SubjectUserName, ObjectDN, AttributeLDAPDisplayName, AttributeValue, OperationType und OpCorrelationID. Eine Änderung erzeugt üblicherweise separate Ereignisse für das Löschen und Hinzufügen eines Werts; korrelieren Sie sie anhand von OpCorrelationID sowie dem Objekt- und Attributkontext, um alte und neue Werte zu vergleichen. Der Leitfaden zur AD-Überwachung erklärt, warum Überwachungsrichtlinie, Erfassung, Feldzuordnung und Korrelation zusammenwirken müssen, bevor ereignisbasierte Erkennungen eine nützliche Abdeckung bieten.

Für die lokale Ersteinschätzung passt dieses Beispiel Microsofts Get-WinEvent-Syntax und Hashtable-Filterung an. Führen Sie es auf dem Controller mit den erforderlichen Rechten zum Lesen der Protokolle aus:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5136,1102} -MaxEvents 100
Get-WinEvent -LogName 'Directory Service' -MaxEvents 100

Das Limit begrenzt die angezeigten Datensätze; es ist weder ein Alarmschwellenwert noch eine vollständige Vorfallschronologie. Prüfen Sie das relevante Zeitfenster in Ihrem SIEM, korrelieren Sie unerwartete Änderungen mit Host- und Netzwerktelemetrie und schließen Sie dokumentierte Wartungsarbeiten aus. Eine Abfrage ohne Auffälligkeiten kann weder bestätigen, dass ein DC gepatcht ist, noch dass er nicht kompromittiert wurde.

Behebung: Patchen, neu starten und Nachweise sichern

1. Erstellen Sie für jeden Controller einen Update-Nachweis. Erfassen Sie das genaue Windows-Server-Produkt, die Installationsvariante, das anwendbare KB oder ersetzende Update, den Verantwortlichen und den Abschlussnachweis. Klären Sie nicht erreichbare oder nicht gemeldete Systeme ausdrücklich.
2. Installieren Sie das anwendbare unterstützte Update. Beide CVEs erfordern eine Kundenaktion. Verwenden Sie den genehmigten Update-Kanal und beachten Sie die Voraussetzungen sowie die Hinweise zu bekannten Problemen der Veröffentlichung. Für Server 2025 empfiehlt der Supportartikel das neueste anwendbare Windows-Update und dokumentiert die spätere Behebung eines RDS-Problems, das die September-Veröffentlichung betraf.
3. Schließen Sie den erforderlichen Neustart ab und prüfen Sie den Zustand der Dienste. Beide CVRF-Einträge kennzeichnen für die aufgeführten Server-Updates einen erforderlichen Neustart. Bestätigen Sie Authentifizierung und Replikation mit Ihren üblichen Betriebsprüfungen und vergleichen Sie neue Verzeichnisdienstfehler mit dem Ausgangszustand vor der Wartung.
4. Prüfen Sie die Installationsnachweise erneut. Verwenden Sie den dokumentierten Inventarisierungsbefehl und Verwaltungsnachweise, bestätigen Sie den laufenden Build sowie die Ersetzung und bewahren Sie das Ergebnis für jeden Controller auf. Ein installiertes Paket mit ausstehendem Neustart ist kein abgeschlossener Änderungsvorgang.
5. Untersuchen Sie glaubhafte Hinweise auf eine Kompromittierung separat. Sichern Sie zentral gesammelte Protokolle und Host-Nachweise, koordinieren Sie die Eindämmung mit dem Team für Identitätssicherheitsvorfälle und bewerten Sie unbefugte Verzeichnisänderungen. Allein die Installation des Fixes macht Änderungen, die ein Angreifer bereits vorgenommen haben könnte, nicht rückgängig.

Wie EtcSec dies erkennt

Verwenden Sie Ergebnisse der EtcSec-Konfigurationsprüfung zusammen mit unabhängigen Nachweisen zur Patchkonformität und SIEM-Untersuchungen. Diese Analyse validiert keine EtcSec-Prüfung für eine der beiden CVEs, das installierte Update oder deren Ausnutzung. Ein Konfigurationsbefund allein kann nicht feststellen, ob ein Controller das anwendbare AD-DS-Update vom September erhalten hat.