No Password Required: Inside the CVSS 10 Bug That Let Anyone Rewrite Azure AI Language Models

AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. That's the entire CVSS vector string for CVE-2026-70352, and if you've spent any time scoring vulnerabilities, you already know what it means without reading a single word of Microsoft's advisory: reachable from the network, trivial to pull off, no privileges needed, no user has to click anything, the blast radius spreads beyond the vulnerable component, and confidentiality, integrity, and availability all take a full hit. Run that vector through any calculator and it lands exactly where it landed for Microsoft: 10.0. The maximum. There's no higher number on the scale.

What earned that score wasn't a kernel exploit or a clever memory corruption chain. It was something almost insultingly simple: a critical function in Azure AI Language Authoring that didn't check who was calling it. No password required. No API key. No token. Just a network path to the endpoint.

What Actually Broke

Microsoft's Security Response Center describes CVE-2026-70352 in one sentence: "Missing authentication for critical function in Azure AI Language allows an unauthorized attacker to elevate privileges over a network." It's classified under CWE-306: Missing Authentication for Critical Function — one of the oldest, most boring, most preventable categories in the entire CWE taxonomy. This isn't a novel side-channel or a race condition that took a research team six months to find. It's an endpoint that should have asked "who are you?" and simply didn't.

Azure AI Language is the service formerly known (in parts) as Language Understanding Intelligence Service, now consolidated under Azure AI Foundry as the platform behind conversational language understanding (CLU), custom text classification, named entity recognition, and question answering. The Authoring layer specifically is the control plane — the part exposed through Language Studio where a tenant builds a custom model, uploads training data, trains it, and deploys it to a runtime endpoint that their application actually calls in production. It's the "build" side, not the "predict" side.

That distinction matters enormously here. A vulnerability in the runtime/prediction endpoint might expose one deployed model's inference results. A vulnerability in the authoring plane — the layer with permission to create projects, import data, kick off training jobs, and push new deployments — is a vulnerability in the thing that controls what the model actually is. According to Microsoft's own scoring, an unauthorized attacker reaching that critical function could elevate privileges and, per multiple independent CVE trackers that mirrored the MSRC record, manipulate deployed language models directly.

Field	Value
CVE ID	CVE-2026-70352
Title	Azure AI Language Elevation of Privilege Vulnerability
Weakness	CWE-306: Missing Authentication for Critical Function
CVSS 3.1 Base Score	10.0 (Critical)
CVSS Vector	`AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`
Temporal Score	8.7
Publicly Disclosed Before Fix	No
Exploited in the Wild	No (per Microsoft)
Customer Action Required	None — fixed server-side
Release Date	September 3, 2026 (early/off-cycle cloud batch)

How This Would Have Played Out

Microsoft doesn't publish proof-of-concept detail for cloud-service CVEs like this one — for obvious reasons, since the flaw already existed in a live multi-tenant service before it was patched. So I want to be precise about what's confirmed versus what's a reasoned reconstruction from the CVSS vector and the CWE classification. The following is the latter: the shape of an attack that a bug scored and classified this way implies, not a documented incident.

Reconnaissance. An attacker identifies the Authoring API surface for Azure AI Language — the endpoints Language Studio itself calls to manage projects, training jobs, and deployments — and finds a specific critical function among them that responds without validating a bearer token, subscription key, or Azure AD identity against the caller.
Unauthenticated invocation. Because PR:N (no privileges required) and UI:N (no user interaction), the attacker calls that function directly over the network with no credentials attached — no stolen key, no phished token, nothing to obtain first.
Cross-tenant reach. The S:C (scope changed) component is the detail that should worry infrastructure teams most: it signals the vulnerable function could affect resources beyond its own security boundary — consistent with a shared control-plane bug touching more than the caller's own tenant, rather than a bug confined to resources the caller already owns.
Tampering with the model. With write access to a critical authoring function, an attacker could plausibly alter a deployed model's configuration, redeploy a different model version, or interfere with training data and jobs — explaining the C:H/I:H/A:H rating (full loss of confidentiality, integrity, and availability) on "just" an authoring bug.
Silent server-side fix. Microsoft found and closed the gap before disclosure. The CVE exists purely for transparency — there's no patch number, no KB article, no version to upgrade, because the fix happened in Microsoft's own infrastructure, not in anything a customer runs.

The Batch It Was Buried In

CVE-2026-70352 didn't arrive alone. It was one of nine vulnerabilities Microsoft disclosed in an early, off-cycle security update on September 3, 2026 — five days before the main September Patch Tuesday. Every one of them was cloud-side and fixed server-side, meaning no customer had a patch to apply for any of them. Two hit the maximum CVSS score of 10.0. This one, and an Azure AD B2C flaw right alongside it:

CVE	Product	Weakness	CVSS
CVE-2026-83711	Azure AD B2C	Authorization Bypass Through User-Controlled Key	10.0
CVE-2026-70352	Azure AI Language Authoring	Missing Authentication for Critical Function	10.0
CVE-2026-83941	Entra ID	Missing Authorization	9.9
CVE-2026-80098	Copilot Studio	Improper Verification of Cryptographic Signature	9.3

