From the Microsoft edition of November 10, 2026
November Patch Tuesday: critical Azure OpenAI flaw CVE-2026-119990 (CVSS 9.8, no authentication), with conflicting guidance on customer action
Trend Micro Zero Day Initiative (analysis of Microsoft security update) · Cross-SLED (Azure OpenAI tenants in government and education) · Global; applies to U.S. SLED Azure OpenAI users
- Publisher
- Zero Day Initiative blog
- Original publication
- 2026-11-10
- Source retrieved
- 2026-11-11
- Event date
- 2026-11-10
What happened
Microsoft's Nov. 10 release included CVE-2026-119990, an Azure OpenAI elevation-of-privilege flaw rated Critical, CVSS 9.8. ZDI says the advisory FAQ describes an unauthenticated attacker sending a crafted internet request to an affected Azure OpenAI service, with impact on orchestration information, workflow changes or service disruption. ZDI notes the bulletin first said 'Customer Action Required: Yes' without steps, then Microsoft revised it to say no customer action is needed. NVD lists it as CWE-306 (missing authentication), published Nov. 10, awaiting analysis; CSO Online reports the service is patched by Microsoft. ZDI lists it as neither public nor exploited. Azure OpenAI was one of four Critical Azure and identity bugs.
Why it matters
State agencies, cities and universities running chatbots, document processing or agents on Azure OpenAI depend on Microsoft's server-side fix, so the work for SLED teams is verification and documentation, not patching. Interpretation: a critical no-auth flaw in a managed AI service is a reminder to include AI platform services in vulnerability tracking and vendor-risk reviews.
Evidence and measured results
Independent security-research analysis of Microsoft's advisory data, corroborated by the NVD record (CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N, 9.8) and CSO Online reporting. No exploitation data; affected-build detail and exposure window not confirmed from Microsoft's advisory page, which was not opened.
Limitations and uncertainty
Microsoft's own advisory (msrc.microsoft.com) was not opened directly; details are from ZDI, NVD and CSO. No confirmed exposure window, affected configurations or exploitation evidence. Guidance changed on release day and may change again.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-11; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- SLED organizations using Azure OpenAI may not track vulnerabilities in managed AI services or know when vendor guidance changes.
- Stakeholders
- CISO
- Agency or campus CIO
- AI program lead
- Application owners of Azure OpenAI workloads
- Vendor risk management
- Discovery questions
- Which applications use Azure OpenAI, and in which subscriptions?
- Does vulnerability tracking include cloud AI service advisories?
- Who monitors revisions to Microsoft advisories?
- Are Azure OpenAI endpoints restricted to private networks?
- Value hypothesis
- A structured review can confirm coverage of AI services in vulnerability and vendor-risk processes and reduce surprise from advisory changes.
- Potential engagement
- A short Azure OpenAI security posture and advisory-monitoring review across the client's subscriptions.
- Unsupported claims
- That any client was compromised
- That customer action is required
- Exposure window or affected configurations
- That Azure Government instances were or were not affected
Pre-sales engineering
Role takeaway
- Fit
- Any SLED tenant with Azure OpenAI or Foundry deployments, including departmental and research subscriptions.
- Architecture and integration
- Azure OpenAI sits behind chatbots, retrieval pipelines and agents; the flaw's impact on orchestration and workflows maps to those layers.
- Prerequisites
- Inventory of Azure OpenAI resources
- Diagnostic logging enabled
- Network access configuration documented
- Constraints
- Server-side fix controlled by Microsoft
- Advisory details incomplete on release day
- Government-cloud coverage not stated in sources
- Security
- Restrict public network access, use managed identities rather than keys where possible, and retain logs to support review once the exposure window is published.
- Proof of value
- Confirm all Azure OpenAI resources identified
- Log review completed for the published window
- Advisory status re-checked after revisions
Delivery
Role takeaway
- Work
- Add cloud AI services to Patch Tuesday triage and the AI system inventory, with documented advisory status per workload.
- Dependencies
- Complete AI system inventory
- Security operations capacity
- Access to Azure activity and diagnostic logs
- Ownership
- Agency or campus security operations, with each AI workload's application owner.
- Skills and adoption
- Brief security analysts on reading cloud-service advisories and 'customer action' fields.
- Governance checkpoints
- Monthly triage includes Azure AI advisories
- Owner sign-off on advisory status per workload
- Escalation if guidance changes
- Acceptance criteria
- 100% of Azure OpenAI resources mapped to an owner
- Advisory status recorded within one business day of release
- Log review evidence retained for audit
- Risks
- Shadow Azure OpenAI deployments missed
- Guidance changes unnoticed
- Assuming managed service means no verification
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Applications built on Azure OpenAI rely on the provider's patching of the managed service; orchestration and workflow layers named in the impact description sit inside many agent and RAG designs.
Governance
Who approves, reviews and stays accountable for outcomes?
Vulnerability management programmes that track only on-premises patches may miss cloud AI advisories; the revised 'customer action' field shows why advisory changes need monitoring after release day.
Security and privacy
What data, permissions and controls need testing?
Potential unauthorized access to orchestration information and workflow tampering in AI services handling resident or student data; agencies should check logs for anomalous activity during the exposure window once Microsoft documents it.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Security analysts need skills to interpret cloud-service advisories and changing 'customer action' fields; no accessibility impact.
Procurement
What should contracts, pricing and exit terms secure?
Vendor-risk reviews and contracts for AI services should address advisory notification and customer-action communication.
Operating model
Which teams own the service once it runs?
Cloud AI advisories added to monthly security triage with named workload owners.
Publication history
- 2026-11-10Microsoft · Issue 124 resources
Stable resource ID: azure-openai-cve-2026-119990-critical-missing-auth-patch-tuesday-20261110