Azure AI Foundry scored a CVSS 10.0, and customers got nothing to patch and nothing to check

Seven perfect scores in one quiet afternoon

On 17 September 2026 Microsoft published eighteen vulnerability records in its Security Update Guide that were not Azure Linux kernel entries. I pulled the whole September release from the MSRC API and counted them myself. All eighteen are cloud service flaws. All eighteen carry the flag customerActionRequired set to false. Seven of the eighteen score CVSS 10.0.

CVE-2026-85889, an elevation of privilege flaw in Azure AI Foundry, is one of the seven. Microsoft's entire description of it is one sentence: "Missing authentication for critical function in Azure AI Foundry allows an unauthorized attacker to elevate privileges over a network." The weakness is CWE-306. The vector Microsoft assigned is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, with a temporal string of E:U/RL:O/RC:C and a temporal score of 8.7. The acknowledgement record names the finder as Remy Marot.

Widen the frame to the whole September release and the pattern is sharper. Across every record numbered 2026-Sep, twenty seven are cloud CVEs marked as needing no customer action. Every single one of the twenty seven says exploited: No and publiclyDisclosed: No. Twenty six of the twenty seven carry an exploit code maturity of Unproven. Exactly one does not, and that one is also Azure AI Foundry. It is not the 10.0.

What the 10.0 does not establish

None of the above establishes that anything happened to anyone's Foundry project.

The published record does not say what the vulnerable function was, which endpoint exposed it, when it became reachable, how long the window lasted, which regions or clouds were affected, whether the privilege gained reached another customer's tenant or only a shared service component, or whether any customer visible telemetry recorded the affected requests. I read the MSRC advisory, the CVE.org record and the NVD record in full. None of those facts appear in any of them.

It does not establish that the flaw was cross tenant, which is the inference most readers will draw from a 10.0. Microsoft set Scope to Changed. In CVSS 3.1 that means impact reached beyond the security authority of the vulnerable component. It is Microsoft asserting that a boundary was crossed. It is not Microsoft saying which boundary, and a service component boundary and a tenant boundary score identically.

And it does not establish that nothing happened. "No evidence of exploitation" is a statement about what Microsoft looked for and found. The advisory does not describe the telemetry reviewed, the period covered, or the confidence attached. Treat it as a vendor assertion, which is what it is, and note that you cannot check it.

The 10.0 is arithmetic, not a measurement

Take the vector apart and the headline number stops carrying the weight readers give it. The exploitability sub score for AV:N/AC:L/PR:N/UI:N is 8.22 times 0.85 times 0.77 times 0.85 times 0.85, which is 3.887, rounded by NVD to 3.9. With Scope Changed and all three impacts High, the impact sub score is 6.048, rounded to 6.0. The base score is the roundup of 1.08 times 9.935, which exceeds ten and is therefore capped. Ten point zero.

Now vary the one input that actually differs across this month's crop of tens. Hold everything else and set availability impact to Low: the sum is 9.858, times 1.08 is 10.65, capped at 10.0. Set it to None: the sum is 9.645, times 1.08 is 10.42, capped at 10.0. Once a flaw is network reachable, unauthenticated, needs no interaction and changes scope, high confidentiality and integrity impact alone pin the score at the ceiling. Availability cannot move it. Neither can the root cause.

That is why the nine CVSS 10.0 records in this release, spanning seven distinct weakness classes and three different availability impacts, all land on exactly 10.0, and why all nine also land on exactly 8.7 once Microsoft applies the same E:U/RL:O/RC:C temporal string to each. The number is not ranking these bugs against each other. It is reporting that the same five exploitability facts were asserted nine times.

The nine CVSS 10.0 records in Microsoft's September 2026 release, from the MSRC Security Update Guide API. All nine are marked as requiring no customer action, and all nine carry a temporal score of 8.7.

