CVE-2026-33826: Windows AD RCE and the Active Directory Exploitation Landscape

– min read

I was going through Microsoft’s April 2026 Patch Tuesday release when one CVE caught my attention — CVE-2026-33826, a critical Remote Code Execution vulnerability in Windows Active Directory. What makes this one interesting is the “Exploitation More Likely” tag Microsoft slapped on it, which means the bad guys are already working on weaponizing it. Let me break down what this flaw is, how it works, and the bigger picture of Windows AD exploitation.

Microsoft Security Response Center: CVE-2026-33826
NVD: CVE-2026-33826
GitHub PoC (CVE-2026-41089): 0xABCD01/CVE-2026-41089


CVE-2026-33826: The Basics

This vulnerability was patched in Microsoft’s April 2026 Patch Tuesday alongside 168 other CVEs. It scores CVSS 8.0 (Critical) and affects every major Windows Server version from 2012 R2 all the way through Windows Server 2025. The flaw lives in the Active Directory component and is classified under CWE-20: Improper Input Validation.

FieldValue
CVE IDCVE-2026-33826
CVSS Score8.0 (Critical)
CWECWE-20 – Improper Input Validation
Attack VectorAdjacent Network
Privileges RequiredLow (Authenticated)
User InteractionNone
ImpactRemote Code Execution (RCE)
ExploitationExploitation More Likely
AffectedWindows Server 2012 R2 through 2025
PatchedApril 2026 Patch Tuesday


Technical Deep Dive

The root cause is straightforward but dangerous — Active Directory fails to properly validate input data within its RPC (Remote Procedure Call) handling mechanisms. An authenticated attacker with low privileges who is already inside the same domain can send specially crafted RPC calls to a vulnerable RPC host running on the target server. The server processes this malformed input without proper sanitization, and the attacker gets code execution with the same permissions as the RPC service.

What makes this particularly dangerous is the attack surface. RPC is the backbone of Windows domain communication. Every domain-joined machine talks RPC with Domain Controllers constantly. An attacker who compromises a single workstation can start probing the DC with malformed RPC calls without raising immediate flags — because RPC traffic between domain members is expected behaviour.


RPC as an Attack Vector: A Quick History

RPC-based attacks against Windows domains have a long and successful track record. Before CVE-2026-33826, we had:

CVEYearTypeImpact
CVE-2020-1472 (Zerologon)2020Netlogon RPC BypassCVSS 10 – Full DC compromise
CVE-2021-1678 (PrintNightmare)2021Spooler RPC RCECVSS 8.8 – RCE + LPE
CVE-2022-26923 (ADCS)2022Certificate RPCCVSS 8.8 – Priv Esc
CVE-2023-21767 (AD LDS)2023RPC DoSCVSS 7.5 – DoS
CVE-2026-338262026AD RPC RCECVSS 8.0 – RCE
CVE-2026-41089 (Netlogon)2026CLDAP Stack OverflowCVSS 9.8 – Unauthenticated RCE


See the pattern? RPC keeps being the attack surface of choice because it is deeply embedded in Windows identity infrastructure. Every new CVE in this space builds on lessons from previous ones, and the mitigation techniques overlap significantly.


CVE-2026-41089: Netlogon CLDAP Stack Buffer Overflow (CVSS 9.8)

While researching CVE-2026-33826, I stumbled onto an even nastier AD RCE that went active in the wild barely a month later. CVE-2026-41089 is a stack-based buffer overflow in the Netlogon service that scores CVSS 9.8 (Critical). Unlike CVE-2026-33826 which requires authentication, this one is completely unauthenticated — send one UDP packet to port 389 and you crash LSASS on the Domain Controller.

The Belgian Centre for Cybersecurity (CCB) confirmed active exploitation in the wild as of June 1, 2026. This is Zerologon-level severity territory — unauthenticated, no user interaction, SYSTEM-level privileges on the DC.


Root Cause Analysis

The bug lives in NlGetLocalPingResponse, a function inside netlogon.dll that handles CLDAP (Connectionless LDAP) DC locator pings. Here is the call chain:

I_NetLogonLdapLookupEx
  -> NlGetLocalPingResponse           # 528-byte stack buffer
    -> LogonRequestHandler
      -> BuildSamLogonResponse
        -> NetpLogonPutUnicodeString   # byte/WCHAR size confusion

