Brief Summary: Azure Front Door CVE-2026-118742, an Incorrect Permission Assignment Enabling Unauthenticated Privilege Elevation

Introduction

A permissions flaw inside Azure Front Door, Microsoft's global edge delivery service, allowed an unauthenticated attacker on the network to elevate privileges, with Microsoft rating the confidentiality impact as High. AFD sits on the request path in front of the applications that customers place behind it. A weakness in how the service assigns permissions to its own critical resources is worth reading carefully for that reason, even though the fix lives on Microsoft's side of the shared responsibility line.

For readers less familiar with the service: Azure Front Door is Microsoft's cloud content delivery service. It provides global edge delivery, caching, SSL offload, origin load balancing, traffic routing, and health monitoring, along with network DDoS protection, an attachable web application firewall, and private origin connectivity through Azure Private Link. Microsoft is the second-largest cloud infrastructure provider, holding 19% of the worldwide market in Q3 2026 according to Synergy Research Group, although that figure measures cloud infrastructure services broadly rather than AFD on its own. Because AFD is an entry point for traffic routing and delivery, it is a central component in many Azure application architectures.

Technical information

Root cause

Microsoft describes the root cause as incorrect permission assignment for a critical resource in Azure Front Door, allowing an unauthorized attacker to elevate privileges over a network. MITRE defines the assigned weakness, CWE-732, as permissions that allow a security-critical resource to be read or modified by unintended actors.

In practical terms, some sensitive resource within AFD carried permissions loose enough that an unauthenticated party could reach it and obtain privileges they should not have had. That is as far as the public record goes. Microsoft has not identified which resource was affected, which permission entry was wrong, what endpoint or request format was involved, or what role an attacker ends up holding. No source diff, commit, or technical write-up has been published, so there is no code to show here.

What the CVSS vector tells us

Microsoft publishes the following base and temporal vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L/E:U/RL:O/RC:C

The Unproven exploit maturity and Official Fix remediation level pull the temporal score down to 7.5 from the 8.6 base.

The vector is easy to over-read in two ways. First, an unauthenticated attack profile does not by itself mean unlimited administrative control. The integrity and availability ratings are both Low, so the dominant consequence is information exposure. Second, an Unchanged scope does not answer which tenants, resources, or deployment boundaries are affected. The available sources do not establish cross-tenant compromise, Azure subscription takeover, or remote code execution.

Attack flow as described by the scoring

Microsoft has not published an exploitation sequence, so the only attack flow we can describe responsibly is the one encoded in the vector:

1. An attacker with network access reaches the affected AFD resource. No account, token, or prior foothold is required (PR:N).
2. No special timing, configuration race, or other high-complexity condition is needed (AC:L), and no AFD customer or administrator has to take any action (UI:N).
3. Because the critical resource's permissions admit unintended actors, the attacker gains privileges beyond what an anonymous party should hold.
4. The result is primarily disclosure of restricted information (C:H), with limited modification (I:L) and limited disruption (A:L).

Anything more specific, such as the request that triggers the issue or the data exposed, is not in the public record.

Exploitation status

Microsoft's exploitability table reflects the situation at original publication on November 10, 2026: Publicly disclosed: No, Exploited: No, Exploitability assessment: N/A. The N/A value is not a probability. OffSeq Threat Radar, also dated November 10, 2026, reports no evidence of exploitation, no CISA Known Exploited Vulnerabilities listing, no indexed public exploit in Metasploit or Exploit Database, no indexed Nuclei template, and no attack traffic on its own sensors. These are dated observations from limited vantage points, so the supported conclusion is that active exploitation is not confirmed in the available reporting.

Microsoft credits Muhammad Waseem (Institute for Art & Culture) for reporting the issue through coordinated disclosure. The credit names the researcher who reported the flaw and attributes no attack to anyone. No threat actor, campaign, or CVE-specific indicator of compromise has been published.

Patch information

What Microsoft shipped. Microsoft fixed CVE-2026-118742 with a vendor-side update listed in the Security Update Guide on November 10, 2026, as part of the 2026 Nov release. The advisory has a single row for the product Azure Front Door (Azure product family, base version 1.0.0, Max Severity Important, Impact Elevation of Privilege). Microsoft's public SUG API marks that product as fixed:

