Back to Intelligence

CVE-2026-85889: CVSS 10.0 Missing Authentication Flaw in Azure AI Foundry — Defender's Validation and Hardening Guide

SA
Security Arsenal Team
September 18, 2026
10 min read

Microsoft has shipped a fix for CVE-2026-85889, a maximum-severity vulnerability in Azure AI Foundry carrying a CVSS score of 10.0. Per Microsoft's advisory language, the flaw is a "missing authentication for critical function" (CWE-306) that "allows an unauthorized attacker to elevate privileges over a network." Because Azure AI Foundry is a fully managed cloud service, Microsoft has applied the fix server-side — no customer action is required to remediate the vulnerability itself.

That last sentence is where most organizations will stop reading. Don't.

In fifteen years of IR work, the phrase "no customer action required" has preceded some of the most uncomfortable post-incident conversations I've had with clients. A server-side patch closes the hole going forward — it does nothing to tell you whether the hole was used before it was closed. With a CVSS 10.0, network-reachable, unauthenticated privilege-escalation flaw sitting in a service that orchestrates your AI models, training data, and increasingly your agents' identities and tool access, retrospective validation is not optional. This post walks through what we know, what defenders should hunt for, and how to harden your Azure AI estate against the next one.

Technical Analysis

Affected Product and Component

  • Product: Azure AI Foundry (Microsoft's unified platform for building, evaluating, and deploying AI applications and agents, formerly Azure AI Studio — built atop Azure Machine Learning / Cognitive Services infrastructure)
  • Vulnerability type: CWE-306 — Missing Authentication for Critical Function
  • CVE: CVE-2026-85889
  • CVSS: 10.0 (CVSS v3.1 maximum; consistent with a network-vector, unauthenticated, no-user-interaction privilege escalation)
  • Vector: Network — the flaw is exploitable remotely without credentials

What the Vulnerability Enables

A missing-authentication flaw in a critical function means a specific API endpoint, control-plane operation, or internal management interface within the AI Foundry service accepted requests without validating the caller's identity. The practical consequence chain for a defender looks like this:

  1. Unauthenticated network access to the vulnerable function — no token, no session, no prior foothold required.
  2. Privilege elevation within the service context — the attacker assumes capabilities of a legitimate principal. In an AI Foundry context, that can mean control over workspace resources, deployed models, endpoints, connected datastores, and — critically — the managed identities attached to those resources.
  3. Downstream blast radius — AI Foundry workspaces routinely hold connections to Azure Storage, Key Vault, Azure OpenAI deployments, Container Registry, and data sources via managed identity and RBAC role assignments. A service-context privilege escalation is a pivot point into everything the workspace identity can touch.

This is why a CVSS 10.0 in an AI orchestration platform matters more than the same score in an isolated service: modern AI workspaces are credential aggregation points. Model endpoints, agent tool connections, and pipeline identities concentrate secrets and permissions in one place.

Exploitation Status

As of this writing:

  • Microsoft's public advisory describes the flaw as exploitable by an unauthorized network attacker, but no public proof-of-concept exploit has been observed.
  • No confirmed in-the-wild exploitation has been reported at time of disclosure.
  • The CVE has not yet appeared in the CISA Known Exploited Vulnerabilities (KEV) catalog — monitor this, as KEV inclusion for a CVSS 10.0 cloud flaw would trigger Binding Operational Directive timelines for federal agencies and should trigger your internal emergency-change process regardless.

Absence of reported exploitation is not evidence of absence. Cloud service exploitation frequently surfaces weeks or months later in provider telemetry disclosures. Assume the vulnerability window — disclosure to patch deployment — was observable to anyone monitoring the service's behavior, and hunt accordingly.

Detection & Response

Because the vulnerable function lived in Microsoft's service plane, you will not see the exploitation attempt itself in endpoint telemetry. What you can see is the post-exploitation behavior in your tenant: anomalous control-plane operations against AI Foundry / Machine Learning workspaces, unexpected RBAC changes, suspicious data-plane access to model endpoints and attached storage, and abuse of workspace managed identities. The detections below are built for exactly that.

SIGMA Rules

The following rules target Azure Activity Log and Entra ID audit telemetry. Pipe these through your SIEM's Azure log connector.

YAML
---
title: Azure AI Foundry Workspace Privilege Escalation via Role Assignment
id: 3f8a1c94-7b2e-4d51-9a6c-2e8f5b0d1a77
status: experimental
description: Detects role assignments or write operations targeting Azure Machine Learning / AI Foundry workspace resources, a potential indicator of privilege escalation following CVE-2026-85889 exploitation.
references:
  - https://thehackernews.com/2026/09/microsoft-patches-cvss-100-azure-ai.html
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.privilege_escalation
  - attack.t1078.004
logsource:
  product: azure
  service: activitylogs
detection:
  selection_scope:
    resourceProvider|contains:
      - 'Microsoft.MachineLearningServices'
      - 'Microsoft.CognitiveServices'
  selection_action:
    operationName|contains:
      - 'Microsoft.Authorization/roleAssignments/write'
      - 'Microsoft.MachineLearningServices/workspaces/write'
      - 'Microsoft.MachineLearningServices/workspaces/computes/write'
      - 'Microsoft.MachineLearningServices/workspaces/connections/write'
  condition: selection_scope and selection_action
falsepositives:
  - Legitimate CI/CD pipeline deployments of AI workspace infrastructure
  - Platform engineering teams provisioning new workspaces
level: high
---
title: Suspicious Data Plane Access to Azure AI Model Endpoints
id: 8c2d5e61-4a9f-47b3-b8d0-6f1a3c9e2b55
status: experimental
description: Detects listing of workspace keys or secrets against Azure AI / ML resources, which may follow unauthorized privilege escalation to enable model endpoint or datastore access.
references:
  - https://thehackernews.com/2026/09/microsoft-patches-cvss-100-azure-ai.html
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.credential_access
  - attack.t1552.005
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    operationName|contains:
      - 'Microsoft.MachineLearningServices/workspaces/listKeys/action'
      - 'Microsoft.CognitiveServices/accounts/listKeys/action'
      - 'Microsoft.MachineLearningServices/workspaces/connections/listsecrets/action'
      - 'Microsoft.KeyVault/vaults/secrets/read'
  condition: selection
falsepositives:
  - Administrators rotating keys during routine maintenance
  - Automated secrets-management tooling (scope by known service principals)
level: high
---
title: New Online Endpoint Deployment on Azure AI Foundry Workspace
id: b71e4a08-2d6c-4f95-a13e-9c4d7b2e8f33
status: experimental
description: Detects creation of online endpoints and deployments on ML workspaces. Attackers who gain elevated privileges may deploy rogue endpoints for data exfiltration or persistence within the AI platform.
references:
  - https://thehackernews.com/2026/09/microsoft-patches-cvss-100-azure-ai.html
  - https://attack.mitre.org/techniques/T1583/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.persistence
  - attack.t1583.006
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    operationName|contains:
      - 'Microsoft.MachineLearningServices/workspaces/onlineEndpoints/write'
      - 'Microsoft.MachineLearningServices/workspaces/onlineEndpoints/deployments/write'
  condition: selection
falsepositives:
  - Data science teams deploying models to staging or production endpoints
level: medium

KQL Hunt — Microsoft Sentinel / Defender

This query hunts the Azure Activity Log for first-seen or anomalous control-plane operations against AI Foundry resources by principals with no prior history of performing them — the signature of an attacker operating with newly elevated privileges. Run it over a 30-day baseline with a 14-day lookback.

KQL — Microsoft Sentinel / Defender
let Lookback = 14d;
let Baseline = 30d;
let SuspiciousOps = dynamic([
  "Microsoft.Authorization/roleAssignments/write",
  "Microsoft.MachineLearningServices/workspaces/write",
  "Microsoft.MachineLearningServices/workspaces/connections/write",
  "Microsoft.MachineLearningServices/workspaces/listKeys/action",
  "Microsoft.MachineLearningServices/workspaces/connections/listsecrets/action",
  "Microsoft.CognitiveServices/accounts/listKeys/action",
  "Microsoft.MachineLearningServices/workspaces/onlineEndpoints/write",
  "Microsoft.MachineLearningServices/workspaces/onlineEndpoints/deployments/write"
]);
let HistoricalActors = AzureActivity
  | where TimeGenerated between (ago(Lookback + Baseline) .. ago(Lookback))
  | where OperationNameValue in~ (SuspiciousOps)
  | summarize by Caller;
AzureActivity
| where TimeGenerated >= ago(Lookback)
| where OperationNameValue in~ (SuspiciousOps)
| where Caller !in (HistoricalActors)
| where ActivityStatusValue == "Success"
| extend ResourceParts = split(ResourceId, "/")
| extend WorkspaceName = tostring(ResourceParts[-1])
| summarize Operations = make_set(OperationNameValue),
            OperationCount = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Workspaces = make_set(WorkspaceName)
  by Caller, CallerIpAddress, SubscriptionId, ResourceGroup
| sort by OperationCount desc

Complement this with an Entra ID audit hunt for privilege changes on service principals associated with ML workspaces:

KQL — Microsoft Sentinel / Defender
AuditLogs
| where TimeGenerated >= ago(14d)
| where OperationName has_any ("Add member to role", "Add app role assignment to service principal", "Add owner to application")
| extend TargetPrincipal = tostring(TargetResources[0].displayName)
| where TargetPrincipal has_any ("ml", "ai-foundry", "machinelearning", "workspace") or tostring(TargetResources[0].id) has "MachineLearningServices"
| extend Actor = tostring(InitiatedBy.user.userPrincipalName), ActorIP = tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated, OperationName, Actor, ActorIP, TargetPrincipal, Result
| sort by TimeGenerated desc

Velociraptor VQL — Endpoint Hunt for Azure CLI Abuse

If you suspect a developer workstation or build agent was used to interact with AI Foundry during the exposure window (e.g., via stolen tokens or az CLI), this artifact hunts for Azure CLI invocations touching ML/Cognitive Services resources:

VQL — Velociraptor
-- Hunt for Azure CLI operations against AI Foundry / ML resources
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)az(\.exe)?$'
  AND CommandLine =~ '(?i)(ml |machinelearningservices|cognitiveservices|ai |role assignment|list-keys|listsecrets)'

