"Exploitation Less Likely": 126 days in the queue for CVE-2026-33824

On 18 August, CISA added CVE-2026-33824 to its catalogue of exploited vulnerabilities. Microsoft had patched it on 14 April, with a label beside it: Exploitation Less Likely. This morning, two days after CISA said otherwise, that page still says exactly what it said in April.

The flaw, in two paragraphs

The official entry is titled "Windows Internet Key Exchange (IKE) Service Extensions Remote Code Execution Vulnerability" and the description fits on one line: "Double free in Windows IKE Extension allows an unauthorized attacker to execute code over a network." CVSS 9.8. CWE-415. The question in Microsoft's FAQ is answered by Microsoft itself: "An unauthenticated attacker could send specially crafted packets to a Windows machine with Internet Key Exchange (IKE) version 2 enabled, which could enable remote code execution." The ports are UDP 500 and 4500, the usual IPsec pair.

The technical detail was published by the Zero Day Initiative on 23 April, by Richard Chen and Lucas Miller: while reassembling a fragmented IKE_AUTH message, a pointer to a Security Realm blob — one the attacker has had allocated through the preceding IKE_SA_INIT — is shallow-copied from the MMSA structure into a heap work item, and ends up being freed twice, once in IkeDestroyPacketContext and once in IkeFreeMMSA. The result, in their words: "Successful exploitation could result in a crash of the IKEEXT service, or potentially arbitrary code execution", and the service runs as SYSTEM.

It is worth holding on to where this happens: during packet reassembly. Before anyone has proven they are anyone. If your VPN asks for a second factor, that second factor lives behind an exchange the attacker never has to finish. Same for machine certificates and pre-shared keys. Authentication is not failing here: the flaw sits in front of it.

The label

Microsoft's exploitability index has four rungs. The one this CVE was given, Exploitation Less Likely, is defined on the MSRC site as: "[w]hile exploit code could be created, an attacker would likely have difficulty creating the code, requiring expertise and/or sophisticated timing, and/or varied results when targeting the affected product." The temporal vector on the page says it in shorthand: E:U, exploit unproven.

That label is not meant to be eternal, and Microsoft says so plainly: the index exists to "help customers prioritize those updates for the most current monthly release", and assessments may be revised during the first month but not afterwards, because past that point "it is no longer useful to the customer". That is a defensible position for a vendor. The problem shows up at the other end: the entry stays frozen, half the world's patch inventories read it over an API, and an April snapshot becomes a permanent verdict.

So we went and counted

We got curious, so we went through the whole thing this morning. We crossed CISA's KEV catalogue with Microsoft's Security Update Guide API. So far in 2026, CISA has added 35 Microsoft entries; we kept the 24 that are 2025 and 2026 CVEs — the rest are 2012-or-older flaws, plus three from 2023 and 2024 we left out so as not to mix vintages. Of those 24:

The 126 is ours. The 153 is CVE-2025-60710, published on 11 November 2025 and added to KEV on 13 April 2026. And there are four CVEs on that list scoring 9 or above that were not marked as exploited on patch day; three of them carry a 9.8.

Before drawing big conclusions, the caveat this number demands: it is a numerator without a denominator. We do not know how many Less Likely CVEs Microsoft published over the same period and never saw exploited, and they are the overwhelming majority. The table does not say "the label is often wrong". It says something else, more uncomfortable and more useful: when the label is right, it gives you no lead time — a median of zero days between patch and KEV, because Microsoft already knew it was happening when it published — and when it does give you lead time, that is because it knew nothing. As information it is sound. As a queue order, it orders nothing.

The 126 days, with dates

The headline of the Unit 42 campaign is the AI agent, and fair enough: that makes a front page. But go down to the line for this particular CVE and the report files it under manual campaigns: FOFA enumeration, Python scanners and hands-on exploitation. A patch left unapplied for weeks was enough here.

The two mitigations, and the one you cannot apply

Microsoft offers two ways out for anyone who cannot install the update: "Block inbound traffic on UDP ports 500 and 4500 for systems that do not use IKE" and "For systems that require IKE, configure firewall rules to allow inbound traffic on UDP ports 500 and 4500 only from known peer addresses." And it adds, rightly, that neither replaces the patch.

