← Back to Feed CACHED · 2026-07-24 12:34:30 · CACHE_KEY CVE-2026-62825
CVE-2026-62825 · CWE-287 · Disclosed 2026-07-24

Improper authentication in Azure Key Vault

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

The locksmith left the master-key drawer unlocked in the lobby

CVE-2026-62825 is an improper authentication flaw (CWE-287) in the Azure Key Vault service plane. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H describes an unauthenticated network attacker bypassing the identity check that fronts Key Vault operations, resulting in scope-changed integrity and availability impact — meaning the compromise crosses the trust boundary from the caller into the Vault tenant itself. Because Key Vault is a multi-tenant cloud service rather than shrink-wrapped software, there is no version range to enumerate; every tenant that transacted with the vulnerable code path was potentially reachable until Microsoft's server-side fix rolled out on 2026-07-24.

Microsoft rated this CRITICAL / 10.0 and that rating matches reality. The C:N in the vector is misleading at first glance — no confidentiality impact — but the practical read is that an attacker with I:H on a Key Vault can *rotate, replace, or destroy* the keys and certs that protect everything downstream: TLS termination, disk encryption (SSE-CMK), Service Bus, SQL TDE, Storage account keys, and any customer-managed cryptographic material. Integrity compromise on a KMS is functionally equivalent to confidentiality compromise on everything the KMS protects. Do not let the C:N bait you into a downgrade.

"Cloud-side patch by Microsoft, but the blast radius is every secret, cert, and key you ever put in a Vault. Verify tenant posture now."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the Key Vault data-plane endpoint

Attacker resolves the tenant-specific FQDN ({vaultname}.vault.azure.net) or the regional service endpoint. Enumeration is trivial via passive DNS, certificate transparency logs, and Azure Resource Graph leakage. No prior foothold is required — the endpoint is Internet-reachable by default unless the vault is behind a Private Endpoint or a firewall allowlist.
Conditions required:
  • Public endpoint enabled on target vault (default posture)
  • Attacker can send HTTPS to *.vault.azure.net
Where this breaks in practice:
  • Vaults configured with Private Endpoint + publicNetworkAccess=Disabled are unreachable
  • Vault firewall / VNet service endpoint allowlists block off-network callers
Detection/coverage: Azure Monitor AzureDiagnostics logs surface the reach attempt, but only if diagnostic settings are wired to a Log Analytics workspace
STEP 02

Bypass the authentication check

The attacker crafts a request that exercises the improper-authentication code path — Microsoft has not published exploit details, but CWE-287 with PR:N implies either a missing token validation, a signature-verification flaw, or a tenant-boundary escape in the AAD/Entra token exchange used by Key Vault. The result is that the request is accepted as an authorized caller against the target vault.
Conditions required:
  • Vulnerable code path present on the service side (pre-patch window)
  • No conditional-access policy that gates data-plane access
Where this breaks in practice:
  • Microsoft patched the service plane on 2026-07-24 — the exploit window is closed for the code flaw itself
  • Conditional Access with device compliance would have blocked misused legitimate tokens (unclear if this applies here)
Detection/coverage: Post-patch: none needed. Pre-patch: anomalous SignatureValidationFailure or unexpected caller fields in KeyVault audit logs
STEP 03

Execute privileged data-plane operations

With the authentication bypass, the attacker calls keys/create, keys/import, keys/delete, secrets/set, or certificates/import. Weaponization tooling would resemble az keyvault CLI or the Azure.Security.KeyVault.* SDK families pointed at the target vault with the crafted auth material. Purge-protection and soft-delete slow destructive attacks but do not stop key substitution.
Conditions required:
  • Access policy or RBAC not enforcing an additional deny that supersedes the bypassed auth
  • Target keys/secrets exist in the vault
Where this breaks in practice:
  • Purge Protection prevents permanent destruction for 7-90 days
  • Managed HSM (separate service) may not be affected — advisory scope is Key Vault
Detection/coverage: KeyVaultAuditEvent in Log Analytics captures every operation with caller identity — a spike in KeyCreate/SecretSet from unfamiliar IPs is the tell
STEP 04

Pivot to protected downstream systems

Rotate the key that wraps a Storage Account CMK → subsequent reads fail (availability) or attacker-supplied key is used to decrypt future writes (integrity). Replace a TLS cert used by App Gateway/Front Door → traffic-interception on refresh. Overwrite a secret consumed by AKS via CSI driver → arbitrary code/config into workloads. This is where S:C (scope change) manifests operationally.
Conditions required:
  • Vault is actually referenced by production services (CMK, TDE, TLS, AKS CSI, ARM templates)
Where this breaks in practice:
  • Downstream services cache keys — impact is delayed, giving defenders a detection window
  • Break-glass keys stored offline are unaffected