For historical review, also pull the Azure CLI command log and token cache from suspected hosts — glob() over C:/Users/*/.azure/ (msal_token_cache, azureProfile.json, commands/*.log) tells you which subscriptions and identities the CLI authenticated as and when.

Remediation & Verification Script

The patch is Microsoft's responsibility; verifying your estate's hygiene is yours. This PowerShell inventory-and-audit script enumerates AI Foundry / ML workspace resources, checks diagnostic settings (so you actually have the logs the detections above need), and surfaces role assignments for review:

PowerShell
# Requires: Az.Accounts, Az.MachineLearningServices, Az.Monitor modules
# Run with an identity holding Reader + Monitoring Reader at minimum
Connect-AzAccount -UseDeviceAuthentication

# 1) Inventory all ML / AI Foundry workspaces across subscriptions
Get-AzSubscription | ForEach-Object {
  Set-AzContext -SubscriptionId $_.Id | Out-Null
  Write-Host "=== Subscription: $($_.Name) ===" -ForegroundColor Cyan

  # Enumerate workspaces (Azure AI Foundry projects ride on ML workspaces)
  Get-AzResource -ResourceType 'Microsoft.MachineLearningServices/workspaces' |
    Select-Object Name, ResourceGroupName, Location | Format-Table -AutoSize

  # 2) Verify diagnostic settings exist (required for the Sigma/KQL detections)
  Get-AzResource -ResourceType 'Microsoft.MachineLearningServices/workspaces' | ForEach-Object {
    $diag = Get-AzDiagnosticSetting -ResourceId $_.ResourceId -ErrorAction SilentlyContinue
    if (-not $diag) {
      Write-Warning "NO DIAGNOSTIC SETTINGS on $($_.Name) — enable AzureActivity + resource logs to Sentinel/LAW immediately"
    }
  }

  # 3) Export role assignments on workspace scopes for anomalous-principal review
  Get-AzResource -ResourceType 'Microsoft.MachineLearningServices/workspaces' | ForEach-Object {
    Get-AzRoleAssignment -Scope $_.ResourceId |
      Where-Object { $_.RoleDefinitionName -in 'Owner','Contributor','AzureML Data Scientist','Cognitive Services Contributor' } |
      Select-Object @{n='Workspace';e={$_.DisplayName.Split('/')[-1]}}, DisplayName, SignInName, ObjectType, RoleDefinitionName |
      Format-Table -AutoSize
  }
}

# 4) Review workspace managed identities and their downstream access
Write-Host "Review each workspace's managed identity role assignments on Storage, Key Vault, ACR, and Azure OpenAI. Least privilege or bust." -ForegroundColor Yellow

Any role assignment on these scopes that your platform team cannot attribute to a known person or pipeline is an escalation-of-privilege lead — treat it as an incident until proven otherwise.

Remediation

  1. The patch itself: None required — Microsoft remediated CVE-2026-85889 in the Azure AI Foundry service. Confirm this verbally with your TAM or via the Microsoft Security Response Center advisory for your records and compliance evidence.
  2. Retrospective validation (do this now): Run the KQL hunts above across the longest retention window you have. Look specifically at the 30 days preceding Microsoft's patch announcement. Document findings — your auditors and, potentially, your cyber insurer will ask.
  3. Enable and centralize logging: Every AI Foundry / ML workspace must stream Azure Activity Logs and resource diagnostic logs to your SIEM. The verification script above identifies gaps. If you had no diagnostic settings during the exposure window, note it as a detection-coverage finding in your risk register.
  4. Lock down workspace identities: Audit managed identities attached to AI Foundry resources. Remove Owner/Contributor where narrower roles suffice. Scope Key Vault access to specific secrets, not the vault.
  5. Enforce Private Link / private endpoints on AI Foundry workspaces and disable public network access where operationally feasible — this collapses the network attack surface for any future service-adjacent flaw, even though CVE-2026-85889 lived in Microsoft's plane.
  6. Tighten RBAC change control: Alert on any roleAssignments/write touching ML/Cognitive Services resource providers. These changes should route through PIM-eligible assignments, not standing access.
  7. Monitor CISA KEV: If CVE-2026-85889 enters the catalog, BOD 22-01 timelines apply to federal agencies and the finding should auto-escalate in your vulnerability-management workflow regardless of sector.
  8. Tabletop the scenario: A compromised AI workspace identity reaching your training data, model weights, or Key Vault is a board-level incident. Rehearse it before you live it.

The Bottom Line

"No customer action required" describes the patch, not the response. A CVSS 10.0 unauthenticated privilege escalation in the platform that brokers your AI models, data connections, and service identities demands a retrospective hunt, a logging audit, and a hard look at workspace RBAC. The organizations that treat cloud CVEs as someone else's problem are the ones who discover — months later, during an unrelated IR engagement — that someone else treated their tenant as an opportunity.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.