DHCP RCE Juli 2026

Während alle auf die beiden aktiv ausgenutzten Zero-Days schauen, stehen im Juli-Patchday zwei unauthentifizierte Remote-Code-Execution-Lücken im Windows DHCP Server mit CVSS 9.8. Kein Login, keine Benutzerinteraktion, geringe Angriffskomplexität. Und in kleineren Umgebungen läuft die DHCP-Rolle fast immer dort, wo sie am wenigsten hingehört: auf dem Domain Controller.

Die vergessenen 9.8er

Der Juli-Patchday 2026 war der größte aller Zeiten – je nach Zählweise 570 bis 622 CVEs, darunter rund 60 als kritisch eingestufte. Die ZDI sprach von einer »Bug-Apokalypse«. Bei dieser Menge passiert etwas Vorhersehbares: Die Berichterstattung konzentriert sich auf die drei Zero-Days, und alles andere verschwindet in einer Liste.

Genau dort stehen zwei Lücken, die in einem normalen Monat die Schlagzeile gewesen wären:

CVE CVSS Beschreibung
CVE-2026-50518 9.8 Windows DHCP Server, Heap-based Buffer Overflow (CWE-122). Remote Code Execution durch einen nicht authentifizierten Angreifer, ohne Benutzerinteraktion, geringe Angriffskomplexität.
CVE-2026-56159 9.8 Ebenfalls Windows DHCP Server, ebenfalls Heap-Overflow, ebenfalls unauthentifiziert und ohne Interaktion ausnutzbar.
CVE-2026-56188 9.8 Race Condition (CWE-362) in einem Windows-Server-Netzwerktreiber. RCE durch speziell präparierten Netzwerkverkehr, unauthentifiziert.
CVE-2026-57092 9.9 VMSwitch-Ausbruch – Gast-zu-Host auf Hyper-V-Systemen. Der höchste CVSS-Wert dieses Patchdays.

Alle vier haben eines gemeinsam: Sie sitzen auf der Netzwerk- statt auf der Identitätsschicht. Und alle vier greifen an Stellen an, die sich nicht durch MFA, Conditional Access oder Tiering absichern lassen – ein DHCP-Paket fragt nicht nach Anmeldedaten.

Warum DHCP ein besonders unangenehmes Ziel ist

Der Windows-DHCP-Dienst hat drei Eigenschaften, die zusammen ein hässliches Bild ergeben.

Erstens läuft er als SYSTEM. Eine erfolgreiche Code-Ausführung im DHCP-Server-Prozess bedeutet SYSTEM-Rechte auf dem Host – ohne Zwischenschritt, ohne Privilege Escalation, ohne Umweg.

Zweitens hört er auf einem Broadcast-Protokoll. DHCP nimmt per Definition Pakete von Geräten entgegen, die noch keine Identität haben. Es gibt keine Vorauthentifizierung, die man härten könnte. Jedes Gerät im selben Broadcast-Segment – auch ein kompromittierter Drucker, ein Besucher-Notebook oder eine unsauber getrennte Gäste-WLAN-Zone – kann Pakete an den Dienst schicken.

Drittens steht er in kleineren Umgebungen fast immer auf dem Domain Controller. Das war jahrelang die pragmatische Standardinstallation: Ein Server, alle Rollen. Damit wird aus einer DHCP-Lücke unmittelbar eine Domain-Compromise-Lücke. SYSTEM auf einem DC ist der komplette Verzeichnisdienst.

Kurz gesagt: Wenn DHCP auf einem Domain Controller läuft, ist eine unauthentifizierte RCE in DHCP faktisch eine unauthentifizierte RCE im Active Directory – auslösbar von jedem Gerät im Netz.

Schritt 1: Wo läuft überhaupt DHCP?

Die meisten Administratoren können zwei DHCP-Server aus dem Kopf nennen. In gewachsenen Umgebungen sind es regelmäßig mehr – Testinstallationen, Außenstellen, ein alter Server, den mal jemand für ein Projekt aufgesetzt hat. Autorisierte DHCP-Server sind im Active Directory eingetragen und lassen sich sauber auslesen. Das folgende Skript kombiniert diese Liste mit einer direkten Rollenprüfung und dem Patchstand.

<#
    Get-IswDhcpExposure.ps1
    Findet alle DHCP-Server in der Domaene, prueft Patchstand,
    DC-Kollokation und Windows-Firewall-Status.
    Rein lesend. Benoetigt: ActiveDirectory- und DHCPServer-Modul, Domaenen-Adminrechte.
