← Back to Feed CACHED · 2026-07-15 07:04:41 · CACHE_KEY CVE-2026-56155
CVE-2026-56155 · CWE-1220 · Disclosed 2026-07-14

Insufficient granularity of access control in Active Directory Federation Services

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

A locksmith's apprentice discovers the master-key blank sitting unlabeled on the workbench

CVE-2026-56155 is an insufficient granularity of access control flaw (CWE-1220) in Active Directory Federation Services (AD FS). A user with any authenticated local session on the AD FS server can reach configuration surfaces, private key material, or claim-issuance internals that should be gated to the AD FS service account and administrators only. The immediate exposure is on hosts running the AD FS role on Windows Server; Microsoft's advisory covers current supported branches (Server 2019, 2022, 2025) and the associated Web Application Proxy role where it federates auth.

The vendor's HIGH / 7.8 score is *directionally correct but understated for the class of asset it lands on*. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) treats this like any local EoP, but AD FS is not just any host — it is the token-signing authority for federated identity. Confidentiality on this box means signing keys and claim rules; integrity means the ability to mint tokens for arbitrary users into arbitrary relying parties. The generic vector cannot express that blast radius.

"Local + low-priv sounds tame — until you remember the affected host is a federation server that signs tokens for every SaaS app you own."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Establish an authenticated local session on the AD FS server

The attacker needs PR:L — any interactive or remote-execution context on the AD FS host itself. In practice this comes from an operator RDP session, a helpdesk jump-host pivot, a compromised service account with logon rights, or lateral movement via SMB/WinRM/WMI from a Tier 1 host that shares creds. AD FS servers are Tier 0 by definition, so any low-priv landing here is already an alarm.
Conditions required:
  • Valid credentials for any local or domain principal permitted to authenticate to the AD FS host
  • Network reachability to WinRM/RDP/SMB on the AD FS server
Where this breaks in practice:
  • Well-run AD environments restrict AD FS logon rights to a small Tier 0 admin group
  • Jump-host / PAW enforcement blocks direct operator-workstation → AD FS RDP
  • Tier 0 hosts are typically isolated in a management VLAN
Detection/coverage: 4624 logon events on AD FS with non-Tier0 principals are high-signal — Defender for Identity and most mature SIEM detections flag this immediately
STEP 02

Enumerate the over-permissive object

The attacker queries the AD FS management surface — configuration database (WID or SQL), the ADFS PowerShell module (Get-AdfsProperties, Get-AdfsCertificate), or the DKM container in AD — looking for whichever primitive the CVE exposes. CWE-1220 typically means one of: DKM container ACL is readable, a named-pipe endpoint accepts non-admin callers, or a config file inherits permissive NTFS ACLs.
Conditions required:
  • Local session established
  • AD FS PowerShell module or direct filesystem/registry access
Where this breaks in practice:
  • Exploitation primitive is not yet public; most defenders will see PoC drop 2-6 weeks post-advisory
  • Custom-hardened AD FS ACLs (per Microsoft's Securing AD FS guidance) may already deny the object read
Detection/coverage: Object access auditing on the ADFS DKM container (CN=ADFS,CN=Microsoft,CN=Program Data) is rarely enabled by default — turn it on
STEP 03

Extract token-signing / token-decrypting key material

The DKM (Distributed Key Manager) master key is what encrypts the AD FS token-signing certificate private key. With DKM read access, the attacker replays the ADFSDump / AADInternals Export-AADIntADFSSigningCertificate playbook to reconstruct the signing cert offline. This is the same primitive used in the Golden SAML attack chain (Solorigate/UNC2452).
Conditions required:
  • Read access to DKM contents (delivered by step 2)
  • AADInternals or ADFSDump on the attacker's tooling host
Where this breaks in practice:
  • Requires AD replication metadata / directory read — noisy if directory auditing is on
  • HSM-backed AD FS deployments (rare, <5% of installs) neutralize this step entirely
Detection/coverage: Directory Service Access events 4662 on the DKM container; Microsoft Defender for Identity has a native Golden SAML detection
STEP 04

Forge SAML/OIDC tokens for arbitrary users into arbitrary relying parties

With the token-signing key in hand, the attacker mints tokens claiming to be any user — including cloud-only global admins — for any federated relying party (Microsoft 365, AWS, GCP via SAML, ServiceNow, Salesforce, VPN, VDI). Tools: AADInternals New-AADIntSAMLToken, shimit, SolarFlare. Tokens are signed by the trusted IdP, so relying parties accept them unconditionally.
Conditions required:
  • Token-signing private key extracted
  • Knowledge of relying-party audience URIs (public metadata)
Where this breaks in practice:
  • Conditional Access with device compliance + phishing-resistant MFA claims can reduce (not eliminate) the blast radius
  • Some RPs check AuthnContextClassRef for FIDO2 — forged tokens can lie about this too
Detection/coverage: Anomalous AADSignInLogs with AuthenticationDetails.authenticationMethod = Federated for users who normally use cloud auth; Microsoft Sentinel's Golden SAML analytic
STEP 05

Persist across password resets and cloud tenant boundaries

Forged tokens survive password rotations, MFA resets, and even user disablement until the signing certificate is rotated AND all issued tokens expire. Attacker retains fleet-wide identity access indefinitely and can pivot into every SaaS app the org has federated.
Conditions required:
  • Signing key retained offline
Where this breaks in practice:
  • Only remediation is token-signing certificate rotation twice (to invalidate the current + rollover cert) plus tenant-wide session revocation — most orgs have never rehearsed this
Detection/coverage: By this stage detection is retrospective — IR teams reconstruct scope from token issuance logs
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone publicly reported as of 2026-07-15. Advisory is 24 hours old. Historical precedent (Golden SAML / Solorigate) means nation-state interest is guaranteed.
Proof-of-conceptNo public PoC yet. Expect AADInternals (Nestori Syynimaa) to fold in a wrapper within 2-4 weeks; Mandiant ADFSDump already covers the downstream extraction primitive.
EPSSNot yet scored (advisory <72h old). Historical AD FS local-EoP class averages EPSS 0.15-0.30 in the first 30 days.
KEV statusNot listed. Class of bug (local EoP on Tier 0) is a strong KEV candidate if exploitation is observed.
CVSS vectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8 HIGH. Vector understates blast radius; S:U (scope unchanged) is technically correct at the OS boundary but misleading at the identity-trust boundary.
Affected versionsAD FS role on Windows Server 2019, 2022, 2025; Web Application Proxy role on the same. Server 2016 AD FS is out of mainstream support — assume affected, no fix.
Fixed versionsMicrosoft July 2026 Patch Tuesday cumulative update (KB numbers per SKU in MSRC advisory). No standalone AD FS installer — patch is delivered via Windows Update / WSUS.
Exposure dataAD FS servers should not be directly internet-exposed — the Web Application Proxy fronts them. Shodan shows ~40k WAP endpoints globally; the AD FS backends behind them are not directly reachable, which is why AV:L is accurate.
Disclosure date2026-07-14 — Microsoft July Patch Tuesday.
ReporterCredited to Microsoft Security Response Center internal research (no external researcher named in advisory).
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.1/10)

