Windows IKE CVE-2026-33824: The AI Ran Recon, a Human Pulled the Trigger

On August 18, 2026, CISA added CVE-2026-33824 — a pre-authentication remote code execution flaw in the Windows Internet Key Exchange (IKE) service — to its Known Exploited Vulnerabilities catalog and set federal agencies a three-day patch deadline under BOD 26-04. That much is a routine bad day. What makes this one worth reading is where the exploitation was found: inside a single campaign that Palo Alto Networks Unit 42 attributes to a Chinese-speaking operator who wired a DeepSeek model to the front of his kill chain and let it hunt, triage, and attack on its own. The autonomous half of that campaign compromised nothing. The IKE endpoints fell to the human. The gap between those two facts is the story.

What CVE-2026-33824 actually is

The vulnerability is a double free in the Windows IKE Extension (ikeext.dll), the service that negotiates IPsec VPN tunnels. An unauthenticated attacker sends specially crafted packets to a host with IKEv2 enabled on UDP 500 or 4500, frees the same heap allocation twice, and turns the resulting memory corruption into code execution over the network. No credentials, no user interaction, no foothold required — the listening service does the work.

Microsoft rates it CVSS 9.8, and several trackers flag it as wormable, because the preconditions (an internet-reachable IKE responder) are exactly the kind of thing that repeats across a fleet. Affected builds are broad: Windows Server 2016 through 2025 (including 2022 23H2), Windows 10 from 1607 to 22H2, and Windows 11 from 23H2 to 26H1 — anything running the IPsec IKE service, per the BleepingComputer report.

The uncomfortable timeline detail: Microsoft shipped the fix in the April 2026 Patch Tuesday. The exploitation Unit 42 observed and the KEV listing came four months later. This is the same pattern as every other "patched in spring, breached in summer" post on this blog — the patch existed; the exposed IKE responders did not get it.

One actor, two hands: what Unit 42 saw

Unit 42 tracked the operator under the aliases "knaithe" / "KnYuan", a self-described "binary security researcher" based in Zhuhai, China. He ran the campaign as two parallel workflows, and the split is the whole point.

The autonomous strand used DeepSeek as the reasoning engine behind Hermes Agent, an open-source framework that can drive an OS terminal, run commands, and reach the internet. Orchestrated over Telegram, the agent enumerated targets and their weaknesses through the FOFA internet-scanning service, selected from seven CVEs (in software including Langflow, n8n, and Citrix NetScaler), and attempted end-to-end exploitation against more than 460 targets — on its own, per the Unit 42 analysis and BleepingComputer's write-up. DeepSeek was reportedly chosen because it had the fewest guardrails to talk around.

The manual strand — the same operator, hands on keyboard — went after known bugs in Citrix NetScaler, Apache Tomcat, Marimo Notebook, and Windows IKE VPN endpoints. This is where CVE-2026-33824 shows up: Unit 42 recorded reverse-shell callbacks against three IKE VPN endpoints. Three manual intrusions succeeded overall, and all three were the same bug — CVE-2026-3055 in Citrix NetScaler, not the IKE flaw.

	Autonomous strand (DeepSeek + Hermes)	Manual strand (hands on keyboard)
Target selection	FOFA scanning, agent-driven	Operator-chosen
CVEs used	7 (Langflow, n8n, NetScaler, …)	NetScaler, Tomcat, Marimo, Windows IKE
Targets touched	460+	460+
Successful compromises	0	3 (all CVE-2026-3055)
CVE-2026-33824 activity	—	reverse-shell callbacks to 3 IKE endpoints

Why "the AI compromised nothing" is the wrong headline

It is tempting to read the score — autonomous strand: 460 attempts, zero wins — as reassurance. It is the opposite. The agent did not fail at the hard part; it was never assigned the hard part. It did the recon, the fingerprinting, the CVE-to-target matching, and the first exploitation attempt — the tedious, high-volume top of the funnel that used to gate an attacker's throughput. The delicate memory-corruption work, like landing a double-free on a live IKE responder, still went to a human.

"Show me a scanner that finds my exposed NetScaler and IKE endpoints, ranks them by which CVE is most likely to land, and drafts the first payload — and I'll take the three that need a steady hand myself."

That is the workflow Unit 42 documented, and they were blunt about the significance: even with limited impact, it "confirms a functional, end-to-end autonomous offensive capability." The number that should worry a defender is not 3 compromises. It is 460 targets triaged by one person in a few days — a reconnaissance-and-selection tempo that a solo operator could never sustain by hand, now available to anyone who can point an unguarded model at FOFA.

The exposure math changes accordingly. When triage was human-limited, an internet-facing IKE responder that had missed the April patch might sit unnoticed for months — attackers had to choose where to spend attention. When triage is an agent running around the clock, every exposed responder is found and queued on the first pass. The window between "you forgot to patch one host" and "someone is sending it crafted IKE packets" collapses.

The IKE extension is a recurring wound

CVE-2026-33824 is not a novel surface — it is the latest entry in a pattern. Zero Hunt's own knowledge base surfaces a cluster of prior IKE Extension memory-corruption bugs the moment you query this one: the September 2022 batch of network RCEs (CVE-2022-34721 / 34722 / 21843 / 21849), all reachable over the same UDP 500/4500 IKE surface, plus the 2023 elevation-of-privilege and denial-of-service issues (CVE-2023-36726, CVE-2022-34720). The IKE responder has been a reliable source of pre-auth memory bugs for years.

