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.
5 steps from start to impact.
Establish an authenticated local session on the AD FS server
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.- 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
- 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
Enumerate the over-permissive object
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.- Local session established
- AD FS PowerShell module or direct filesystem/registry access
- 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
CN=ADFS,CN=Microsoft,CN=Program Data) is rarely enabled by default — turn it onExtract token-signing / token-decrypting key material
Export-AADIntADFSSigningCertificate playbook to reconstruct the signing cert offline. This is the same primitive used in the Golden SAML attack chain (Solorigate/UNC2452).- Read access to DKM contents (delivered by step 2)
- AADInternals or ADFSDump on the attacker's tooling host
- 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
Forge SAML/OIDC tokens for arbitrary users into arbitrary relying parties
New-AADIntSAMLToken, shimit, SolarFlare. Tokens are signed by the trusted IdP, so relying parties accept them unconditionally.- Token-signing private key extracted
- Knowledge of relying-party audience URIs (public metadata)
- Conditional Access with device compliance + phishing-resistant MFA claims can reduce (not eliminate) the blast radius
- Some RPs check
AuthnContextClassReffor FIDO2 — forged tokens can lie about this too
AADSignInLogs with AuthenticationDetails.authenticationMethod = Federated for users who normally use cloud auth; Microsoft Sentinel's Golden SAML analyticPersist across password resets and cloud tenant boundaries
- Signing key retained offline
- 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
The supporting signals.
| In-the-wild exploitation | None 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-concept | No public PoC yet. Expect AADInternals (Nestori Syynimaa) to fold in a wrapper within 2-4 weeks; Mandiant ADFSDump already covers the downstream extraction primitive. |
| EPSS | Not yet scored (advisory <72h old). Historical AD FS local-EoP class averages EPSS 0.15-0.30 in the first 30 days. |
| KEV status | Not listed. Class of bug (local EoP on Tier 0) is a strong KEV candidate if exploitation is observed. |
| CVSS vector | CVSS: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 versions | AD 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 versions | Microsoft 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 data | AD 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 date | 2026-07-14 — Microsoft July Patch Tuesday. |
| Reporter | Credited to Microsoft Security Response Center internal research (no external researcher named in advisory). |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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. - 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.
- 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.
- 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.
- 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
ADFSPowerShell cmdlets run by a valid local session; you need directory-service and DKM auditing to catch this
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.
#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
}
If you remember one thing.
Sources
- MSRC advisory CVE-2026-56155
- CWE-1220: Insufficient Granularity of Access Control
- Microsoft — Securing AD FS servers (Tier 0 guidance)
- Mandiant — Remediation and Hardening Strategies for Microsoft 365 to Defend Against Golden SAML
- AADInternals — Nestori Syynimaa
- Mandiant ADFSDump (GitHub)
- CISA KEV catalog
- FIRST EPSS
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.