Look at that weakness column again: authorization bypass, missing authentication, missing authorization, broken signature verification. Four different Microsoft products, four different teams, one shared root cause — somewhere in the request path, nobody checked whether the caller was allowed to be there. That's not a coincidence worth writing off as "these things happen." That's a pattern.

The Part of This That's Actually New: The "No Action Required" CVE

I've read a lot of security advisories over the years, and this one still sits oddly with me for a reason that has nothing to do with the bug itself. Microsoft's own FAQ on this CVE reads almost apologetically: "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." That's it. No update to schedule. No config to change. No advisory to forward to your patch management team. Just an entry in the vulnerability database telling you, after the fact, that a maximum-severity bug existed in a service you were using and someone else already closed it for you.

This is part of a deliberate shift — Microsoft's own Cloud Service CVEs transparency initiative — to assign CVEs to cloud-side bugs that were found and fixed internally before any customer was ever exposed to public knowledge of them, rather than quietly patching and saying nothing. I think that's the right instinct in principle. Silent fixes with no disclosure at all is worse. But it also creates a new category of advisory that traditional vulnerability management processes aren't built to handle: a CVSS 10.0 entry with nothing to patch, no IOC to hunt for, and no way for a customer to independently verify when the exposure window actually closed, because the only party who ever saw server logs was Microsoft.

My Take

I manage infrastructure for a living — networks, identity, the boring unglamorous plumbing that everything else sits on top of — and the thing that jumps out at me here isn't the CVSS score. Dozens of critical-severity bugs get disclosed every Patch Tuesday and most of them barely register outside the SOC. What jumps out is where this one lived: the control plane of a managed AI service, the layer that decides what a deployed model actually is.

For years, "AI security" conversations in the enterprise space have obsessed over model weights, training data poisoning, prompt injection, and adversarial inputs — genuinely important problems, but ones that assume the plumbing underneath is solid. CVE-2026-70352 is a reminder that the plumbing underneath a managed AI service is still just software, written by people, exposed over HTTP, and just as capable of having a control-plane endpoint that forgot to check a header as any legacy on-prem app from 2010. CWE-306 is not an exotic AI-era vulnerability class. It's the same missing-auth mistake that's been showing up in CVE databases since before "machine learning" was a marketing term, just relocated to a service with "AI" in the product name and a blast radius that now includes whatever business logic your organization built on top of a custom language model.

What actually bothers me is the asymmetry of information. If this had been an on-prem product, I'd have a CVE description with enough technical meat to reason about exposure, a patch to test and deploy on my own timeline, and — eventually — a public writeup from whoever found it. Here, I get one sentence, a CVSS vector, and a promise that it's fine now. I have no way to independently confirm that. Neither does anyone else outside Microsoft. I'm not accusing Microsoft of bad faith — quite the opposite, disclosing this at all when they didn't have to is the transparent move, and burying it would've been worse. But "trust us, it's handled" is structurally different from "here's the patch, verify it yourself," and every organization that has built production workflows on Azure AI Language's custom models absorbed that trade-off without ever being asked whether they wanted to.

What You Should Do Right Now

There's genuinely no patch to install for CVE-2026-70352 specifically — but treat this advisory as a prompt to check the things that are within your control:

Audit who can reach your Azure AI Language resources. Review the network access configuration (private endpoints, IP firewall rules, VNet integration) on any Language/Foundry resources you own. A control-plane bug on Microsoft's side doesn't help an attacker who can't reach your resource's data plane through some other combination of misconfiguration.
Review deployed model versions and training project history. Since the mitigation window and any potential exposure predate this disclosure, it's worth a sanity check: pull the deployment history and audit logs for your custom CLU or text classification projects in Language Studio and confirm every deployed version and training run is one your team actually initiated.
Tighten your own authentication layer regardless. Make sure every application calling your deployed language model endpoints is doing so with scoped, rotated API keys or managed identities — not because this specific bug required it, but because a defense-in-depth posture is what actually limits damage when the next missing-auth bug in a dependency you don't control gets found.
Track the Cloud Service CVE feed, not just Patch Tuesday. If your team's vulnerability management process only reviews the monthly Patch Tuesday bulletin, you will systematically miss these off-cycle cloud CVEs. Add MSRC's cloud-service CVE releases to whatever you use for CVE monitoring — even when there's nothing to patch, your risk register should reflect that a maximum-severity bug briefly existed in a service you depend on.
Ask your vendor risk process an uncomfortable question. If you have compliance obligations that require documenting vulnerability exposure windows for your supply chain, work out now how you'll answer "were we exposed and for how long" for a cloud CVE where the only telemetry lives in a provider you don't control. Better to have that conversation before an auditor asks it for you.

This article was researched and drafted with AI assistance as part of an experiment in building a faster tech-writing workflow, then reviewed and edited before publishing.

Primary source: CVE-2026-70352: Azure AI Language Elevation of Privilege Vulnerability — Microsoft Security Response Center, September 3, 2026

Secondary sources: Microsoft's Two-Track Patch Tuesday: Cloud Identity Flaws Fixed Before Disclosure, Windows Still Catching Up — Forkast, September 8, 2026; What is Azure AI Language — Microsoft Learn