The 'local' AD FS bug that forges your cloud logins: CVE-2026-56155, exploited in the wild

Microsoft's record-breaking July 2026 Patch Tuesday — roughly 570 CVEs — carried three zero-days, and the one worth your morning is a bug in AD FS, the on-prem service that signs the SAML and JWT tokens every federated app trusts. Its CVSS vector begins AV:L — local access required — so a base-score-only triage files it under soon. But Microsoft flags it exploited in the wild, CISA added it to the Known Exploited Vulnerabilities catalog the same day, and Microsoft credits the find to its own incident-response team. When the people who fix breaches for a living discover a bug inside a breach, the "local" label stops being reassuring.

What the flaw actually is

AD FS protects the private keys of its token-signing and token-encryption certificates with a symmetric master key managed by the Distributed Key Manager (DKM). That master key doesn't sit on disk — it lives inside Active Directory, tucked in the thumbnailPhoto attribute of a contact object under CN=ADFS,CN=Microsoft,CN=Program Data. Anyone who can read that attribute can rebuild the key and decrypt the signing certificate offline. The vulnerability, classified CWE-1220 (Insufficient Granularity of Access Control), is exactly the failure that makes that read possible: Microsoft's servicing guidance (KB5121391 — "AD FS DKM container ACL hardening") says the DKM container historically shipped with overly-permissive ACLs, so principals that had no business reading the key could reach it.

Why a 'local' 7.8 is an identity emergency

The vector — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — reads as contained: local access, low privileges, unchanged scope. Three things invert that reading. First, the asset is a trust anchor: AD FS signs the tokens that Microsoft 365, Entra ID, and every wired-up SaaS accept, so stealing the signing key means minting a valid identity for any user — the classic Golden SAML technique (MITRE T1606.002), MFA bypassed. Second, AV:L is cheap to satisfy mid-intrusion: an attacker with any foothold on the AD FS server context clears the bar, which is why analysts note it "can be paired with an RCE, as we often see in ransomware." Third, CVSS's Scope:Unchanged scores the AD FS host, not the cloud tenants the forged tokens unlock — the base number simply can't see the blast radius.

The exploitation chain

The path runs from a foothold to durable, tenant-wide identity forgery — and, crucially, it doesn't end when you patch. Because the flaw grants a read of long-lived key material, anyone who read the DKM key before you closed the ACL still holds a working forging key until you rotate the token-signing certificates. The diagram traces the chain and marks the three cheapest places to break it: prevent the read (harden the ACL), detect the theft (audit the key access), and evict the attacker (rotate the certs).

Am I affected?

This is an AD FS bug. If you don't run the AD FS role anywhere in the domain, you're not exposed — confirm with Get-WindowsFeature ADFS-Federation across your servers. If you do run AD FS, every supported Windows Server SKU that hosts the role is in scope until it's patched and the DKM ACL is remediated. Note the two-stage nature of the fix: installing the July update only turns on an audit; it does not fix the ACL by itself.

Exploited in the wild — with a decade of precedent

AD FS token-signing-key theft isn't a novel idea; it's a proven nation-state play. In the 2020 Solorigate intrusions, the actor Microsoft tracks as NOBELIUM extracted AD FS signing certificates and forged SAML tokens — Golden SAML — later aided by the FoggyWeb implant. What this 2026 bug changes is the bar: it hands attackers a low-privilege, local path to the very same key material that used to require domain-admin-level access. Microsoft flags exploitation as Detected and credits discovery to two engineers on its Detection and Response Team (DART) — the unit that investigates live breaches. Honest limits worth stating: Microsoft published no exploitation mechanics, no IOCs, no victimology, and no attribution, and there is no public proof-of-concept. That's a reason to move, not to wait.

Detection & hunting

A local ACL read leaves little trace, so hunting targets the theft it enables and the Golden SAML abuse that follows, not the vulnerability itself. There is no network signature and no CVE-specific PoC to match. Three telemetry sources carry most of the value:

• The crown-jewel read: Security Event 4662 (Directory Service Access) against the DKM contact object's thumbnailPhoto attribute (attribute GUID 8d3bca50-1d7e-11d0-a081-00aa006c33ed), by any principal other than the AD FS service account. This needs a SACL auditing ReadProperty on the DKM container — deploy it if it's absent.
• Service-account misuse: the AD FS service account should only ever produce Event 4624 with LogonType 5 (service). An interactive, network, batch, or RDP logon by that account is a strong hands-on-keyboard signal after an EoP yields the service identity; correlate with Event 4672.
• Golden SAML follow-on: a successful sign-in in a cloud / relying-party log with no matching AD FS token-issuance Event 1200 means the token was forged offline — a high-fidelity indicator. Watch Event 1102 (audit log cleared) on AD FS hosts as anti-forensics.
• Standing config check: AD FS/Admin Event 1132 (from the July update) means the DKM ACL is still insecure — any host emitting 1132 without a later 1135 is vulnerable right now.

What to do now

1. Inventory every AD FS farm node and confirm the July 14, 2026 (or later) cumulative update is installed — remember, patching only enables audit mode.
2. Read the audit result in the AD FS/Admin log. Nodes showing Event 1132 (ACL not secure) need remediation; 1133 / 1135 are already secure.
3. Remediate by setting HKLM\SOFTWARE\Microsoft\ADFS\RemediateDkmAcl = 1 (DWORD) and restarting adfssrv; confirm Event 1135. Don't wait for the October auto-enforcement — it's past the KEV deadline.
4. Assume the key may be stolen. Since this was exploited as a zero-day, if any node reported 1132 before you patched, rotate the AD FS token-signing and token-encryption certificates twice and re-establish relying-party trusts.
5. Hunt for the DKM key read and Golden SAML follow-on (above), and verify remediation farm-wide before 2026-07-28.

FAQ

Sources

• Microsoft MSRC — CVE-2026-56155 advisory
• NVD — CVE-2026-56155
• Microsoft — KB5121391: AD FS DKM container ACL hardening
• CISA — Known Exploited Vulnerabilities catalog
• CISA — BOD 26-04: Prioritizing Security Updates Based on Risk
• Zero Day Initiative — The July 2026 Security Update Review
• Tenable — Microsoft's July 2026 Patch Tuesday
• BleepingComputer — Microsoft July 2026 Patch Tuesday fixes 3 zero-days
• The Hacker News — Microsoft patches record flaws in July 2026
• Rapid7 — Patch Tuesday, July 2026
• Hunters — AD FS Threat Hunting, Part 2: Golden SAML
• CyberArk — Golden SAML Revisited: The Solorigate Connection
• The DFIR / ThreatHunter-Playbook — AD FS DKM keys