The first one is clean and should be applied today: if a server does not terminate tunnels, those two ports have no business facing the internet. The second works nicely for site-to-site tunnels, where the far end is a fixed address you know. And it leaves out precisely the case that hurts a small company: remote access. A salesperson connecting over hotel 4G has no "known peer address". That allow-list cannot be written. This is our reading, not a quote from anyone, but we cannot find a way around it: if you publish IKEv2 remote access to the internet, your mitigation is the April patch and there is nothing else.

With one exception: if your users always come in from four known offices, the allow-list does work, and works well. It is genuine remote work — the kind with home IP addresses that keep changing — that ends up without a net.

Half an hour, in this order

• Who is listening. On every exposed Windows box: Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress, LocalPort, OwningProcess and Get-Service IKEEXT. The service ships with every supported version; what you need to find out is whether anything is actually listening on it.
• From outside. An nmap -sU -p 500,4500 against your public addresses, knowing UDP scanning lies by nature: "no response" does not mean "closed". If it comes back open, it is open.
• The patch. It is cumulative: any cumulative from 14 April 2026 onwards carries it. Check the date of the last one you installed; if it predates that, you have your answer. The MSRC entry lists the right KB for each version.
• What should not be there. Every port 500 and 4500 left open on a server that terminates no tunnels gets closed today, no debate.
• If you have something watching the traffic, ZDI publishes the only detection rule we have seen for this, and it is not trivial because two packets have to be correlated: "Detection requires correlating two packets within the same IKE session: an IKE_SA_INIT request carrying the Microsoft Security Realm Vendor ID, followed by a fragmented IKE_AUTH request. Neither packet alone is malicious; both must be observed in sequence from the same source." Neither of them, on its own, will raise an alert.

And an architecture question for after the fire drill, which is where this is actually won: if your VPN concentrator is a domain-joined Windows server published to the internet, every flaw of this kind costs you a Sunday. On choosing a tunnel we wrote a WireGuard versus IPsec comparison, and on what happens when the perimeter box itself is the thing that breaks, the SonicWall SMA 1000 zero-days.

When we would not rush

We will declare the conflict of interest up front: we sell managed network and security services, and a piece like this suits us. With that on the table: if your Windows machines do not publish 500 or 4500 to the internet, this is not an emergency. It is a patch for the normal window, the next scheduled maintenance, with nobody pulled off holiday. The 21 August deadline is an obligation for US federal agencies, not a yardstick for you — we wrote about that a few days ago. Rebuilding the whole concentrator in August because a headline was scary usually goes worse than applying a cumulative update.

What stays

The flaw was fixed in April. What has not been fixed is the line describing it, and that line is what many teams use to decide what gets patched on Tuesday and what waits for the quarter. A 9.8 and a "less likely" on the same screen are not two data points: they are two contradictory pieces of advice, and the second one has the advantage of sounding reassuring.

The question that is left is a simpler one, and it is about your queue: of the patches you have parked right now, how many are parked because something — a console, a report, an inherited line of text — said it was unlikely?

Sources (verified on 20 August 2026): the official CVE title, the 14 April 2026 release date, the critical severity, the 9.8 CVSS score, the vector carrying E:U, the "Exploitation Less Likely" label, the "Exploited: No" field, the last-revision date and the FAQ and mitigation sentences quoted verbatim, from the CVE-2026-33824 entry in Microsoft's Security Update Guide, queried through its API on 20 August at 08:05. The exploitability index definitions and the policy of not revising it after the first month, from the MSRC Exploitability Index page. The catalogue entry date (18 August), the 21 August deadline and the description, from CISA's KEV catalogue, version 2026.08.19. The double-free analysis, the function names, the two-correlated-packets detection rule and the sentence "Successful exploitation could result in a crash of the IKEEXT service, or potentially arbitrary code execution", from the Zero Day Initiative analysis by Richard Chen and Lucas Miller. The sentence "Reverse shell callbacks targeting three IKE VPN endpoints (CVE-2026-33824)", the 460-plus targets and the use of FOFA and Python scanners for this particular case, from Unit 42's report of 30 July 2026. Ours: the count of the 35 Microsoft KEV entries in 2026 and the 24 from 2025 and 2026, with their labels and their days-to-KEV, done by crossing both sources this morning; ours too is the reading that a "known peer addresses" allow-list cannot be written for remote access, and it is declared as a reading in the text. Quotes from Microsoft, ZDI and Unit 42 are left in English, their original language, so they can be verified word for word.