#>

[CmdletBinding()]
param(
    [datetime] $PatchStichtag = '2026-07-14',
    [string]   $ReportPath    = "$env:USERPROFILE\Desktop\DHCP_Exposure_$(Get-Date -f yyyyMMdd).csv"
)

Import-Module ActiveDirectory -ErrorAction Stop
Import-Module DhcpServer     -ErrorAction Stop

# --- 1) Im AD autorisierte DHCP-Server ---
$autorisiert = @()
try {
    $autorisiert = Get-DhcpServerInDC | Select-Object -ExpandProperty DnsName
} catch {
    Write-Warning "Get-DhcpServerInDC fehlgeschlagen: $($_.Exception.Message)"
}

# --- 2) Domain Controller zum Abgleich ---
$dcs = (Get-ADDomainController -Filter *).HostName

# --- 3) Server mit installierter DHCP-Rolle (Gegenprobe) ---
$serverOus = Get-ADComputer -Filter "OperatingSystem -like '*Server*' -and Enabled -eq 'True'" `
                            -Properties DNSHostName, OperatingSystem

$ergebnis = New-Object System.Collections.Generic.List[object]

foreach ($host in ($autorisiert + $serverOus.DNSHostName | Sort-Object -Unique)) {

    if ([string]::IsNullOrWhiteSpace($host)) { continue }
    if (-not (Test-Connection -ComputerName $host -Count 1 -Quiet)) { continue }

    # Rolle wirklich installiert und Dienst aktiv?
    $dienst = Get-Service -Name DHCPServer -ComputerName $host -ErrorAction SilentlyContinue
    if (-not $dienst) { continue }

    $istDC       = $dcs -contains $host
    $istAutor    = $autorisiert -contains $host

    # Letztes installiertes Update
    $letztesHF = $null
    try {
        $letztesHF = Get-HotFix -ComputerName $host -ErrorAction Stop |
                     Sort-Object InstalledOn -Descending |
                     Select-Object -First 1
    } catch { }

    $gepatcht = if ($letztesHF -and $letztesHF.InstalledOn -ge $PatchStichtag) { $true } else { $false }

    # Anzahl aktiver Bereiche (Hinweis auf produktive Nutzung)
    $bereiche = 0
    try { $bereiche = (Get-DhcpServerv4Scope -ComputerName $host -ErrorAction Stop).Count } catch { }

    # Risikobewertung
    $risiko = 'NIEDRIG'
    if (-not $gepatcht)              { $risiko = 'HOCH' }
    if (-not $gepatcht -and $istDC)  { $risiko = 'KRITISCH' }
    if ($gepatcht -and $istDC)       { $risiko = 'MITTEL' }

    $ergebnis.Add([pscustomobject]@{
        Server           = $host
        DienstStatus     = $dienst.Status
        IstDomainCtrl    = $istDC
        ImADAutorisiert  = $istAutor
        AktiveBereiche   = $bereiche
        LetztesUpdate    = $letztesHF.HotFixID
        UpdateDatum      = $letztesHF.InstalledOn
        JuliPatchDrin    = $gepatcht
        Risiko           = $risiko
    })
}

$ergebnis | Sort-Object Risiko | Export-Csv -Path $ReportPath -NoTypeInformation -Encoding UTF8 -Delimiter ';'

Write-Host ''
Write-Host '=== DHCP-Exposure ===' -ForegroundColor Cyan
$ergebnis | Format-Table Server, IstDomainCtrl, AktiveBereiche, UpdateDatum, JuliPatchDrin, Risiko -AutoSize

$kritisch = @($ergebnis | Where-Object Risiko -eq 'KRITISCH')
if ($kritisch.Count -gt 0) {
    Write-Host ''
    Write-Host "$($kritisch.Count) DHCP-Server ohne Juli-Patch laufen auf einem Domain Controller." -ForegroundColor Red
    Write-Host "Diese Systeme gehoeren heute gepatcht." -ForegroundColor Red
}

# Nicht autorisierte Server mit aktivem DHCP-Dienst = Rogue-Verdacht
$rogue = @($ergebnis | Where-Object { -not $_.ImADAutorisiert -and $_.DienstStatus -eq 'Running' })
if ($rogue.Count -gt 0) {
    Write-Host ''
    Write-Host "Achtung: DHCP-Dienst laeuft auf nicht autorisierten Systemen:" -ForegroundColor Yellow
    $rogue.Server | ForEach-Object { Write-Host "  - $_" -ForegroundColor Yellow }
}
Write-Host ''
Write-Host "Bericht: $ReportPath" -ForegroundColor Cyan

Hinweis: Get-HotFix liefert bei manchen Server-Builds ein unvollständiges Bild, weil kumulative Updates über die Component-Based-Servicing-Kette laufen. Als schnelle Gegenprobe eignet sich die Build-Nummer aus (Get-CimInstance Win32_OperatingSystem).Version im Vergleich mit der KB-Dokumentation eurer Server-Version.

Schritt 2: Patchen – und zwar priorisiert

Bei 600 CVEs in einem Monat funktioniert die alte Regel »alles einspielen, dann ist gut« nicht mehr als Priorisierungsstrategie. Sie funktioniert als Ziel, aber nicht als Reihenfolge. Die Reihenfolge, die sich in der Praxis bewährt:

1 Aktiv ausgenutzte Lücken, unabhängig vom CVSS-Wert. Ein CVSS von 5.3, das gerade angegriffen wird, ist dringender als eine 9.8 ohne Exploit.
2 Unauthentifizierte RCE auf Diensten, die im internen Netz breit erreichbar sind – DHCP, RDP, Netzwerktreiber. Genau hier stehen die vier oben genannten CVEs.
3 Alles auf Systemen mit Internet-Exposition.
4 Der Rest im regulären Wartungsfenster.

Ein Neustart des DHCP-Dienstes bedeutet übrigens keinen Ausfall für bestehende Clients: Vorhandene Leases bleiben gültig, erst die Erneuerung braucht den Server wieder. Bei üblichen Lease-Zeiten von acht Tagen ist ein Patchfenster von 20 Minuten praktisch unsichtbar. Das ist ein Argument, das in der Diskussion mit dem Fachbereich hilft.

Schritt 3: Die Angriffsfläche dauerhaft verkleinern

Der Patch ist die Pflicht. Die Kür ist, dass die nächste DHCP-Lücke – und die kommt – weniger schlimm ist.

DHCP vom Domain Controller trennen. Das ist die wirksamste Maßnahme und gleichzeitig die, die am seltensten umgesetzt wird, weil sie Arbeit macht. Zwei kleine dedizierte VMs mit DHCP-Failover kosten wenig Ressourcen und nehmen dem Thema dauerhaft die Schärfe. Wer das Tier-Modell ernst nimmt, hat auf einem Tier-0-System ohnehin keine Rolle zu suchen, die unauthentifizierten Netzwerkverkehr verarbeitet.

Netzsegmentierung prüfen. Aus welchen VLANs erreichen Pakete den DHCP-Server? Gäste-WLAN, Drucker-Netz und OT-Segmente sollten über Relay-Agents laufen, nicht direkt broadcasten. Damit reduziert sich die Zahl der Systeme, die den Dienst überhaupt ansprechen können, erheblich.

Rogue-DHCP-Überwachung einrichten. Wenn das Skript oben nicht autorisierte Server mit laufendem DHCP-Dienst findet, ist das unabhängig von diesen CVEs ein Befund. Ein DHCP-Server, von dem niemand weiß, ist selten harmlos.

Monitoring auf Dienstabstürze. Ein fehlgeschlagener Exploit-Versuch gegen einen Heap-Overflow endet häufig in einem Absturz des Dienstes, bevor er in einer erfolgreichen Ausführung endet. Wiederholte unerwartete Neustarts des DHCP-Server-Dienstes (Event-ID 7031/7034 im System-Log) sind ein Signal, das nicht in einem Rauschen untergehen sollte.

Fazit

Der Juli 2026 hat gezeigt, wohin die Reise geht: Die Zahl der gemeldeten Schwachstellen steigt schneller, als klassisches Patch-Management sie abarbeiten kann – nicht zuletzt, weil Schwachstellensuche zunehmend automatisiert und KI-gestützt abläuft. Wer weiterhin nach dem Prinzip »alles am zweiten Dienstag« arbeitet, verliert die Fähigkeit zu erkennen, was davon wirklich dringend ist.

Zwei unauthentifizierte 9.8er-RCEs in einem Dienst, der auf vielen Domain Controllern mitläuft, sind dringend. Auch wenn sie in diesem Monat niemand auf die Titelseite gesetzt hat.