The defensive lesson from that history is concrete: the IKE/IPsec service should almost never be a general-internet-facing listener. Most organizations expose it because a VPN concentrator or a Windows RRAS box was stood up years ago and nobody revisited whether UDP 500/4500 needed to answer the whole world. The patch closes this instance; reducing the attack surface closes the class.

Remediation

A complete runbook for CVE-2026-33824. If you run Windows hosts with IPsec/IKEv2 enabled and reachable, treat this as active-exploitation priority, not next-cycle maintenance.

1. Am I affected?

Any supported Windows 10/11 or Windows Server build with the IKE Extension service running and IKEv2 reachable is in scope. Check for exposure:

# Is the IKE service running?
Get-Service IKEEXT | Select-Object Status, StartType

# Anything listening / responding on the IKE ports?
Get-NetUDPEndpoint -LocalPort 500,4500 -ErrorAction SilentlyContinue

# Is an IPsec/IKEv2 connection actually configured?
Get-NetIPsecMainModeSA; Get-VpnServerConfiguration -ErrorAction SilentlyContinue

From outside, confirm whether UDP 500/4500 answer from untrusted networks — an exposed responder is the precondition for pre-auth exploitation.

2. Patch — the exact fix

Microsoft fixed CVE-2026-33824 in the April 2026 Patch Tuesday cumulative updates for all supported Windows 10, Windows 11, and Windows Server releases. Verify the host has an April 2026 or later cumulative update installed; confirm the specific KB for your build against the Microsoft advisory for CVE-2026-33824. If a system reports an earlier patch level, it is vulnerable regardless of whether the VPN "seems fine."

3. Can't patch now? — compensating controls

• Restrict IKE at the edge. Filter UDP 500 and 4500 so they only answer known peer IPs; the IKE responder should never be a general-internet listener.
• Disable IKEv2 where it is not used. If a host runs IKEEXT only as a default, and no IPsec tunnel depends on it, stop and disable the service.
• Terminate VPN elsewhere. Front Windows IPsec endpoints with a hardened concentrator or firewall that does the internet-facing IKE negotiation, so the vulnerable stack is not the first thing a packet reaches.

4. Hunt for compromise

The manual strand left network artefacts, not just host ones. Map hunting to MITRE ATT&CK:

• Exploitation (T1190 — Exploit Public-Facing Application): malformed or oversized IKE_SA_INIT / IKE_AUTH packets, IKE service crashes or IKEEXT restarts correlated with inbound UDP 500/4500 from unfamiliar ASNs.
• C2 / reverse shell (T1071, T1571 — Application/Non-Standard Port C2): outbound connections from a VPN/IPsec host that historically only received IKE traffic. Unit 42 observed reverse-shell callbacks from compromised IKE endpoints — treat any egress initiated by the IKE service context as hostile until proven otherwise.
• Recon fingerprint (T1595 — Active Scanning): high-tempo, broad UDP 500/4500 probing consistent with FOFA-style enumeration; a burst of IKE handshakes across many hosts from one source in a short window is the automated-triage signature.
• Tooling transfer / execution (T1105, T1059): unexpected process creation under System following IKE activity; new binaries dropped to C:\Windows\Temp or \ProgramData on VPN gateways.

5. Eradicate and verify

Patching a box that already made a callback does not evict the intruder. After patching:

1. Isolate any host that shows outbound connections tied to the IKE service context.
2. Hunt for and remove implants, scheduled tasks, and new local accounts on VPN/IPsec gateways.
3. Rotate credentials and IPsec pre-shared keys / certificates that lived on or transited an exposed endpoint — assume they are burned.
4. Re-scan from the outside to confirm UDP 500/4500 no longer answer untrusted networks, and confirm the April 2026 patch level after remediation, not before.

Where Zero Hunt fits

The lesson of this campaign is not "an AI popped an IKE box" — it didn't. It is that an adversary just automated the tempo of offense: continuous, agent-driven discovery and triage of every exposed responder, at a scale one operator could never reach by hand. A quarterly pentest and a monthly vulnerability scan do not answer that. You cannot match an attacker who re-triages your entire perimeter every night by re-testing yours every ninety days.

That is the exact gap the Zero Hunt platform was built to close, and it is why our answer here leads with the offensive engine rather than the sensor. Zero Hunt runs a 10-agent generative pentest swarm — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic and Report agents under an AI Controller — that does to your estate what knaithe's Hermes Agent did to his target list: continuously enumerate exposure, match it against a threat-intel corpus synced from 21 sources (CISA KEV, NVD, EPSS, ExploitDB and more), and actually attempt the chain with a per-target exploit written by a local LLM, not a canned script. New asset on the perimeter, or a host that slipped an April patch, triggers a full campaign within the hour via change-triggered scheduling — the same "found on the first pass" tempo, working for the defender. Every new offensive skill is backtested in the AI Gym against Vulhub and CVE black-box corpora before it touches production, so the engine that probes your IKE responders is validated, not improvised.

The traffic side is the second layer for exactly the artefacts in the Remediation hunt. Zero Hunt's AI Traffic Analysis — a deep-learning model with four inference heads running on the appliance GPU — is built to flag the reverse-shell callback from a host that historically only answered IKE, the egress on a never-before-seen path, the C2 beacon that signature-based NDR misses, while it is happening rather than in the next morning's SIEM digest. When an autonomous adversary compresses the time from exposure to callback to minutes, a detection layer that reads intent from behaviour — not from a matched signature — is what closes the loop. Both run 100% on-prem, no cloud callbacks, which matters when the thing you are hunting is itself an AI on the other side of the wire.