A CRITICAL-badged Azure bug that quietly only affects the on-prem hybrid product almost nobody runs
CVE-2026-58630 is an *improper access control* flaw (CWE-284) in the App Service resource provider on Azure Stack Hub — Microsoft's on-premises hybrid-cloud appliance. Per the July 23 advisory, an unauthenticated network-adjacent attacker can bypass authorization boundaries to elevate privilege inside the App Service RP, potentially reading tenant deployment credentials, publishing profiles, and service-to-service tokens. Affected versions are not enumerated in the advisory; Microsoft directs operators to cross-reference their Azure Stack Hub build+hotfix level against App Service release notes. The public Azure PaaS *.azurewebsites.net fleet is not in scope.
The vendor's CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N) is technically correct — the vector chain is genuinely unauthenticated, network-reachable, with a scope change into other tenants — but the label is misleading in operational terms. Azure Stack Hub is a niche appliance (sovereign cloud, defense, disconnected edge). The blast radius per deployment is legitimately high because you're breaking multi-tenant isolation, but the *reachable population* is a rounding error compared to what 'Azure App Service CRITICAL 10' suggests to a triage queue. That mismatch is why we drop this to HIGH, not because the bug is weak.
4 steps from start to impact.
Reach the Azure Stack Hub App Service management endpoint
- Network path to the Stack Hub App Service RP endpoints
- DNS resolution for the tenant/admin portal FQDNs
- Azure Stack Hub is nearly always deployed on segmented management networks
- Many operators front the portals with a reverse proxy + client cert auth
Trigger the access-control bypass in the App Service RP
PR:N and UI:N, no valid tenant credential or user interaction is required — the RP fails to enforce authorization on a path that should require an authenticated principal. Exact call signature has not been published.- Vulnerable Stack Hub build without the July 2026 App Service RP hotfix
- No public PoC as of 2026-07-25
- Reproducing requires a Stack Hub lab, which few researchers own
/subscriptions/*/providers/Microsoft.Web/*Escalate into cross-tenant App Service functions
curl plus Microsoft's own ARM REST client; no exotic tooling required.- Successful bypass from step 2
- Other tenants have active App Service workloads
- Small Stack Hub deployments may have only one or two tenants — limits cross-tenant value
Pivot to hosted workloads and downstream identity
- Tenant workloads hold MSI grants to sensitive backends
- Well-scoped MSI role assignments and Key Vault access policies limit blast
Microsoft.Web/* provider paths, and for Kudu deployment activity from IPs outside your CI/CD ranges. Backdate the hunt 30 days once deployed.- Azure WAF / Front Door rules — you're on Stack Hub, not public Azure, and the vulnerable endpoints are internal management-plane APIs, not tenant HTTP workloads.
- Public Azure Defender for App Service — its coverage is for the public PaaS; the Stack Hub connector has different, weaker telemetry.
- Rotating tenant *user* passwords — the flaw is
PR:N, so no credential is being abused in the initial call; user password rotation doesn't touch the attack path. - Network-based IPS signatures — no public PoC or traffic signature exists yet; signature vendors have nothing to write.
The supporting signals.
| In-the-wild status | No active exploitation observed as of 2026-07-25. Not on CISA KEV. |
|---|---|
| Public PoC | None published. No GitHub repos, no Metasploit module, no researcher writeup beyond the MSRC advisory. |
| EPSS | Not yet scored by FIRST — advisory is <48h old. Expect initial score <1% given zero PoC and niche footprint. |
| KEV status | Not listed. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N — unauthenticated network, scope-changed, confidentiality+integrity impact, no availability hit. Vendor score 10.0 CRITICAL. |
| Affected component | Azure Stack Hub App Service resource provider — on-premises only. Public Azure App Service (*.azurewebsites.net) is not affected per the MSRC advisory. |
| Fixed versions | Microsoft directs operators to the latest App Service on Azure Stack Hub RP update; specific build/hotfix numbers are on the MSRC portal (MSRC/update-guide/vulnerability/CVE-2026-58630). |
| Exposure data | Azure Stack Hub is not enumerable via Shodan/Censys/GreyNoise in any meaningful way — management endpoints live on internal VLANs. Installed base is estimated in the low thousands globally (defense, sovereign cloud, telco edge). |
| Disclosure date | 2026-07-24 (MSRC public advisory). Coordinated disclosure; no zero-day window reported. |
| Credit | Microsoft Security Response Center advisory does not currently name an external reporter — likely internal Microsoft finding. |
Sources.
- MSRC Security Update Guide — CVE-2026-58630
- Windows News — July 23 Advisory: CVE-2026-58630 Azure Stack Hub App Service EoP
- TheHackerWire — Critical Azure App Service Privilege Escalation
- Azure App Service on Azure Stack Hub — release notes
- Azure App Service Security FAQs — Microsoft Learn
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS
- CWE-284: Improper Access Control
Why this verdict
- Product scope narrows the population by ~1000x: vendor CRITICAL 10 implies every App Service tenant on Earth, but MSRC scopes this to Azure Stack Hub only. Baseline drops from 'internet-facing PaaS' to 'niche on-prem appliance.'
- Management plane is internal by design: Stack Hub tenant and admin portal endpoints are almost universally on segmented VLANs, not routable from the internet.
AV:Nis technically true but the reachable N is tiny. - No PoC, no KEV, no observed campaigns 24 hours post-disclosure. First public exploitation typically lags Stack Hub advisories by weeks or is never observed at all.
- Role multiplier — App Service RP is a multi-tenant control plane: if the chain lands, tenant isolation breaks and MSI tokens / publishing profiles leak across tenants on that Stack Hub. That is the CRITICAL-floor blast radius for a PaaS host, which is why we do not drop below HIGH.
- Role multiplier — Stack Hub deployments skew sovereign/defense/telco-edge: the small population that IS affected tends to run high-consequence workloads, so a HIGH is not a shrug — it is a real 30-day-mitigate obligation for that subset.
Why not higher?
CRITICAL would be appropriate if this hit public Azure App Service or if there were an active PoC. Neither is true: the population is a small on-prem appliance base, management endpoints are internal, and no weaponization exists 24h in. Reserving CRITICAL for cases with real-world exploitability keeps the queue meaningful.
Why not lower?
MEDIUM would ignore the role multiplier — the affected component is a multi-tenant PaaS control plane, and a successful chain breaks tenant isolation. Any bug that leaks credentials across tenant boundaries on a hosting platform floors at HIGH, even with a small install base and no PoC.
Crowdsourced verification payload.
Run this from a Stack Hub operator workstation with the Az.Stack / AzureStack PowerShell modules installed and an admin login to the Stack Hub admin ARM endpoint. Invoke as: .\Check-CVE-2026-58630.ps1 -AdminArmEndpoint 'https://adminmanagement.<region>.<fqdn>' -FixedBuild '2026.07.0'. Requires Stack Hub *operator* role to read the RP version.
#requires -Modules AzureStack
# Check-CVE-2026-58630.ps1
# Reports whether the App Service resource provider on this Azure Stack Hub
# stamp is at or above the fixed build for CVE-2026-58630.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
param(
[Parameter(Mandatory=$true)][string]$AdminArmEndpoint,
[Parameter(Mandatory=$true)][string]$FixedBuild # from MSRC advisory, e.g. '2026.07.0'
)
$ErrorActionPreference = 'Stop'
try {
# Assumes operator has already run Add-AzEnvironment + Connect-AzAccount to the admin endpoint
$ctx = Get-AzContext
if (-not $ctx) { Write-Error 'Not logged in. Run Connect-AzAccount against the Stack Hub admin endpoint first.'; exit 2 }
# Query the App Service resource provider status
$rp = Get-AzsAppServiceStatus -ErrorAction Stop
if (-not $rp -or -not $rp.Version) {
Write-Output 'UNKNOWN - App Service RP not installed or version unreadable'
exit 2
}
$installed = [version]$rp.Version
$fixed = [version]$FixedBuild
Write-Output "Installed App Service RP: $installed"
Write-Output "Fixed build required: $fixed"
if ($installed -ge $fixed) {
Write-Output 'PATCHED'
exit 0
} else {
Write-Output 'VULNERABLE - upgrade App Service RP to the MSRC-listed build'
exit 1
}
}
catch {
Write-Output "UNKNOWN - $($_.Exception.Message)"
exit 2
}