Nothing to Patch, Everything to Prove: Microsoft's Exploited Entra ID 10.0 Leaves Tenants Holding the Logs

A maximum-severity flaw that has already been used against real systems normally arrives with a version number attached. Cisco's latest round is the ordinary shape of that: nine flaws across Crosswork and Secure Workload, fixed builds named for each, found in internal testing and not known to be exploited ^[36]. Five of the nine scored CVSS 10.0, and every one of them is something an operator can close on a Tuesday ^[35].

CVE-2026-69836 inverts both halves of that arrangement. Microsoft scores the Entra ID deserialization bug at 10.0, says it has been exploited in the wild, and says the fix is already in place with nothing for customers to do ^[1][2]. The finding was credited to one of Microsoft's own principal security engineers ^[5], so the discovery, the fix, and the telemetry that would describe the abuse all sit inside a single organisation. What is left on the tenant side is not remediation. It is assurance, and assurance needs facts the advisory does not contain: how the flaw was exploited, when that started, and whether it is still happening are all listed as unknown ^[3].

Nothing to patch also means nothing to check against

Set it beside the GitLab bug from the same week. CVE-2026-19478 is a 9.4 code injection that lets an unauthenticated attacker rewrite or delete public projects, and watchTowr says it came under exploitation within days of disclosure ^[14]. The firm reproduced it in minutes and saw attempts against its honeypot network ^[16]. Defenders got two levers: four patched releases to install ^[18], and a string to search web logs for, `@gl_introduced` ^[15]. The patch is the fix. The string is what turns "we checked" into a sentence with something behind it.

The Entra advisory supplies the first of those and not the second. The service side is closed, and the tenant is told the matter is settled ^[2]. Anyone whose auditors, insurers, or board ask what happened in their directory during the exploitation window has to answer from their own logs, without knowing where the window is.

The retention arithmetic nobody put in the advisory

Microsoft's own documentation is where that answer runs out. Entra ID on a free licence stores up to seven days of activity data, and upgrading does not change history: switch from free to premium and you still see only what is inside the seven days ^[7]. Retention changes are not retroactive, and data that has already expired cannot be recovered unless it was archived beforehand ^[8]. Longer retention exists only if the tenant was already routing audit and sign-in data to an Azure storage account through Azure Monitor ^[9]. Microsoft Graph activity logs are narrower still: available on P1 and P2 only, and not retained at all unless archived to storage or piped into analytics tooling ^[10].

Put the two documents together and the shape of the problem is arithmetic rather than argument. The exploitation interval is undated ^[3]; the default evidence horizon is seven days and is unrecoverable once passed ^[40]. A tenant that did not export cannot establish whether the interval it needs to inspect is still inside its own records, which means the licensing and log-routing decision made months ago is the thing that determines whether the question is answerable now.

Two partial exceptions are worth noting because they are the only places evidence may outlive the gap. Entra audit and sign-in logs are separate from the Microsoft 365 Unified Audit Log, whose retention is managed through Purview Audit and is not affected by Entra licensing changes ^[11]. And risky users and workload identities are not deleted until the risk has been remediated ^[13], which preserves a Microsoft-generated verdict rather than the raw activity a reviewer would want to read.

Whoever holds the telemetry writes the "no impact" line

This week produced two other negative findings, and comparing them is instructive because they are the same sentence with very different foundations.

The Rust Project deleted malicious releases of arrayref, internment, and append-only-vec, published from one compromised owner account and removed within 86 to 107 minutes ^[28]. There is no patched version, no CVE, and the RustSec advisories record no evidence that any malicious version was used ^[29]. The Hacker News asked the Rust Security Response Team for the basis of that finding and for the download counts of the deleted versions, and had received no reply at the time of writing ^[30]. Meanwhile arrayref shows 245,385,500 downloads all time, 53,905,601 in the 90 days ending August 20, and 403 dependent crates ^[31]. That 90-day figure works out to roughly 416 downloads a minute, so an 86-minute window sits over about 35,800 downloads' worth of ordinary demand for the crate ^[34]. The malicious release was not competing for that traffic on equal terms either: the owner account yanked 0.3.5 through 0.3.9 in the same minute, leaving the compromised version as the only one Cargo would not warn about, which is how the reporter says he hit it ^[33]. And the payload ran from a build script, so nothing in the crate had to be called for it to execute ^[32]. "No evidence of usage" is a claim about what the registry can see, and the registry has not published the number that would let anyone else evaluate it.

Check Point's negative is better built. Its researchers say that across all collected samples and telemetry sources they did not observe real-world abuse of Defender's BTR.sys driver in the manner they demonstrated, and they draw the operational conclusion from it: detection engineering is feasible before weaponisation appears ^[25]. Same absence, stated basis, actionable consequence.

Two Microsoft answers, one week apart

The BTR.sys work is the other half of this story, because it ends in the same place from the opposite direction. Check Point's technique uses Defender's own signed boot-time removal driver to perform kernel-level file and registry operations on everything from Windows 7 to Windows 11 25H2, with no software flaw exploited and no driver brought in from outside ^[19]. The driver is a required Windows component, so it cannot be added to the Vulnerable Driver Blocklist or blocked with WDAC without breaking Defender itself ^[20]. A live demonstration removed the whole Defender stack from a fully updated 25H2 machine with Tamper Protection enabled ^[26]. MSRC's position, per the research paper, is that the findings do not meet the criteria for immediate servicing because the technique requires pre-existing administrative privileges with SeLoadDriverPrivilege ^[21]. The researcher's repository states that no patch is planned, a characterisation Microsoft has not confirmed publicly ^[22].

So one advisory says there is nothing to do because it is fixed ^[2], and one disclosure says there is nothing to fix because it is architecture ^[21]. In both, the remediation lever belongs to Microsoft and the residual work handed to the customer is evidentiary. In both, the evidence has a hole precisely where the answer would be. For BTR.sys the hole is concrete: the driver is installed by writing HKLM directly, bypassing the Service Control Manager and generating no Event ID 7045 ^[23], and the resulting kernel operations are attributed in telemetry to the System process, PID 4 ^[24]. For Entra the hole is a retention default. A missing event ID and an expired log are the same problem for whoever has to write the incident summary.

What the proof is worth

One Identity, arguing for its own governance products, makes the point that regulators and cyber insurers now want evidence that controls run all the time, which turns the question from "did you review access" into whether you can prove access was appropriate every single day ^[37]. The same essay observes that the gap between a compromised account and real damage has compressed to hours or minutes ^[38]. Discount the sales pitch and the description still fits: the standard of proof being demanded is daily, the incident in question is undated, and the underlying records are seven days deep unless somebody already paid to copy them elsewhere.

The contrast inside Microsoft's own month makes the asymmetry plain. Earlier in August the company patched CVE-2026-68820, a 7.0 privilege escalation in the Windows Ancillary Function Driver for WinSock, exploited as a zero-day by the Lazarus Group in the campaign tracked as Operation Dream Job ^[6]. Lower score, on-premises code, and it came with a fix to deploy and a named adversary. The 10.0 in the identity plane came with a status. The lever that remains for the next one of these is not incident response but procurement: whether the logs that would answer the question were already being written somewhere the tenant controls, before there was a reason to ask.