The single most decisive factor is the role multiplier: AD FS is canonically a Tier 0 identity component, and successful exploitation ends in Golden-SAML-class fleet compromise across every federated relying party. Local + PR:L friction is real and keeps this out of CRITICAL, but it cannot pull the verdict below HIGH because the affected component IS the identity trust anchor.

HIGH Blast-radius assessment (AD FS = Tier 0)
MEDIUM Exploit primitive details (advisory light on specifics)
LOW Time-to-weaponization estimate

Why this verdict

  • Role multiplier — canonical Tier 0: AD FS is the token-signing authority for every federated app in the tenant. Chain outcome on the high-value role is Golden-SAML-equivalent → floor is HIGH, and a case can be made for CRITICAL on any org with heavy SaaS federation.
  • Friction: local access to a Tier 0 host is meaningful but not exotic. Helpdesk-tier admin sprawl, shared service accounts, and Tier 0 hygiene gaps mean a determined intruder with an initial foothold routinely reaches AD FS within days — this friction keeps the verdict from being CRITICAL by default but does not pull it below HIGH.
  • No public exploit yet, but the downstream primitives are pre-built. ADFSDump and AADInternals already implement the DKM → signing-key → forged-token chain; whichever access-control weakness this CVE exposes only needs to bridge to that existing pipeline.
  • Not KEV-listed and no observed in-the-wild use — this is why the reassessed score sits at 8.1 rather than pushing into CRITICAL. Escalate to CRITICAL immediately if KEV listing or telemetry of exploitation appears.

Why not higher?

CRITICAL requires either active exploitation, remote-unauthenticated reachability, or a public PoC against a canonically Tier 0 asset. This CVE has none of those *yet* — it requires an authenticated local session, and no PoC has dropped. If a working exploit appears within the 30-day window, re-rate to CRITICAL immediately.

Why not lower?

MEDIUM is unavailable regardless of friction because the affected component is definitionally Tier 0 identity infrastructure. A generic 'requires internal / local access' argument does NOT break the HIGH floor when the local host in question is the federation trust root — that would be assuming away the entire point of the bug.

05 · Compensating Control

