Kritische Codeausführung in den AD-Zertifikatdiensten: CVE-2026-62818
Im August-Patchday hat Microsoft eine Schwachstelle in den Active Directory-Zertifikatdiensten geschlossen, die in vielen Umgebungen viel zu weit unten auf der Prioritätenliste gelandet ist. Der Grund: Sie hat „nur“ CVSS 8.8 und ist bisher nicht als ausgenutzt gemeldet. Das ist der falsche Maßstab. Entscheidend ist, wo die Lücke sitzt.
Eine RCE auf der Zertifizierungsstelle ist keine Server-Lücke. Sie ist eine Lücke in der Vertrauenswurzel der gesamten Domäne.
Was genau gepatcht wurde
CVE-2026-62818 ist ein Use-after-free (CWE-416) in den Active Directory Certificate Services. Ein Angreifer sendet eine speziell präparierte Anfrage über das Netzwerk an den betroffenen Dienst und kann dadurch Code auf dem Zielsystem ausführen. Benutzerinteraktion ist nicht erforderlich, die Angriffskomplexität ist niedrig.
| Merkmal | Ausprägung | Bedeutung für die Praxis |
|---|---|---|
| CVE-ID | CVE-2026-62818 | Veröffentlicht im Security Release vom 11. August 2026 |
| Typ | Remote Code Execution (Use-after-free) | Codeausführung im Kontext des CA-Dienstes |
| CVSS | 8.8 CRITICAL | Microsoft stuft die Lücke als „Critical“ ein |
| Voraussetzung | Authentifiziert, niedrige Rechte | Ein beliebiges Domänenkonto genügt – auch ein kompromittiertes |
| Benutzerinteraktion | Keine | Kein Klick, kein Social Engineering nötig |
| Betroffen | Server 2012/R2, 2016, 2019, 2022, 2025 (inkl. Core), Windows 10 1607/1809 | Praktisch jede laufende Windows-CA |
| Exploit-Status | KEIN PoC BEKANNT | Stand der Veröffentlichung – das kann sich täglich ändern |
Warum ausgerechnet die CA die kritischste Baustelle ist
Die Zertifizierungsstelle stellt die Zertifikate aus, mit denen sich in Ihrer Umgebung Menschen und Maschinen ausweisen: Smartcard-Anmeldung, WLAN- und VPN-Authentifizierung per EAP-TLS, internes TLS, Geräteidentitäten, Codesignatur. Wer Code auf der CA ausführen kann, greift potenziell auf Vorlagen, Registrierungsdienste, Sicherungsmaterial und im schlimmsten Fall auf den privaten Schlüssel der CA zu.
Genau deshalb ist die Reihenfolge beim Patchen wichtiger als die CVSS-Zahl. Ein Server, der neu ausgerollt werden kann, ist ein Sachschaden. Eine Vertrauenswurzel, die neu aufgebaut werden muss, ist ein Projekt über Wochen – mit Auswirkungen auf jede Anmeldung, jede VPN-Verbindung und jede Anwendung, die auf interne Zertifikate baut.
Schritt 1: Wissen, wo Ihre CAs überhaupt stehen
Erfahrungsgemäß ist die erste Überraschung nicht der Patchstand, sondern die Anzahl. In gewachsenen Umgebungen finden sich Test-CAs aus Projekten, eine zweite ausstellende CA aus einer alten Migration oder eine CA, die seit Jahren auf einem Domänencontroller mitläuft. Alle diese Objekte sind im Configuration Naming Context sauber hinterlegt – das folgende Skript liest sie dort aus und prüft direkt den Patchstand mit:
# ISW - AD CS Inventar & Patchstand (August 2026)
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
Import-Module ActiveDirectory
$cfg = (Get-ADRootDSE).configurationNamingContext
$base = "CN=Enrollment Services,CN=Public Key Services,CN=Services,$cfg"
$cas = Get-ADObject -SearchBase $base -SearchScope OneLevel `
-Filter 'objectClass -eq "pKIEnrollmentService"' `
-Properties dNSHostName, cn, cACertificateDN
$dcs = (Get-ADDomainController -Filter *).HostName
foreach ($ca in $cas) {
$srv = $ca.dNSHostName
$obj = [ordered]@{
CA = $ca.cn
Server = $srv
AufDC = ($dcs -contains $srv)
OS = 'n/a'
LetzterPatch= 'n/a'
Erreichbar = $false
}
try {
$os = Get-CimInstance Win32_OperatingSystem -ComputerName $srv -ErrorAction Stop
$obj.OS = "$($os.Caption) (Build $($os.BuildNumber))"
$hf = Get-HotFix -ComputerName $srv -ErrorAction Stop |
Sort-Object InstalledOn -Descending | Select-Object -First 1
$obj.LetzterPatch = $hf.InstalledOn.ToString('yyyy-MM-dd') + " / " + $hf.HotFixID
$obj.Erreichbar = $true
} catch {
$obj.LetzterPatch = "Abfrage fehlgeschlagen: $($_.Exception.Message)"
}
[pscustomobject]$obj
}Schritt 2: Angriffsfläche der CA verkleinern
Das Update schließt diese eine Lücke. Es ändert nichts an der Frage, wer den CA-Dienst überhaupt erreichen darf. Die Rollendienste rund um die Webregistrierung sind dabei die üblichen Verdächtigen, weil sie den Dienst über HTTP erreichbar machen und in vielen Umgebungen nur für ein einziges altes Projekt installiert wurden:
# Welche Rollendienste laufen auf der CA? (auf dem CA-Server ausfuehren)
Get-WindowsFeature AD-Certificate, ADCS-Cert-Authority, ADCS-Web-Enrollment,
ADCS-Enroll-Web-Pol, ADCS-Enroll-Web-Svc, ADCS-Device-Enrollment |
Where-Object Installed |
Select-Object Name, DisplayName
# Wer darf sich an der CA anmelden bzw. Zertifikate anfordern?
certutil -v -getreg CA\Security | Select-String "Allow|Deny"- Nicht benötigte Rollendienste entfernen – insbesondere Web Enrollment, CES und CEP, wenn kein Anwendungsfall existiert.
- Netzwerkzugriff auf den CA-Dienst auf administrative Netze und tatsächlich registrierende Systeme begrenzen.
- Enrollment-Rechte prüfen: „Authenticated Users“ auf Vorlagen mit „Enrollee supplies subject“ ist der Klassiker unter den ESC-Fehlkonfigurationen.
- Auditierung auf der CA aktivieren und die Ausstellungsprotokolle regelmäßig auswerten – nicht erst im Vorfall.
- Sperrprozess einmal testen: Können Sie ein einzelnes verdächtiges Zertifikat innerhalb einer Stunde sperren und die CRL verteilen?
- Offline-Root-CA konsequent offline halten und den privaten Schlüssel getrennt sichern.
Schritt 3: Den Patchstand dauerhaft belegen können
Für alle, die unter NIS2 oder ISO 27001 berichten müssen, endet die Aufgabe nicht mit dem installierten Update. Sie müssen belegen können, welche Systeme betroffen waren, wann sie gepatcht wurden und wie Sie das nachgehalten haben. Ein Screenshot aus dem WSUS reicht dafür nicht – gefragt ist eine nachvollziehbare Zuordnung von CVE zu System zu Zeitpunkt.