Skip to content

Cybersecurity · Vulnerability Management

CVE-2026-33824: The Windows IKE Bug That Needs No Credentials, Just a Packet

A double-free in Windows' IKE Service Extensions lets an attacker get remote code execution with a crafted UDP packet, no authentication, no user interaction. CISA confirmed active exploitation with a patch deadline of August 21. Here's what's affected and how to close it fast.

Prathviraj Singh

Prathviraj Singh

5 min read

CVE-2026-33824: The Windows IKE Bug That Needs No Credentials, Just a Packet

Sponsored

Share

An attacker doesn’t need a password, a phishing click, or any foothold at all to exploit CVE-2026-33824. They need one crafted packet aimed at UDP port 500 or 4500 on a Windows machine running IKE Service Extensions, which is most of them, because IKE ships as part of the core Windows networking stack rather than an opt-in feature. CISA confirmed active exploitation and gave federal agencies until August 21 to patch. If your fleet includes Windows Server or Windows 10/11 with IKE reachable from any untrusted network, that same date should be your deadline too.

What the bug actually does

IKE, Internet Key Exchange, is the protocol Windows uses to negotiate encrypted VPN tunnels. Setting one up starts with an IKE_SA_INIT exchange, and that exchange supports fragmentation for handling larger payloads across multiple packets. CVE-2026-33824 lives in how that fragment reassembly is implemented.

According to the Zero Day Initiative’s technical writeup, a Security Realm Vendor ID payload during IKE_SA_INIT causes IkeHandleSecurityRealmVendorId() to allocate a heap blob and store a pointer to it in the MMSA (main mode security association) structure. The fragment reassembly path then shallow-copies that blob pointer rather than tracking ownership correctly. The result: when MMSA cleanup runs, the same memory region gets freed twice.

IKE_SA_INIT exchange begins
  → Security Realm Vendor ID payload received
  → IkeHandleSecurityRealmVendorId() allocates a heap blob, stores pointer in MMSA
  → Fragment reassembly shallow-copies the blob pointer (doesn't track ownership)
  → MMSA cleanup runs
  → Same memory freed twice → heap corruption → attacker-controlled RCE primitive

A double-free is a classic memory-corruption bug class: once the same allocation is freed twice, an attacker who can influence what gets allocated into that now-doubly-freed memory region next has a path to corrupting heap metadata or overwriting adjacent objects, which is what turns “the process crashes” into “the attacker controls what runs next.” That’s the difference between a denial-of-service bug and a full remote code execution vulnerability, and CVE-2026-33824 is the latter.

Why this one is especially dangerous

Three things compound here in a way that’s worth calling out plainly:

  • No authentication. The attacker doesn’t need any credentials, session, or prior access.
  • No user interaction. Nobody has to click anything. The vulnerable code path runs automatically as part of processing an incoming IKE negotiation attempt.
  • Broad default exposure. IKE Service Extensions are part of core Windows networking, not a feature most administrators explicitly enabled or would think to check. That means a meaningful number of affected systems are vulnerable by default configuration, not by an unusual setup choice.

That combination, unauthenticated, zero-click, broadly present by default, is the same profile that made past wormable Windows vulnerabilities dangerous: the flaw doesn’t need a human to make a mistake, it just needs network reachability. Any Windows system that accepts inbound UDP 500 or 4500 traffic from an untrusted network is exposed.

What’s affected

Microsoft’s advisory covers every currently supported release of Windows 10, Windows 11, and Windows Server. There’s no version carve-out here the way some CVEs affect only specific feature branches; check your specific build against Microsoft’s advisory for the exact KB to apply, but plan for this to touch your entire Windows fleet, not a subset.

What to do about it

Patch first, everywhere IKE is reachable. This isn’t a “patch the internet-facing systems first, get to the rest later” situation. Internal Windows Server instances that accept IKE traffic from other internal segments are exploitable by anything that’s already gained a foothold anywhere on that network, which is exactly the lateral-movement scenario ransomware operators look for.

If you can’t patch immediately, block the ports. Microsoft’s own interim guidance is straightforward: block inbound UDP 500 and 4500 on any system that doesn’t actually use IKE. For systems that do need it, typically VPN gateways, restrict inbound IKE traffic to known, trusted peer IP addresses via firewall rule rather than accepting it from anywhere. Neither of these substitutes for the patch, but both meaningfully shrink the window of exposure while you roll it out.

Prioritize by reachability, not by role. A workstation with no legitimate reason to accept inbound IKE traffic from the internet is lower risk than an internal server that’s reachable from every other segment in a flat network, even if the server “feels” more protected. Map which systems actually have UDP 500/4500 reachable from where, and patch in that order rather than by asset criticality alone.

This is the second unauthenticated, zero-click Windows or Windows-adjacent networking flaw to land on CISA’s KEV list in the last two weeks alongside the Cisco ASA and FTD VPN vulnerability, which is worth noticing as a pattern: VPN and tunnel-negotiation code paths, IKE, IPsec, SSL VPN stacks, keep surfacing as a soft spot across vendors this year, not because any one vendor is uniquely careless, but because that code handles untrusted input by definition, before authentication happens, which is exactly where these bug classes cluster.

The takeaway

CVE-2026-33824 is about as close to a worst-case CVE profile as this class of bug gets: unauthenticated, zero-click, broadly present by default, and already under active exploitation with a compressed patch window. If your patch management process treats “internal-only” as equivalent to “lower priority,” this is a good moment to reconsider that assumption, since the exploitability here has nothing to do with internet exposure and everything to do with network reachability from wherever an attacker already stands. If you need help mapping actual IKE exposure across a mixed on-prem and cloud fleet before the deadline, that kind of exposure audit is part of the infrastructure security work our team does under time pressure.

Frequently asked questions

What is CVE-2026-33824?
It's a double-free vulnerability in Windows' Internet Key Exchange (IKE) Service Extensions. During IKE_SA_INIT fragment reassembly, a heap-allocated blob pointer gets shallow-copied rather than properly tracked, which causes the same memory to be freed twice during cleanup, a memory corruption bug an attacker can turn into remote code execution.
Do I need to be authenticated to exploit this?
No. This is an unauthenticated, remote vulnerability. An attacker sends a maliciously crafted packet to UDP port 500 or 4500 on a vulnerable Windows system, and no valid credentials, prior access, or user interaction of any kind are required to trigger it.
Which Windows versions are affected?
All currently supported releases of Windows 10, Windows 11, and Windows Server are affected, since IKE Service Extensions ship as part of the core networking stack rather than an optional add-on. Check Microsoft's advisory for your specific build to confirm the exact patch to apply.
Is CVE-2026-33824 being actively exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalog on August 18, 2026, based on confirmed evidence of active exploitation, and set a remediation deadline of August 21, 2026, for federal civilian agencies under Binding Operational Directive 26-04.
What can I do if I can't patch by the deadline?
Microsoft's own interim guidance is to block inbound traffic on UDP ports 500 and 4500 for any system that doesn't actually use IKE, which removes the exploitable surface entirely for machines with no legitimate need for it. For systems that do need IKE (VPN gateways and similar), restrict inbound IKE traffic to known, trusted peer IP addresses via firewall rules until you can apply the patch.

Sources

Sponsored

Sponsored

Discussion

Join the conversation.

Comments are powered by GitHub Discussions. Sign in with your GitHub account to leave a comment.

Sponsored