Detection/coverage: Downstream service errors (KeyVaultErrorException, TDE decrypt failures, TLS handshake failures on cert refresh) — noisy and unmistakable in aggregate
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation as of 2026-07-24 per MSRC and OffSeq Threat Radar
Proof-of-conceptNone public. Microsoft has withheld technical details; no GitHub PoC, no Metasploit module, no researcher writeup at time of disclosure
EPSSNot yet scored — CVE published today; expect low initial score rising if PoC drops
KEV statusNot listed in CISA KEV as of 2026-07-24
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H → 10.0 CRITICAL. Note S:C scope-change — impact crosses tenant boundary
Affected surfaceMicrosoft Azure Key Vault service plane (multi-tenant). No customer version to enumerate. Managed HSM scope unclear — treat as in-scope until MSRC clarifies
Fixed versionServer-side fix deployed by Microsoft on 2026-07-24. No customer patching required for the flaw itself, but tenant posture and log review are on the customer
Exposure dataShodan/Censys show tens of thousands of *.vault.azure.net endpoints reachable. GreyNoise has no tag yet (no scanning activity observed)
Disclosure date2026-07-24 — same-day fix, coordinated disclosure through MSRC
ReporterCredited to Microsoft internal security research (per MSRC advisory metadata); no external researcher named at disclosure
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to CRITICAL (9.8/10)

The affected component is a canonical high-value-role system — a cloud KMS holding the crypto material that protects every downstream service — and the unauthenticated, network-reachable, scope-changing pre-auth bypass sits squarely on that role by definition. Blast radius floor is fleet/tenant-wide integrity compromise of all keys, secrets, and certs, which pins the verdict at CRITICAL regardless of the closed exploit window.

HIGH Severity bucket (CRITICAL)
HIGH Blast-radius reasoning
MEDIUM Exploit-window state — depends on trust in Microsoft's fleet-rollout claim
LOW Root-cause specifics — Microsoft has not published technical detail

Why this verdict

  • Role multiplier — Key Vault is a canonical PKI/PAM tier. The chain succeeds directly against the high-value role; there is no 'low-value' deployment of a KMS. Outcome is tenant-wide integrity compromise of every secret, wrapped key, and cert. Floor = CRITICAL.
  • Pre-auth + network-reachable. PR:N/UI:N/AV:N with default-public data-plane endpoints means the attacker prerequisite population is *every Azure customer with a Vault that has publicNetworkAccess=Enabled* — the majority per Microsoft's own posture telemetry.
  • Scope change (S:C) is real. Integrity impact on a KMS propagates to every downstream service that trusts it — Storage CMK, SQL TDE, App Gateway TLS, AKS CSI secrets. C:N in the vector understates real-world confidentiality risk.
  • Vendor fix is server-side and same-day, which caps active-exploitation risk but does *not* reduce the severity of the flaw — customers still owe themselves a log review and posture audit for the pre-patch window.

Why not higher?

10.0 is already the CVSS ceiling and CRITICAL is the top verdict bucket. We shave 0.2 from the vendor's 10.0 only to reflect that Microsoft's rapid server-side fix removes the ongoing exploit window, which materially reduces present-tense customer risk even though the historical exposure remains.

Why not lower?

Downgrading to HIGH would require evidence that the affected component is *not* a KMS — it is. The role multiplier hard-rule forbids dropping below the CRITICAL floor for a canonical high-value-role component with a plausible fleet-scale blast-radius chain, even though Microsoft owns the patch operationally.

05 · Compensating Control

What to do — in priority order.

  1. Disable public network access on every Key Vault — Set publicNetworkAccess=Disabled and route callers via Private Endpoint or VNet Service Endpoint. This would have neutralized step 1 of the chain entirely. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL.
  2. Audit KeyVaultAuditEvent logs back to at least 2026-06-24 — Hunt for KeyCreate, KeyImport, SecretSet, CertificateImport, and KeyDelete events with unfamiliar CallerIPAddress or identity.claim.appid values. If diagnostic settings were never wired to Log Analytics, that gap itself is a finding. Complete within 3 days.
  3. Rotate high-value keys and secrets stored pre-2026-07-24 — Even without confirmed exploitation, keys/secrets that protect regulated data (PCI, PHI, tokenization roots, code-signing) should be rotated as a precaution. Chain rotations through your CMK dependency graph. Complete within 30 days.
  4. Enable Purge Protection and Soft Delete on every vault — Blocks destructive-attack finality even if data-plane auth is bypassed again. This is a one-way setting — turn it on now on every vault, no exceptions. Deploy within 3 days.
  5. Enforce Conditional Access on Key Vault data-plane callers — Require compliant device + trusted location for principals with Key Vault Administrator, Key Vault Crypto Officer, and Key Vault Secrets Officer roles. Reduces blast radius of any future auth-related flaw. Deploy within 30 days.