CVE	Service	Weakness	Availability
CVE-2026-85889	Azure AI Foundry	CWE-306 missing authentication	High
CVE-2026-70352	Azure AI Language	CWE-306 missing authentication	High
CVE-2026-69843	Microsoft Fabric	CWE-290 auth bypass by spoofing	High
CVE-2026-69399	Azure Arc	CWE-441 unintended proxy	High
CVE-2026-62874	Azure Billing	CWE-345 data authenticity	Low
CVE-2026-70200	Azure Logic Apps	CWE-22 and CWE-285	None
CVE-2026-83944	Azure Logic Apps	CWE-284 improper access control	None
CVE-2026-69865	Container Registry	CWE-639 user controlled key	None
CVE-2026-83711	Azure AD B2C	CWE-639 user controlled key	None

Stated, and not stated

The useful discipline with a cloud CVE is to separate what is on the record from what a reader supplies from imagination. Everything in the left column below comes from a record I fetched. Everything in the right column is absent from all of them.

CVE-2026-85889 as the primary records actually describe it, from the MSRC Security Update Guide API, the CVE Services record and the NVD record, all read on 18 September 2026.

Stated on the record	Not stated anywhere
Missing authentication for a critical function, CWE-306	Which function, endpoint or component
Unauthorized attacker, no privileges, no user interaction	Whether the attacker reached another tenant
Scope Changed, so a boundary was crossed	Which boundary was crossed
Exploited: No. Publicly disclosed: No	What telemetry was reviewed to conclude that
Fully mitigated by Microsoft, no customer action	When the fix shipped, or when exposure began
Finder credited as Remy Marot	The report date or the time to fix
Exploit code maturity Unproven, remediation Official Fix	Whether any customer log would show abuse

The friendly name here is not a product name. It is the phrase customerActionRequired: false, which the Security Update Guide renders as a reassuring column, and the FAQ sentence that sits under it. Microsoft's own wording is precise: the vulnerability has been "fully mitigated by Microsoft. There is no action for users of this service to take." That is a true and complete statement about patching. It is not a statement about assurance, and the two get conflated the moment the record reaches a risk register.

The Foundry flaw nobody wrote about

Microsoft published a second Azure AI Foundry CVE on the same day. CVE-2026-85917 is a server side request forgery, CWE-918, base score 7.5, credited to Marios Gyftos. It also requires no customer action. It attracted no coverage I can find.

It is the more interesting record. Its vector ends E:P/RL:O/RC:C. Exploit code maturity Proof of Concept, not Unproven. Of the twenty seven cloud CVEs in the September release that require no customer action, it is the only one Microsoft rates above Unproven. The lower scored Foundry bug carries the stronger evidence that working exploit code exists, and it is the one that went unreported, because the sorting mechanism in front of every security reader is the base score.

What a UK customer can actually check

There is no patch, so the work is evidential rather than remedial. Three layers of telemetry exist around a Foundry deployment, and it is worth being exact about what each one covers, because the gap between them is where the honest answer lives.

The Azure activity log. Microsoft's documentation is explicit that it records management operations on your Azure resources, which it calls control plane operations, that it is collected by default with no configuration, and that Azure retains those events for ninety days before deleting them. It also notes that the activity log does not typically capture read operations. So it will show you role assignments, resource creation, configuration changes and who made them, for a window that, as of today, reaches back to about 20 June 2026.

Resource logs. These are the data plane, and Microsoft states plainly that they are not collected by default and require a diagnostic setting. The Foundry Models monitoring guidance puts the point in a way worth quoting to a board: logs "are generated automatically, but you must route them to Azure Monitor logs to save or query by configuring a diagnostic setting". For the Microsoft.CognitiveServices/accounts resource type the supported categories are Audit, RequestResponse, Trace, AzureOpenAIRequestUsage and ManagedNetworkEvent. Microsoft tells you to perform the configuration on each resource, and warns that it can take up to two hours before data is queryable. The property that matters here is that a diagnostic setting is forward looking. If it was not configured before the exposure window, the evidence was generated and then discarded.

