Update, 22 August 2026: Microsoft has told BleepingComputer that it mistakenly marked a maximum-severity Microsoft Entra ID vulnerability as exploited in the wild. The correction removes the strongest public claim behind the first version of this article.
It does not end the story.
CISA’s Known Exploited Vulnerabilities catalogue still lists the same vulnerability as confirmed exploited. CERT-FR still repeats Microsoft’s original assessment. CISA’s separate CVE enrichment records exploitation as none. One vulnerability now carries conflicting labels from high-authority sources.
That disagreement is more than a metadata problem. It changes incident-response priorities, federal remediation deadlines and the evidence organisations use to decide whether an identity environment needs investigation.
The correction changes the conclusion
Microsoft published CVE-2026-69836 on 20 August 2026. The vulnerability affects Microsoft Entra ID, the cloud identity service formerly known as Azure Active Directory.
The Microsoft Security Response Center describes deserialisation of untrusted data that could allow an unauthorised attacker to execute code over a network. Microsoft assigns a CVSS 3.1 base score of 10.0. The attack vector is network-reachable, requires no authentication and needs no user interaction. The potential effect on confidentiality, integrity and availability is high.
Those technical characteristics have not changed. The exploitation evidence has.
This article originally reported exploitation as confirmed because Microsoft’s advisory marked it that way. On 22 August, Microsoft told BleepingComputer that the designation was a mistake. BlackTree has therefore removed the zero-day conclusion from the headline and revised the analysis.
The distinction matters. A CVSS score describes technical severity under defined conditions. It does not prove that anyone has successfully used the vulnerability. An exploitation flag is a separate evidentiary claim and should be treated as such.
Microsoft says the service is already fixed
CVE-2026-69836 is tagged as an exclusively hosted service vulnerability. Customers cannot download or deploy the affected Entra ID code themselves. Microsoft says the vulnerable condition has already been fully mitigated and that users of the service have no remediation action to take.
That is a patching statement. Administrators do not need to find an update, test it or deploy it across a fleet.
It is not a complete incident statement. Microsoft has not publicly described the vulnerable component, the exposure window, the security context in which code could run or whether any customer tenant was affected. No public exploit code or technical attack chain has been identified in the sources reviewed for this update.
The vendor correction now indicates that Microsoft does not regard the flaw as exploited in the wild. That should lower the confidence behind claims of compromise. It does not make the technical vulnerability less severe, and it does not explain why other authoritative systems still assert exploitation.
CISA still lists the vulnerability as known exploited
At the time of this update, CISA’s Known Exploited Vulnerabilities catalogue still records CVE-2026-69836 as confirmed exploited. The entry was added on 21 August and carries a remediation due date of 24 August 2026.
The generic required action tells organisations to apply vendor mitigations, follow the relevant federal cloud-service and forensic-triage guidance, or discontinue use if mitigations are unavailable. Microsoft, however, says the hosted service is already mitigated and customers have nothing to install.
CISA’s own structured CVE enrichment adds another complication. Its Stakeholder-Specific Vulnerability Categorization data records exploitation as none, while describing the attack as automatable with total technical impact.
Two CISA-backed signals therefore point in different directions:
The KEV catalogue says confirmed exploitation.
The CISA CVE enrichment says no exploitation evidence.
This may be a synchronisation delay or a correction still moving through separate publication systems. It may also prompt a further clarification. Until that happens, defenders should preserve the attribution instead of silently choosing the label that best fits an existing workflow.
The first claim has already propagated
The early exploitation designation moved quickly. CERT-FR published an advisory on 21 August stating that Microsoft indicated active exploitation. News reports, threat-intelligence summaries and automated vulnerability feeds repeated the same conclusion.
BleepingComputer revised its story and title at 02:56 EDT on 22 August, which was 08:56 in Madrid, after receiving Microsoft’s correction. Not every downstream system will update at the same speed. Some may preserve the original label without its later context.
This is why exploitation status should be stored as time-stamped, source-attributed evidence rather than a permanent Boolean field. A ticket that says only “exploited: yes” loses the most important context:
Who made the claim?
When was it made?
Was it direct evidence or copied from another source?
Has the originating source corrected it?
Do other authoritative sources still disagree?
A correction does not merely change a dashboard colour. It can change patching queues, escalation levels, regulatory evidence and the scope of an incident review.
What organisations should do now
Organisations should not treat the original Microsoft flag as proof that their Entra tenant was compromised. Microsoft says the label was a mistake, and no tenant-specific impact has been established publicly.
There is also no customer-side patch to deploy. Repeatedly searching for one will not reduce the risk.
A proportionate response is to document the evidence conflict and preserve the identity telemetry that would matter if further information changes the assessment. Security teams should consider:
Recording Microsoft’s correction, the current CISA KEV status and the exact time each source was checked.
Preserving Entra sign-in, audit and risk logs before normal retention removes them.
Reviewing unexplained privileged-role assignments, eligible-role changes and newly created administrative identities.
Checking new or modified application registrations, service principals, credentials and federated identity relationships.
Asking Microsoft for a tenant-specific impact statement if unexplained identity activity appears during the possible exposure window.
Revisiting KEV-driven remediation or compliance tickets when CISA or Microsoft publishes a further clarification.
These are assurance steps, not evidence that exploitation occurred. Their value comes from the importance of Entra ID as an identity control plane and the low cost of preserving evidence while authoritative sources reconcile their records.
The cloud CVE remains a transparency test
Cloud services change the division of security work. The provider owns the code and can remove a vulnerable condition centrally. Customers cannot scan the service binary, reproduce the affected configuration or independently determine the blast radius.
That makes precision in the advisory more important, not less.
For an exclusively hosted vulnerability, customers need a reliable chronology: when the flaw existed, when it was mitigated, whether exploitation was observed, what service boundary was reachable and whether affected tenants will be notified. When an exploitation claim is corrected, downstream authorities and machine-readable feeds also need a clear withdrawal path.
CVE-2026-69836 remains a maximum-severity Entra ID vulnerability that Microsoft says it has fixed. The exploited label does not currently have consistent support.
The defensible position is therefore precise: Microsoft says its exploitation flag was a mistake. CISA’s KEV catalogue still asserts exploitation. CISA’s separate CVE enrichment says exploitation is not established. Customers have no patch to install.
Those statements should remain separately attributed until the authorities reconcile them.
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gid
ID used to identify users for 24 hours after last activity
24 hours
_ga_
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utma
ID used to identify users and sessions
2 years after last activity
Jetpack's built-in visitor analytics. It records page views, referring sites, search terms, and outbound link clicks, and also carries the shared visitor-tracking library used by Jetpack Instant Search and WooCommerce Analytics.