NlGetLocalPingResponse allocates a 528-byte stack buffer and passes it down to BuildSamLogonResponse. The problem is in NetpLogonPutUnicodeString — it receives a maximum length parameter in bytes but treats it as a WCHAR count. Since every Unicode character is 2 bytes, every string written through this path actually consumes twice the space the function thinks it is using.

The “User” field in the CLDAP search filter — which the attacker controls — can be up to 130 wide characters (260 bytes on the wire). Combined with the server name, domain name, and GUIDs that are also written into the same 528-byte buffer, the total write easily overflows the stack boundary.


Proof of Concept

A public PoC is available on GitHub that proves the overflow in three phases:

# Phase 1: Normal CLDAP ping with "testuser" to confirm target responds
# Phase 2: Same packet but username = 130 characters of "A"
#          This pushes serialized data past the 528-byte buffer
#          If LSASS crashes -> recv timeout
# Phase 3: Normal ping again to check if DC is alive
#          No response = LSASS confirmed dead

Run it like this:

python3 poc.py 10.0.50.21 corp.local
python3 poc.py 10.0.50.21 corp.local -l 130
python3 poc.py 10.0.50.21 corp.local -l 200 -t 10

The PoC currently demonstrates Denial of Service (LSASS crash, DC reboot in ~60 seconds), but RCE through stack corruption is theoretically possible with additional exploit development.


Detection and Defence

For CVE-2026-33826 (RPC input validation), detection focuses on anomalous RPC traffic to Domain Controllers — specifically crafted RPC calls targeting Active Directory interfaces from non-admin workstations.

For CVE-2026-41089 (Netlogon CLDAP), detection is more straightforward:

LayerDetection Signal
NetworkCLDAP traffic on UDP 389 with User filter > 20-30 characters
HostLSASS crash events (Event ID 1000) tied to netlogon.dll
NetworkUDP 389 traffic to DCs from untrusted subnets
HostNetlogon debug logging via nltest /dbflag:0x2080ffff
NetworkCLDAP searches with abnormally long username attributes


Enable Netlogon debug logging on Domain Controllers:

nltest /dbflag:0x2080ffff


Mitigation

The fix for CVE-2026-33826 is in the April 2026 Patch Tuesday updates. For CVE-2026-41089, patch in the May 2026 Patch Tuesday updates. Server version to patched build mapping:

Server VersionPatched Build
Windows Server 201610.0.14393.9140
Windows Server 201910.0.17763.8755
Windows Server 202210.0.20348.5074
Windows Server 2022 23H210.0.25398.2330
Windows Server 202510.0.26100.32772


If immediate patching is not possible, deploy compensating controls:

# Restrict UDP 389 inbound to only trusted management subnets
# Apply RPC filtering on Domain Controllers
# Monitor Netlogon interface UUID: 12345678-1234-abcd-ef00-01234567cffb
# For legacy systems: 0patch ships micropatches
#   (single instruction fix: mov edx, 0x40 halves max username length)


AD as an Attack Surface: The Bigger Picture

Looking at these two CVEs together paints a clear picture: Active Directory RPC interfaces remain one of the most valuable attack surfaces in enterprise environments. The trend over the last few years shows that Microsoft keeps finding input validation bugs and buffer overflows in the same plumbing code that has been around since Windows 2000.

For penetration testers and red teamers, understanding the AD RPC attack surface is non-negotiable. Tools like Impacket, BloodHound, rpcclient, and CrackMapExec all leverage RPC interfaces for enumeration and exploitation. When a new AD RCE drops, the exploit path almost always goes through RPC.

# Classic AD RPC enumeration with rpcclient
rpcclient -U "" -N 10.0.50.21                          # Null session
rpcclient -U "domain/user%password" 10.0.50.21          # Auth session
rpcclient 10.0.50.21 -c "srvinfo"                      # Server info
rpcclient 10.0.50.21 -c "enumdomusers"                  # Enumerate users
rpcclient 10.0.50.21 -c "enumdomgroups"                 # Enumerate groups
rpcclient 10.0.50.21 -c "querydominfo"                  # Domain info


If you manage Windows infrastructure, patch your Domain Controllers. Both CVEs are serious — one requires auth but is tagged “Exploitation More Likely”, and the other is already being actively exploited in the wild with zero authentication needed. AD is the crown jewels, and these RPC flaws are the skeleton keys.

Mohamad ZulfahmyCybersecurity · OffSec · Entrepreneur
About me ↗
ON THIS PAGE
On this page