Microsoft patched this one months ago.
Attackers are only now making noise with it.
CVE-2026-33824 is a critical remote-code-execution vulnerability in the Windows Internet Key Exchange (IKE) Service Extensions component. CISA added it to its Known Exploited Vulnerabilities catalog after confirming active exploitation. The bug carries a CVSS score of 9.8.
- The Mess: A double-free bug in Windows IKE Extension lets an unauthenticated attacker send specially crafted network packets and potentially execute code remotely on vulnerable Windows systems. The attack works through IKE traffic on UDP ports 500 and 4500.
This is the kind of vulnerability that makes network defenders stop scrolling.
There is no username requirement.
No password.
No phishing email.
No malicious attachment.
The attacker sends specially crafted packets to a vulnerable Windows machine and tries to trigger memory corruption inside the IKE service.
IKE is not some random Windows feature that nobody uses. It is part of the infrastructure behind IPsec and VPN connectivity. Systems running Windows-based VPN or IPsec configurations can therefore expose the vulnerable component directly to network traffic.
And that creates a nasty attack surface.
The vulnerability is a double-free condition. In simple terms, the same memory can end up being released more than once. That can corrupt the process and, under the right conditions, give an attacker control over execution.
Microsoft rates the flaw as critical with a CVSS score of 9.8. NIST’s vulnerability record describes it as allowing an unauthorized attacker to execute code over a network.
The really bad part?
The attack does not require authentication.
- What Actually Happened: Microsoft fixed CVE-2026-33824 in its April 2026 security updates, but CISA added the vulnerability to its KEV catalog on August 18 after confirming that attackers were exploiting it in the wild.
That four-month gap is interesting.
The patch existed.
The vulnerability was documented.
Systems remained unpatched.
Then attackers started using it.
This is exactly why “we patch monthly” can be an inadequate security strategy when a vulnerability suddenly becomes actively exploited.
The Windows IKE component can be particularly interesting to attackers because VPN and IPsec infrastructure is normally exposed for a reason. Remote users and remote networks need to reach it.
You cannot simply hide every VPN endpoint behind another VPN.
That’s the point of the service.
The vulnerable traffic uses UDP 500 and 4500, which are standard ports associated with IKE and NAT traversal for IPsec. If a Windows host is configured as an IKE responder, those ports can become part of its externally reachable attack surface.
That means perimeter devices deserve immediate attention.
VPN servers.
Remote-access infrastructure.
Windows servers running IPsec policies.
DirectAccess deployments.
Always On VPN environments.
Anything using Windows IKE should be inventoried.
Microsoft’s own security research describes the vulnerability as a pre-authentication RCE in ikeext.dll, with the vulnerable service running in a highly privileged context.
That’s a particularly ugly combination.
Remote.
Unauthenticated.
Memory corruption.
High privileges.
Network-facing.
Pick any one of those and you have a security problem.
Put them together and you have an incident waiting to happen.
- The Damage: Successful exploitation could give an unauthenticated remote attacker code execution on a vulnerable Windows system, potentially turning a VPN or IPsec endpoint into an entry point for deeper network compromise.
The attacker does not necessarily need the compromised machine to contain valuable files.
The machine’s position may be enough.
A VPN endpoint sits at the edge of the network. It can have access to internal services, authentication infrastructure and other systems that are invisible from the public Internet.
Compromise the edge and you may have a route inside.
That is why network appliances and remote-access servers are such attractive targets.
The vulnerability also demonstrates why a firewall rule is not a substitute for patching.
If you actually need IKE exposed, you still have to assume hostile traffic will reach it.
If you do not need IKE, blocking the relevant ports can reduce exposure.
But neither approach replaces the security update.
And if you have already exposed an unpatched system to the Internet, patching should not automatically end the investigation.
Check logs.
Review unusual VPN activity.
Look for unexpected processes.
Look for suspicious outbound connections.
Check whether administrative accounts changed.
The vulnerability has been actively exploited, so “nothing looked weird” is not evidence that nothing happened.
- The Fix: Install Microsoft’s security update that fixes CVE-2026-33824 immediately, and if IKE is not required, block inbound UDP 500/4500 or restrict those ports to known VPN peers.
Do not disable Windows IKE blindly if your environment depends on IPsec or VPN connectivity.
First determine what actually uses it.
Then patch.
For organizations with large Windows fleets, this is also a good time to verify that the April and subsequent cumulative updates really reached every relevant server. “Our patch system says compliant” is useful. Manually verifying high-value VPN infrastructure is better.
CISA’s KEV listing exists specifically because exploitation has been observed in the real world. This is no longer a vulnerability you can rank based purely on a CVSS spreadsheet.
Bugstoday Verdict: A 9.8 RCE sitting on VPN infrastructure is bad. A 9.8 RCE with confirmed exploitation is worse. The patch has existed since April. There is no good reason to still be running vulnerable IKE servers in August.
