Improper authorization in Azure Portal

CVE-2026-62835 is an improper authorization flaw (CWE-285) in the Azure Portal control plane that let an unauthenticated network attacker read information they should not have access to. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L describes a scope-changing confidentiality bug — the attacker crosses a trust boundary and reads data belonging to another tenant/principal. Microsoft assigned it CRITICAL 9.3. Affected component is the Azure Portal SaaS service itself, not any tenant-installed software; no version range applies because Microsoft operates and versions the code.

The vendor score is technically defensible on impact grounds — a scope-changed unauthenticated info-disclosure at the portal plane earns a 9.x — but it is badly misaligned with defender workload. This is a *cloud-provider-side* bug fixed server-side by Microsoft on 2026-07-24. There is no MSI, no RPM, no container to push. For anyone managing 10,000 hosts, this CVE generates zero patch tickets and the only real action is a historical log sweep, so the operational severity is LOW even though Microsoft's advisory sits at CRITICAL.

Why this verdict

• No customer patch surface. Azure Portal is Microsoft-hosted; the fix ships when Microsoft deploys it, not when you approve a change ticket. Vendor CRITICAL scores assume a customer must act — here they do not.
• Read-only impact. I:N and A:L mean no tenancy takeover, no persistence, no configuration change. The worst realistic outcome is metadata leakage that the tenant owner cannot retroactively contain.
• Friction audit — patch window is already closed. The prerequisite chain (reach portal → trigger authz bypass → read cross-scope data) required the pre-patch code path, which no longer exists post-2026-07-24. New exploitation is not possible.
• Role multiplier: Azure Portal is a canonical identity-plane component. If exploitation had occurred pre-patch against a high-value tenant (e.g., an enterprise with privileged service principals or subscription metadata leakage), the blast radius would be tenant-scale reconnaissance for follow-on attacks. This is why the audit-log review below is non-negotiable — but the *future* action is capped by the fact that Microsoft closed the door.
• No installed-base share reasoning needed to break the floor — the affected component is Microsoft-operated, so the 'installed base' is Microsoft's fleet, not yours. The Role-Multiplier floor rule does not fire against a customer patch queue when the customer cannot patch.

Why not higher?

A MEDIUM or higher verdict would imply a customer remediation deadline, but there is nothing to remediate. Assigning HIGH/CRITICAL to a server-side-patched SaaS CVE inflates queue noise and trains teams to ignore the noisgate labels. The read-only impact and the closed exploitation window both cap this well below MEDIUM.

Why not lower?

This is not IGNORE because there is a real, non-zero action item: audit Azure Activity Log, Sign-in Log, and Microsoft 365 audit trails for the pre-patch window (roughly 30-90 days before 2026-07-24) for anomalous cross-tenant enumeration, and watch for MSRC customer-impact notifications. If Microsoft later notifies your tenant that data was accessed, this jumps to HIGH immediately.

1. Audit Azure logs for the pre-patch window — Review Azure Activity Log, Azure AD Sign-in Log, and Microsoft 365 Unified Audit Log for the 90 days preceding 2026-07-24, looking for unexpected read/list operations against subscriptions, resource groups, or directory objects — especially from unfamiliar IPs or service principals. No noisgate mitigation SLA applies (verdict is LOW); complete this as backlog hygiene within 30 days.
2. Subscribe to MSRC customer-impact notifications — If Microsoft determines your tenant was affected, you will receive a Message Center or MSRC notification. Ensure your Azure security contact and Message Center recipients are current — many orgs still route these to a defunct DL. Verify this week.
3. Rotate any secrets that would have been visible via portal blades — As a precaution, if the pre-patch behavior potentially leaked *names* of Key Vault entries, storage accounts, or service principals, treat the *names* as public but the *contents* as still-trusted. Rotate any credentials whose existence being known would materially reduce security (e.g., predictable naming conventions for high-value SPs).
4. Enforce Conditional Access + Continuous Access Evaluation on portal.azure.com — Independent of this CVE, restricting portal access to managed devices with compliant posture reduces the blast radius of any future portal-plane authz bug. Deploy via Azure AD Conditional Access targeting the *Microsoft Azure Management* app.

Run this from an auditor workstation with the Az PowerShell module and Microsoft.Graph installed, using an account with Reader on the target subscription and AuditLog.Read.All in Entra ID. Invoke as ./Check-CVE-2026-62835.ps1 -SubscriptionId <sub-guid> -LookbackDays 90. This does not check for a patch (there is none to check) — it verifies your log-audit posture and surfaces suspicious pre-patch read activity.

#!/usr/bin/env pwsh
# Check-CVE-2026-62835.ps1
# Verifies audit-log coverage and surfaces suspicious portal-plane reads
# in the pre-patch window for the Azure Portal information-disclosure CVE.
# Exit codes: 0=PATCHED (server-side, MS-managed), 1=UNKNOWN (audit gap), 2=VULNERABLE (suspicious activity found)

param(
    [Parameter(Mandatory=$true)][string]$SubscriptionId,
    [int]$LookbackDays = 90
)

$PatchDate = Get-Date '2026-07-24T00:00:00Z'
$StartDate = $PatchDate.AddDays(-$LookbackDays)
$EndDate   = $PatchDate

Write-Host "[*] CVE-2026-62835 verifier — Azure Portal server-side patched $PatchDate"
Write-Host "[*] Audit window: $StartDate -> $EndDate"

try {
    Import-Module Az.Accounts -ErrorAction Stop
    Import-Module Az.Monitor  -ErrorAction Stop
} catch {
    Write-Host "UNKNOWN: Az modules not installed"; exit 1
}

if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null }
Select-AzSubscription -SubscriptionId $SubscriptionId | Out-Null

# Pull Activity Log read operations from the audit window
$events = Get-AzLog -StartTime $StartDate -EndTime $EndDate -MaxRecord 5000 -WarningAction SilentlyContinue |
    Where-Object { $_.OperationName.Value -match '/(read|list)$' }

if (-not $events) {
    Write-Host "UNKNOWN: no Activity Log entries returned — verify diagnostic settings retain >=90 days"
    exit 1
}

# Heuristic: flag caller IPs that performed >500 reads across >20 distinct resource types
$suspects = $events |
    Group-Object CallerIpAddress |
    Where-Object { $_.Count -gt 500 -and ($_.Group.ResourceType.Value | Sort-Object -Unique).Count -gt 20 }

if ($suspects) {
    Write-Host "VULNERABLE: $($suspects.Count) caller IP(s) show broad enumeration patterns in pre-patch window"
    $suspects | Select-Object Name, Count | Format-Table
    exit 2
}

Write-Host "PATCHED: Microsoft fixed server-side on $PatchDate; no suspicious pre-patch enumeration detected in this subscription"
exit 0

Sources

1. MSRC advisory — CVE-2026-62835
2. NVD — CVE-2026-62835
3. THREATINT — CVE-2026-62835
4. WindowsNews analysis — undisclosed online-service CVE
5. Talos — Microsoft Patch Tuesday July 2026
6. CWE-285 — Improper Authorization
7. CISA KEV catalog
8. Microsoft — Coordinated disclosure for online services