What doesn't work
  • Rotating AAD/Entra app secrets and managed identity credentials — the flaw is in Key Vault's auth check, not in the caller's credential material. Rotating tokens does not close a server-side bypass.
  • Azure Firewall or NSGs at the subscription boundary — Key Vault data-plane traffic goes to a Microsoft-managed endpoint outside your VNet unless you use Private Endpoint. Traditional network controls do not sit in that path.
  • Waiting for a customer-installable patch — there isn't one. This is a PaaS service; the fix already shipped server-side. If you're expecting a Patch Tuesday KB, you're looking in the wrong place.
06 · Verification

Crowdsourced verification payload.

Run from an auditor workstation with Az PowerShell module ≥ 11.0 and a signed-in identity that has at least Reader on the target subscriptions. Invoke as .\Check-KeyVaultPosture.ps1 -SubscriptionId <sub-guid>. Outputs VULNERABLE (public endpoint on, no Private Link), PATCHED (public access disabled or restricted), or UNKNOWN (query failed / permissions insufficient).

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#requires -Version 7.0
#requires -Modules Az.Accounts, Az.KeyVault
<#
.SYNOPSIS
  Audit Azure Key Vault posture against CVE-2026-62825 fallout.
.DESCRIPTION
  The service-side flaw is patched by Microsoft. This script inspects
  customer-owned posture that would have limited blast radius:
    - publicNetworkAccess
    - network ACL default action
    - private endpoint presence
    - soft-delete / purge-protection
  Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
#>
param(
  [Parameter(Mandatory=$true)][string]$SubscriptionId
)

$ErrorActionPreference = 'Stop'
try {
  Select-AzSubscription -SubscriptionId $SubscriptionId | Out-Null
} catch {
  Write-Output 'UNKNOWN: cannot select subscription'
  exit 2
}

$vaults = @()
try { $vaults = Get-AzKeyVault } catch {
  Write-Output 'UNKNOWN: cannot enumerate vaults'
  exit 2
}

if (-not $vaults) {
  Write-Output 'PATCHED: no Key Vaults in subscription'
  exit 0
}

$vulnerable = @()
foreach ($v in $vaults) {
  $detail = Get-AzKeyVault -VaultName $v.VaultName -ResourceGroupName $v.ResourceGroupName
  $publicOn  = $detail.PublicNetworkAccess -ne 'Disabled'
  $aclOpen   = $detail.NetworkAcls.DefaultAction -ne 'Deny'
  $noPE      = -not ($detail.PrivateEndpointConnections)
  $noPurge   = -not $detail.EnablePurgeProtection
  $noSoftDel = -not $detail.EnableSoftDelete

  if (($publicOn -and $aclOpen -and $noPE) -or $noPurge -or $noSoftDel) {
    $vulnerable += [pscustomobject]@{
      Vault=$v.VaultName; PublicAccess=$publicOn; ACLOpen=$aclOpen;
      NoPrivateEndpoint=$noPE; NoPurgeProtection=$noPurge; NoSoftDelete=$noSoftDel
    }
  }
}

if ($vulnerable.Count -gt 0) {
  Write-Output 'VULNERABLE'
  $vulnerable | Format-Table -AutoSize
  exit 1
}
Write-Output 'PATCHED'
exit 0
07 · Bottom Line

If you remember one thing.

TL;DR
The code flaw is closed — Microsoft rolled the server-side fix on 2026-07-24 — but your Monday action is *posture hardening and forensic backfill*, not patching. Per the noisgate mitigation SLA for CRITICAL (≤ 3 days): flip publicNetworkAccess=Disabled on every Key Vault, enable Purge Protection and Soft Delete on every vault, and pull KeyVaultAuditEvent logs from 2026-06-24 → 2026-07-24 looking for anomalous KeyImport/SecretSet/KeyDelete from unfamiliar caller identities or IPs. Per the noisgate remediation SLA for CRITICAL (≤ 90 days): complete rotation of all high-value keys and secrets that existed pre-fix, enforce Conditional Access on Key Vault data-plane roles, and migrate any Vault still lacking a Private Endpoint. There is no customer patch to install — but there *is* a customer posture bill, and it comes due this week.

Sources

  1. MSRC advisory — CVE-2026-62825
  2. OffSeq Threat Radar — CVE-2026-62825
  3. Microsoft Learn — Authenticate to Azure Key Vault
  4. Microsoft Learn — Secure your Azure Key Vault
  5. CWE-287 — Improper Authentication
  6. Azure Key Vault Private Link setup
  7. CISA KEV Catalog
  8. FIRST EPSS
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.