"productStatus":"fixed"

The temporal vector includes RL:O (Official Fix), meaning Microsoft considers this a complete vendor fix rather than a workaround.

What the fix corrects. A fix for a CWE-732 bug tightens the access controls on the affected resource so that only properly authorized principals can read or change it. Microsoft has not said which resource was affected or which permissions changed.

How versioning works here. AFD is a managed global edge service, so there is no build number or installer to track:

• The CNA record lists the affected range as version 1.0.0 with lessThan: "publication" (type custom). The service was vulnerable until Microsoft published the advisory, and the fix is in the service as Microsoft runs it.
• The advisory's Build Number column is empty, and the API returns an empty affected binaries list:

"affectedBinaries":[]

• The kbArticles entry states:

"rebootRequired":"No"

• The CVE.org record tags the MSRC advisory as both a vendor advisory and a patch, so the MSRC page itself is the official patch reference.

Discrepancies worth tracking.

1. Customer action flag. Both SUG API endpoints return the following, which is unusual for a service-side Azure fix that Microsoft normally marks as needing no customer action:

"customerActionRequired":true

The advisory has no FAQ explaining what customers would need to do, so it is unclear whether the flag reflects a real tenant-side step or a metadata error. Only revision 1.0, "Information published," exists as of November 10, 2026. Defenders should watch the advisory for revisions.

2. Placeholder links. The Release Notes link points to what looks like an internal Azure DevOps work item, and the Security Update download link is only the root of a CDN host. Neither contains AFD-specific fix details, so neither should be treated as evidence of what changed.

3. Rollout completeness. Microsoft marks the product fixed and the fix official, but the published material does not explicitly state that the fix has reached every AFD edge location. A recorded fix status is not proof that a specific environment has completed remediation.

Affected systems and versions

• Product: Microsoft Azure Front Door (Azure product family)
• Version range: version 1.0.0 with lessThan: "publication" (custom version type), meaning the service as operated before the November 10, 2026 advisory
• Build numbers: none published (the advisory's Build Number column is empty and the affected binaries list is empty)
• Vulnerable configurations: not disclosed. Microsoft has not identified a specific AFD tier, feature, or customer setting that is required for exploitation

Because AFD is a managed service, there is no customer-side version comparison to perform. The open question is the meaning of the customerActionRequired flag, not which build to install.

Vendor security history

The Cyber Safety Review Board's review of the 2023 Exchange Online intrusion offers an independent view of Microsoft's track record. That intrusion compromised mailboxes at 22 organizations and over 500 individuals and was attributed to an espionage actor. The Board concluded the intrusion was preventable, identified a cascade of avoidable errors, and found Microsoft's security culture inadequate and in need of an overhaul. This is a separate historical incident with no connection to CVE-2026-118742.

Microsoft's July 2026 Secure Future Initiative progress report describes its corrective work: decommissioning 1.4M unused Entra applications, advancing credential isolation across boundaries to 98.7%, and expanding secure tenant creation, least privilege, and drift detection. These are Microsoft's own reported outcomes. The CSRB documents a past failure independently, while SFI documents stated progress. Neither tells us anything about the exploitation status or remediation completeness of this AFD issue.

References

• NVD entry for CVE-2026-118742
• CVE.org record for CVE-2026-118742
• Microsoft Security Update Guide: Azure Front Door Elevation of Privilege Vulnerability
• MSRC SUG API: vulnerability record
• MSRC SUG API: affected product record
• CVE Services API record (cveawg.mitre.org)
• MITRE CWE-732: Incorrect Permission Assignment for Critical Resource
• OffSeq Threat Radar: Azure Front Door, Incorrect Permissions (CWE-732 record)
• OffSeq Threat Radar: Azure Front Door (AFD), Incorrect Permissions
• Microsoft Learn: Azure Front Door overview
• CISA Known Exploited Vulnerabilities Catalog
• Cyber Safety Review Board: Review of the Summer 2023 Microsoft Exchange Online Intrusion
• Microsoft Secure Future Initiative Progress Report, July 2026
• Synergy Research Group: Q3 2026 cloud market report