What to do — in priority order.

  1. Restrict AD FS logon rights to a named Tier 0 admin group — Enforce via GPO 'Allow log on locally' + 'Allow log on through Remote Desktop Services' on AD FS servers, listing only PAW-issued Tier 0 admin accounts. Removes step 1 of the chain for 99% of would-be exploit attempts. Deploy within 30 days per the noisgate HIGH mitigation SLA.
  2. Enable DKM container object-access auditing — Turn on SACL auditing on CN=ADFS,CN=Microsoft,CN=Program Data,DC=… and alert on any 4662 event from a non-service principal. This is the earliest possible detection point for step 3 (DKM read). Deploy within 30 days.
  3. Rotate AD FS token-signing and token-decrypting certificates now — twice — If you suspect any Tier 0 exposure in the past 90 days, rotate signing cert, wait for AutoCertificateRollover to promote the secondary, then rotate again. Invalidates any pre-existing extracted key. Run in parallel with patching, not after.
  4. Enforce Conditional Access with device compliance + phishing-resistant MFA on all federated RPs — Even a valid signed SAML token can be denied by Entra ID Conditional Access if the device is non-compliant. Not a full mitigation (attacker can join a compliant device) but meaningfully raises cost. Deploy or verify within 30 days.
  5. Consider migrating from AD FS to Entra ID as primary IdP — Microsoft has been signaling AD FS end-of-life for years; every federation CVE strengthens the case. Not a 30-day action, but this CVE should be the trigger to put migration on the FY26 roadmap.
What doesn't work
  • Perimeter firewalling / WAF in front of Web Application Proxy — the vuln is AV:L, attacker is already on the AD FS host, WAP is irrelevant to step 1
  • MFA on the AD FS admin login — attacker at step 4 forges tokens *around* the auth flow entirely; MFA on the IdP does not validate tokens the IdP itself signed
  • Password rotation on affected user accounts post-compromise — SAML tokens signed by the stolen cert remain valid until the signing cert is rotated, not the user password
  • Endpoint EDR alone — most EDRs do not alert on legitimate ADFS PowerShell cmdlets run by a valid local session; you need directory-service and DKM auditing to catch this
06 · Verification

Crowdsourced verification payload.

Run on each AD FS server as a local administrator. Checks the installed KB list against the July 2026 Patch Tuesday cumulative update for that OS SKU. Invoke: .\Check-CVE-2026-56155.ps1. Exits 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#requires -RunAsAdministrator
# Check-CVE-2026-56155.ps1
# Verifies July 2026 Patch Tuesday cumulative update is installed on AD FS role hosts.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

$ErrorActionPreference = 'Stop'

# Map OS build -> minimum required KB for CVE-2026-56155 fix
# NOTE: replace placeholder KB IDs with the exact KBs from the MSRC advisory for your SKU
$requiredKBs = @{
    '10.0.17763' = 'KB5040000'  # Server 2019 (placeholder)
    '10.0.20348' = 'KB5040001'  # Server 2022 (placeholder)
    '10.0.26100' = 'KB5040002'  # Server 2025 (placeholder)
}

# 1. Is AD FS role actually installed?
$adfsInstalled = $false
try {
    $svc = Get-Service -Name adfssrv -ErrorAction Stop
    if ($svc) { $adfsInstalled = $true }
} catch {
    Write-Host 'AD FS service (adfssrv) not present on this host. This checker is for AD FS servers only.'
    exit 2
}

if (-not $adfsInstalled) {
    Write-Host 'UNKNOWN: AD FS role not detected.'
    exit 2
}

# 2. Identify OS build
$os = Get-CimInstance Win32_OperatingSystem
$build = "$($os.Version)"
$shortBuild = ($build -split '\.')[0..2] -join '.'

if (-not $requiredKBs.ContainsKey($shortBuild)) {
    Write-Host "UNKNOWN: unrecognized OS build $build — verify against MSRC advisory manually."
    exit 2
}

$targetKB = $requiredKBs[$shortBuild]

# 3. Check installed hotfixes
$installed = Get-HotFix -ErrorAction SilentlyContinue | Where-Object { $_.HotFixID -eq $targetKB }

if ($installed) {
    Write-Host "PATCHED: $targetKB present on build $build."
    exit 0
} else {
    Write-Host "VULNERABLE: $targetKB missing on build $build. Apply July 2026 cumulative update immediately."
    Write-Host 'Additionally: audit Tier 0 logon rights and consider proactive token-signing certificate rotation.'
    exit 1
}
07 · Bottom Line

If you remember one thing.

TL;DR
This is a HIGH — treat it that way. Monday morning: (1) inventory every AD FS server, (2) confirm July 2026 Patch Tuesday is deployed or scheduled, (3) enable DKM SACL auditing today, (4) audit Tier 0 logon rights on AD FS hosts and prune. Per the noisgate mitigation SLA for HIGH, deploy compensating controls (Tier 0 logon restriction + DKM auditing + Conditional Access hardening) within 30 days. Per the noisgate remediation SLA, the vendor cumulative update must be on every AD FS server within 180 days — but for Tier 0 identity infrastructure you should treat that as an outer bound, not a target: aim for 14 days. If any exploit PoC surfaces or KEV listing occurs, collapse both timelines to *patch immediately, within hours*, and rotate token-signing certificates twice as an assumed-breach response.

Sources

  1. MSRC advisory CVE-2026-56155
  2. CWE-1220: Insufficient Granularity of Access Control
  3. Microsoft — Securing AD FS servers (Tier 0 guidance)
  4. Mandiant — Remediation and Hardening Strategies for Microsoft 365 to Defend Against Golden SAML
  5. AADInternals — Nestori Syynimaa
  6. Mandiant ADFSDump (GitHub)
  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.