Lighthouse AdvisorySLED AI Adoption Intelligence
← Back to results

From the Microsoft edition of November 10, 2026

Independent researchCautionaryNew this fortnight

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
Read original source

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

  1. 2026-11-10Microsoft · Issue 124 resources
Read preserved resource versions (JSON)

Stable resource ID: azure-openai-cve-2026-119990-critical-missing-auth-patch-tuesday-20261110