Vulnerability severity (CVE-2025-29827): CVSS 9.9 / EPSS 0.81 (Source: National Vulnerability Database & Microsoft Security Response Center advisory, CVE-2025-29827 (accessed July 2026); EPSS 0.81 sits above the 0.5 high-risk exploitation-probability threshold)
A Default Setting, A Crossed Boundary
A default configuration inside Microsoft Azure Automation, addressed this year, could let an attacker who controlled one Azure tenant reach into another tenant's identity, credentials, and cloud workloads. Microsoft's fix required zero customer action — the setting was changed server-side, silently, across the service. But the underlying pattern is one WebPulse tracks across every layer of the modern stack: defaults set by the vendor, not the customer, decide who is exposed before a single line of application code ever runs.
How the Chain Worked
The flaw, tracked as CVE-2025-29827, lived in how Azure Automation accounts identified themselves across tenant boundaries. Automation accounts use managed identities to run scripts and reach resources without stored credentials — a design meant to reduce risk, not add it. Security researcher Shay Shavit, on Microsoft's own Azure Networking Security Research team, found that the endpoint an automation account used to assert its identity was, by default, reachable outside its own tenant. An attacker who understood the chain could, per Dark Reading's reporting, use their own legitimate Automation account as a foothold to assume another organization's automation identity — and from there, the data, credentials, and workloads that identity was trusted to touch.
This is a trust-boundary failure, not an application bug. No plugin, no theme, no framework choice inside the customer's own tenant would have prevented it or surfaced it. The fix lived entirely in Microsoft's control plane, outside any customer's visibility or configuration options.
Patched Server-Side, No Known Exploitation
Microsoft has stated the vulnerability required no customer action to resolve — the default was changed at the service level rather than pushed to tenants as a patch. Dark Reading reports no known instances of exploitation in the wild. Shavit is scheduled to detail the full research at Black Hat USA in August 2026, roughly a year after his original report reached the Microsoft Security Response Center.
The Layer Framework Scores Don't See
For a budget-signer, the distinction between "our application was breached" and "the cloud provider's tenant isolation had a gap" is not academic. One is addressed by internal security spend. The other is addressed by vendor accountability, contract terms, and shared-responsibility clarity — questions worth raising with whichever cloud provider hosts the automation, identity, or build pipeline sitting behind a customer-facing site.
WebPulse's per-framework scoring pulls security signal from public CVE and CISA KEV data tied to the framework itself — WordPress core, a Next.js dependency, a Drupal module. That data has no visibility into the identity and access-management layer of the cloud account hosting the site. A site running a framework with a clean CVE record can still sit on infrastructure carrying a trust-boundary flaw like this one. The two are measured separately because they are, structurally, separate risks — but only one of them shows up in a framework scorecard.
For organizations weighing where to spend security budget, the distinction matters. Framework-layer hardening — patching, dependency management, plugin hygiene — addresses one exposure surface. Identity and access configuration in the cloud accounts that host, build, or automate that framework is a separate surface, controlled by a separate vendor, on a separate patch cycle. Neither substitutes for the other, and a clean scan on one says nothing about the state of the other.
