CVE-2026-33824 is a critical remote code execution flaw in the Windows Internet Key Exchange (IKE) Service Extensions, the component behind IPsec VPN negotiation. It affects all supported releases of Windows 10, Windows 11 and Windows Server.

It is a double free, reachable by an unauthenticated attacker sending crafted packets to UDP port 500 or 4500. No credentials, no privileges, no user action. Microsoft's advisory puts the precondition simply: a Windows machine with IKE version 2 enabled.

The bit that should move your week

CISA added it to the Known Exploited Vulnerabilities catalogue on 18 August 2026 and gave federal civilian agencies 3 days to patch under Binding Operational Directive 26-04.

Three days is not the normal figure. KEV additions typically carry around 21 days, and the shortened deadline is the clearest signal CISA has for "this is being used right now and it is not hard". Nobody compresses a government-wide patch mandate by a factor of seven for something theoretical.

You are not a federal agency, and the deadline is still the useful number. It is CISA telling you what it thinks of the risk in the only unit that cannot be spun.

Patched in April, exploited in August

Microsoft shipped the fix in April 2026 Patch Tuesday, and did not mark it as exploited at the time.

That gap is the ordinary shape of this now. A vulnerability is disclosed and patched quietly, sits in the pile with the hundred-odd other CVEs from that month — April's neighbour, August, carried 398 by Microsoft's count — and four months later somebody works out how to use it against everyone who never got round to it.

The same sequence produced the Kemp LoadMaster flaw landing in KEV and 8,500 SharePoint servers still exposed after ransomware started using theirs. The patch existing has never been the same thing as the patch being applied.

Why this one is worse than most

Because of where IKE sits.

The component listens on the edge. UDP 500 and 4500 are how IPsec VPN endpoints find each other, which means the vulnerable service is, by design, exposed to the internet on exactly the boxes you least want compromised: VPN concentrators, RRAS servers, gateway machines. These are not workstations behind three layers of segmentation. They are the layer.

And a double free is a memory-corruption bug, so successful exploitation lands as code execution in the service's context — on a machine whose whole job is terminating trusted tunnels.

What to do

  • Patch, and check you actually did. The fix is from April, so this may already be applied — verify rather than assume, particularly on servers that are excluded from the normal ring because they are load-bearing.
  • Block inbound UDP 500 and 4500 where IKE is not used. Most Windows servers are not VPN endpoints and have no reason to answer on those ports at all.
  • Where IKE is used, restrict it to known peers. Firewall the two ports to your actual VPN peer addresses rather than to the world. This is a config change, not a project.
  • Inventory what is listening. The uncomfortable version of this task is finding out which machines have IKEv2 enabled that nobody meant to enable it on.
  • Treat a VPN endpoint compromise as a credential incident too. Code execution on the box that terminates tunnels is not a contained event.

What is not established

  • Who is exploiting it. CISA confirms exploitation without naming an actor.
  • How it is being used. No campaign, payload or victim has been publicly tied to it.
  • How many systems are exposed. No scan count has been published.
  • Why the reclassification took until August. Microsoft did not flag exploitation in April; what changed between April and CISA's listing has not been explained publicly.