Microsoft's own service side operations. This is the layer that matters for a CWE-306 in a managed service, and it is the one you do not have. The documentation describes the activity log as recording management operations for your resources through Azure Resource Manager. Nothing in the Foundry or Azure Monitor documentation describes a customer visible record of operations Microsoft's own service components perform inside the platform. If the missing authentication check sat behind a Microsoft operated component rather than on your resource's documented API surface, your logs are silent by design, and the advisory does not tell you which it was.

# 1. Do you have data plane logs at all on every Foundry resource?
az monitor diagnostic-settings list \
  --resource /subscriptions/SUBID/resourceGroups/RG/providers/Microsoft.CognitiveServices/accounts/ACCOUNT

# 2. Pull the control plane record before the 90 day window ages out.
az monitor activity-log list --offset 90d \
  --query "[?contains(resourceId, 'Microsoft.CognitiveServices')]"

# 3. If diagnostic settings were already sending to Log Analytics,
#    look at data plane operations across the period you care about.
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where TimeGenerated between (datetime(2026-06-20) .. datetime(2026-09-18))
| summarize calls = count() by OperationName, Resource, CallerIPAddress
| order by calls desc

Run those three and you will be able to say what your own identities did, whether your resource configuration changed, and whether you were even collecting data plane telemetry during the period. You will not be able to rule out the thing the CVE describes. That is not a failure of your process. It is the shape of the evidence available, and the register entry should say so.

One control you do own is worth more than the whole search. Microsoft's Foundry access control documentation states that role based access control applies when you authenticate with Microsoft Entra ID, and that if you use key based authentication instead, the key grants full access without role restrictions. A CVSS 10.0 you cannot touch is a poor use of an hour. An inventory of Foundry account keys sitting in pipeline variables and notebooks is an excellent one.

Microsoft's stated practice, and where it stops

Credit where it belongs: this CVE exists because Microsoft decided it should. In June 2024 the MSRC committed to "issue CVEs for critical cloud service vulnerabilities, regardless of whether customers need to install a patch or to take other actions", added a customer action column to the Security Update Guide, and adopted an exclusively-hosted-service tag on CVE.org records. That tag is present on this record, carried through to NVD. Before that commitment this flaw would have been fixed silently and you would know nothing about it.

The limit of that practice is visible in the same record. It commits Microsoft to the existence of a CVE, and to a weakness class and a score. It does not commit Microsoft to an exposure window, an affected component, a customer impact statement, or any evidence a customer could use to close the question at their end. Transparency about the existence of a defect is not transparency about your exposure to it.

The mechanism that would give a UK controller something usable is a different one entirely. Microsoft's processor commitments state that Azure notifies customers of data breaches, that customer notices are delivered in no more than 72 hours from the time a breach is declared, and that an initial notification includes the nature of the breach, approximate user impact and mitigation steps. That is the document a UK security lead would take to the ICO. It fires on a declared breach, not on a fixed vulnerability, and Microsoft says this was not exploited, so it does not fire.

Two commercial notes, stated without insinuation. The finder is credited by Microsoft as Remy Marot; secondary coverage identifies him as a Tenable engineer, and Tenable sells vulnerability management and publishes the most widely read Patch Tuesday roundup. I checked that roundup: it counts 964 CVEs for the 8 September release and, as of my reading, does not mention Foundry or this CVE at all. That is not an omission worth criticising. It is a timing artefact, and it is the real lesson. Patch Tuesday fell on 8 September. These cloud records landed on 17 September, nine days later, after every roundup that would have carried them had already been written.

What to do this week, in order

The question that exposes the gap

Ask it of your account team, and ask it before you need the answer. If Microsoft had found evidence that one customer's requests reached another customer's Foundry project through this missing authentication check, which document would you have received, on what timescale, and how would it differ from the one you received last Thursday?

On the current record, a flaw that was never touched and a flaw that was touched but not detected produce exactly the same advisory: one sentence, a CVSS 10.0, exploited No, no action for users of this service to take. The score tells you how bad it could have been. Nothing in the package tells you whether it was, and nothing you own can close the gap. That is the governance problem with managed AI platforms, and it will not be solved by a number.

Key facts