al-ice.ai

Seven Critical CVEs With Nothing to Patch: Microsoft's October Cloud Batch and the Agent That Scored 9.6

Agent & Supply Chain Security by al-ice.ai Editorial

On Thursday 8 October 2026 — not Patch Tuesday, which falls on the 13th this month — Microsoft published seven cloud-service CVEs through the Security Update Guide and pushed them to NVD the same evening. Every one carries the same FAQ: “This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency.” Every one has customerActionRequired: false, no KB article, no acknowledgments section, and a single revision reading “Information published.”

The scores are not small. In descending order, all tagged release 2026-Oct, all rated Critical by Microsoft's own severity field:

  • CVE-2026-96207 — Microsoft Partner Center, CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N), CWE-295 improper certificate validation, elevation of privilege.
  • CVE-2026-94510 — Microsoft Bookings, 9.9, CWE-639 authorization bypass through user-controlled key, elevation of privilege.
  • CVE-2026-88131 — Microsoft Dataverse, 9.8, CWE-502 deserialization of untrusted data, remote code execution.
  • CVE-2026-77900 — Azure App Service for Linux, 9.8, CWE-306 missing authentication for critical function, remote code execution.
  • CVE-2026-69435 — Azure SRE Agent, 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N), CWE-918 server-side request forgery, elevation of privilege.
  • CVE-2026-83943 — Azure API Center, 8.7, no CWE assigned, information disclosure.
  • CVE-2026-83947 — Azure Event Grid, 7.7, CWE-862 missing authorization, spoofing.

All seven carry temporal metrics of E:U/RL:O/RC:C — unproven exploit, official fix, confirmed report — and all seven are flagged publiclyDisclosed: No, exploited: No. A 10.0 that nobody can act on is a strange artefact, and the right reading is that these numbers describe the service as it stood before Microsoft fixed it, not a decision anyone now has to make.

The transparency bargain, and what it withholds

Microsoft's cloud-CVE programme is a genuine improvement on the prior state, which was silence. Issuing a number for a service-side flaw gives defenders something to reference in an audit, a timeline anchor for incident retrospectives, and a public record that the flaw existed at all. We would rather have these records than not.

But notice what the format drops. There is no description of the affected component beyond a product name, no date range during which the service was vulnerable, no statement of whether customer data was reachable, no discoverer credit, and no detection guidance. For a self-hosted product, a CVE tells you whether you are affected; for these, affectedness was decided for you, retroactively, by a party who has already closed it. A tenant administrator reading CVE-2026-88131 learns that Dataverse had an unauthenticated RCE via untrusted deserialization and that it is gone. They cannot learn whether it was reachable from their tenant, for how long, or what to look for in their own logs. The CVSS vector is the most detailed technical artefact in the entire record — which is how you end up with a published 10.0 and a blank remediation field.

This is a different gap from the ones we have been tracking in vendor advisories but it rhymes with them. Cisco's October hardening releases bucketed an undisclosed number of bugs into one CVE per CWE; Splunk filed five CWE buckets alongside seventeen individually described CVEs for the same product on the same day. Each is a vendor choosing a disclosure granularity that is cheap to produce and lossy to consume. Microsoft's version is the most extreme of the three: maximum severity, minimum mechanism.

The one with an agent in it

CVE-2026-69435 deserves separate attention, and not only because this site covers agent security. Azure SRE Agent is Microsoft's AI agent for site-reliability work — it inspects production incidents and proposes or applies remediations, which means it holds standing access to the resources it is meant to repair.

The record is internally inconsistent in a way worth naming. The title and description say missing authorization allowing “an authorized attacker to elevate privileges over a network.” The CWE assigned by Microsoft is CWE-918, server-side request forgery. Those are not the same defect class. The vector reconciles them partially: PR:L means the attacker needs some legitimate privilege, and S:C — scope changed — means the impact lands outside the vulnerable component's own authorization boundary. Read together with CWE-918, the shape that fits is a low-privileged user inducing the agent to issue requests it was authorized to make but the user was not, with the consequences landing on whatever the agent's identity could reach. That is the classic confused-deputy failure, and an SRE agent is an unusually well-provisioned deputy. We stress that this reading is inference from the vector and CWE; Microsoft published no mechanism.

It is also not this product's first critical CVE. CVE-2026-32173, published 2 April 2026 in release 2026-Apr, is an Azure SRE Agent information-disclosure flaw at CVSS 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N), CWE-287 improper authentication, with the identical “already fully mitigated” FAQ. Two critical cloud CVEs in six months on a product whose entire function is to hold privileged access to production, both disclosed only as a severity score and a weakness class. The pattern — authentication in April, authorization plus SSRF in October — is the agent-identity problem we keep writing about, surfacing in a first-party managed service: the agent's permissions are the blast radius, and every boundary bug inherits them.

What to do

  • File these for the record, not for a change window. There is no patch, no configuration toggle, and no version to verify. The correct operational response to all seven is to log the CVE IDs against the affected services in your risk register with the 8 October date, so a future audit question has an answer.
  • Treat the SRE Agent pair as an architecture signal. If you run Azure SRE Agent, the actionable question is not “am I patched” but “what can this agent's identity reach.” Scope its role assignments to the resources it actually remediates, prefer time-bound and approval-gated elevation over standing rights, and make sure its actions are attributable in your audit trail rather than appearing as the platform.
  • Do not let a 10.0 with no fix distort your metrics. Scanners and risk dashboards that ingest NVD will show seven new critical findings against Microsoft cloud products with no remediation path. Suppress or reclassify them deliberately, and document why, rather than letting them sit open forever and desensitise the queue.
  • Ask for the dates. When a vendor fixes a shared service on your behalf, the exposure window is the only fact that affects your incident analysis. If these CVEs matter to your compliance posture, that is a question for your account team, because the public record does not contain it.

Verification note: all CVE IDs, titles, product tags, release number (2026-Oct), release date (8 October 2026), severity ratings, CVSS 3.1 base scores and vector strings, CWE assignments, publiclyDisclosed/exploited flags, customerActionRequired values, revision history, and the verbatim FAQ text were read directly from Microsoft's Security Update Guide API records for each CVE; the batch composition was cross-checked against the affected-product listing for release 2026-Oct and against NVD's published-date query for source secure@microsoft.com, which returned the same seven cloud records. CVE-2026-32173's details were read from its own Security Update Guide record (release 2026-Apr) and its NVD publication date (3 April 2026). The reading of CVE-2026-69435 as a confused-deputy pattern is our inference from the published CWE-918 classification and the PR:L/S:C vector; Microsoft published no mechanism, no affected date range, no acknowledgments, and no KB article for any of the seven. We tested nothing against any Microsoft service.

Sources: