A Perfect Ten, and the Word Microsoft Took Back

What actually happened on 20 and 21 August#

A fox does not panic at every snapped twig in the hedgerow. It freezes, reads the wind, and works out whether the sound was a predator or a fallen branch. Most of the internet skipped that second step this week, and the story of why is really a story about vulnerability disclosure policy.

On 20 August 2026, Microsoft disclosed CVE-2026-69836, a flaw in Entra ID, the identity and access management platform formerly called Azure Active Directory that decides who gets into what across Microsoft 365, Azure and a very long tail of connected apps. This was a remote code execution vulnerability of the deserialization kind, catalogued by MITRE as CWE-502, the bug class where a server trusts a malicious blob enough to run it as code. The National Vulnerability Database's own scoring puts it at a full 10.0, the ceiling of the Common Vulnerability Scoring System: network-reachable, low complexity, no privileges and no user interaction required, the worst possible reading on every axis that matters.

That score alone would have earned a scary headline on its own scent. What actually spread the story was one field in Microsoft's own bulletin, the one a sound vulnerability disclosure policy is supposed to govern tightly: Exploited. It initially read Yes.

The one-word correction nobody advertised#

According to The Hacker News, Microsoft's advisory "initially marked the 'Exploited' field as 'Yes'", and corrected it to "No" on 21 August, a single day later, after the outlet contacted the company for comment.

Microsoft's own words, as quoted by that report: "this vulnerability was not exploited in the wild." A company spokesperson added the mitigation line that mattered most to defenders: "We identified and addressed this issue with a fix and released CVE-2026-69836 for greater transparency. There are no additional actions customers need to take."

Sit with that timeline for a second. A maximum-severity score, a claim of active exploitation, a wave of coverage built on that claim, and a correction that landed roughly twenty-four hours later, prompted by a single reporter's question rather than a proactive update under Microsoft's own vulnerability disclosure policy. Most of the trade press had already filed by then.

Most of the sharing on Help Net Security and elsewhere carried the scarier version forward, because a correction rarely travels as fast as the alarm it corrects, and no vulnerability disclosure policy on earth can outrun a headline once it has left the den.

Why the vulnerability disclosure policy matters more than the flaw#

Here is the uncomfortable part for anyone in security marketing, vCISO advisory or GRC reporting. The remote code execution vulnerability itself required almost nothing of you.

Entra ID is a fully managed cloud service, so Microsoft patched its own infrastructure and there was no update to roll out, no configuration to change, nothing to test on a Friday afternoon. The retraction is the part that actually touches your job, because it is a live example of a vendor's severity language moving under a reader's feet, and it is exactly what a vulnerability disclosure policy exists to govern.

A vulnerability disclosure policy sets out what a vendor commits to say, when, and how a correction gets issued once new facts arrive. Microsoft's own vulnerability disclosure policy worked in the narrow sense that the record was fixed within a day. It worked less well in the broad sense that the correction was reactive, not proactive, triggered by a journalist rather than a scheduled review, and it never travelled with the same force as the original claim.

The lesson is not that Microsoft lied. Vulnerability triage under pressure is genuinely hard, and a same-day correction is faster than most vendors manage under their own vulnerability disclosure policy, if they have a written one at all. The lesson is that a claim about exploitation status is working data, not a settled fact, right up until a second, sceptical source has had a chance to check it.

Security marketers who repeat the first number they see, instead of the corrected one, are laundering someone else's mistake into their own credibility. That is exactly the discipline folkfox brings to content marketing for security and compliance clients: cite the primary source, date the claim, and update the piece the moment the vendor does, rather than let a retracted number sit on a page collecting search traffic under false pretences.

The identity and access management market doesn't get to be sloppy either#

Entra ID is identity and access management infrastructure at genuine planet scale, and this remote code execution vulnerability sits squarely inside a category that has grown fast precisely because identity, not the network edge, is where attention has shifted.

That growth has a side effect worth naming plainly. A crowded, well-funded corner of identity and access management attracts vendors who reach for the scariest available framing, because fear converts. A retracted "exploited in the wild" claim from a company as large and as scrutinised as Microsoft is a useful reminder of how easily an unverified severity label becomes marketing copy, and how much damage it does to a smaller vendor's credibility once a customer notices the gap between the claim and the correction.

This is where cloud identity security earns its keep for reasons that have nothing to do with this particular flaw. Microsoft's own guidance was, correctly, that customers of the managed service had nothing to patch. But "nothing to patch" is not the same claim as "nothing to check".

A tenant that was already compromised through some other route would not be un-compromised by Microsoft's server-side fix. Cloud identity security tooling exists precisely to answer the question a vendor's own advisory cannot: did anything unusual happen in your environment in the window before the fix landed. OWASP's own guidance on this bug class, software and data integrity failures, is blunt about it: deserialization flaws are attractive precisely because they let an attacker skip straight past the front gate rather than picking the lock.

What a credible vendor says instead#

None of this is an argument for under-reacting to real severity. A 10.0 is a 10.0, and the fox that never checks the hedgerow gets eaten eventually too. It is an argument for a narrower, more disciplined kind of urgency, one that survives a correction instead of being embarrassed by it, which is what a genuinely good vulnerability disclosure policy is built to deliver.

Measuring trust after the correction#

The retraction did not stop the story travelling. Screenshots of the original "exploited in the wild" framing were still circulating on social platforms days after Microsoft's correction landed, exactly the half-life problem every security vendor and every marketing team attached to one needs to plan for.

That post, shared two full days after Microsoft's own correction, still carried the pre-retraction framing, sourced back to the original Hacker News headline before its edit. It is not evidence of bad faith. It is evidence that a correction has to out-compete the original claim on every channel it appeared on, not just the one where it was issued, or the scarier version simply keeps being true in the corners of the internet the correction never reached.

None of this is unique to Entra ID, or to Microsoft. Zero day disclosure practice across the whole industry runs on the same fault line, a first, urgent claim that outruns the slower, more careful correction behind it, every single time a scent this strong hits the trail. CISA's own Known Exploited Vulnerabilities catalogue exists for exactly this reason, a single, dated record of what is confirmed, not claimed, to be under active attack.

For a marketing or compliance team building credibility in identity and access management, cloud identity security, or any adjacent buyer-intent category, the practical takeaway is dull on purpose: cite the dated, corrected version of a claim, say plainly when a number changed and why, and resist the urge to keep the scarier framing live because it performs better in a feed.

That discipline is also, not coincidentally, exactly what makes a page safe for a generative answer engine to quote, because a claim that survives its own correction is a claim worth repeating. It is the same standard folkfox holds its own SEO and GEO work to, and the same one we apply when we build out a client's brand strategy around genuinely defensible claims rather than the first draft of a headline.

If your last written vulnerability disclosure policy predates the first time your marketing team had to walk a claim back in public, this is a good week to revisit it. If you want that discipline built into your reporting and content from the start, that is what folkfox does.

Frequently asked questions#