AD FS Zero-Day CVE-2026-56155: When 7.8 Buys a Golden SAML

On 14 July 2026 Microsoft shipped a fix for CVE-2026-56155, an elevation-of-privilege flaw in Active Directory Federation Services. CVSS 3.1 base score 7.8. Attack vector: local. Microsoft's severity rating: Important. Scope: Unchanged. On the same day CISA added it to the Known Exploited Vulnerabilities catalog with a remediation due date of 28 July, because it is already being used in attacks. Every number in that first paragraph argues for putting this in the next maintenance window. Every one of them is measuring the wrong thing. An AD FS server is not a server that happens to hold a private key. It is a private key that happens to run on a server, and "local privilege escalation" on that box is the only sentence in the exploit chain that matters.

What CVE-2026-56155 actually is

The technical description is terse. Per NVD, the flaw is CWE-1220 — insufficient granularity of access control — and "allows an authorized attacker to elevate privileges locally." The CVSS vector is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H: an attacker who already has low-privileged access to the machine, with no user interaction, gets full confidentiality, integrity and availability impact on it. Affected builds run from Windows Server 2012 through Windows Server 2025, plus Windows 10 1607 and 1809.

Two details in the disclosure carry more signal than the score does.

The first is the reporter. Per BleepingComputer's Patch Tuesday coverage, CVE-2026-56155 was credited to Jeremy Kingston and Scott Clark of Microsoft's Detection and Response Team. DART is the incident response unit. Bugs credited to DART are not usually found by a researcher fuzzing in a lab — they are found in someone's network, during the cleanup, which is consistent with CISA listing it as exploited on day zero. Microsoft published no exploitation methodology.

The second is what Rapid7's analysis points out: AV:L means an attacker "would need an existing toehold on the target system to chain together with the elevation of privilege opportunity." That is a real precondition and it is why the base score is 7.8 rather than 9.8. It is also the precondition that every phishing campaign, every stolen VPN credential, and every one of the other 620-odd CVEs Microsoft patched this month exists to satisfy. Treating a prerequisite as a mitigation is how organisations end up ranking this behind a noisier 9.8 on a box nobody federates against.

Why local privilege escalation on AD FS is not a local problem

AD FS is a SAML identity provider. Its job is to assert, cryptographically, that a user is who they claim to be, to every application that federates against it — Microsoft 365, AWS, Salesforce, vSphere, whatever the estate trusts. The assertion is signed with the AD FS token-signing certificate. The relying parties do not verify the user. They verify the signature.

Administrative control of the AD FS server exposes that signing key. And a signing key in the wrong hands has a name, a proof-of-concept tool, and nine years of history.

CyberArk Labs published the Golden SAML technique on 21 November 2017, releasing the shimit PoC alongside it. The requirements are minimal: the token-signing private key is the only mandatory ingredient. With it, an attacker mints SAML assertions for any user, with any privileges, against any service that uses SAML 2.0 for SSO — including users that do not exist. CyberArk's two findings that should reframe this CVE for anyone triaging it:

• The technique works even when 2FA is enabled, because the forged assertion is the output of the authentication process. There is nothing left to challenge. The token says the MFA already happened.
• Changing a user's password does not affect the generated SAML. The forgery is at the federation layer, not the credential layer.

And the persistence property: the token-signing private key "is not renewed automatically." A key stolen today is good until someone deliberately replaces it.

So walk the chain backwards. Scope: Unchanged, says the vector — the compromised component and the impacted component are the same. But the impacted component is the trust anchor for every federated application in the estate. The CVSS scope metric is technically correct and practically inverted. The score describes a Windows box. The blast radius is the identity fabric.

The precedent is not hypothetical

This is the SolarWinds playbook. In the 2020 intrusions attributed by the U.S. government to Russia's SVR — the actor tracked variously as APT29, NOBELIUM and Midnight Blizzard — the operators pivoted from on-premises footholds to the cloud by stealing token-signing certificates from AD FS and forging tokens for privileged users. CISA documented the detection problem in advisory AA21-008A, Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments, a companion to the main SolarWinds alert.

The reason that advisory had to exist is the part worth internalising:

The forged token is not a forgery in any sense the relying party can test. It is a well-formed, correctly-signed assertion from the identity provider the application was configured to trust. The application is not fooled. The application is correct. The trust it was told to extend has simply been handed to someone else.

The operators worked inside Microsoft 365 without leaving on-premises authentication traces, because the authentication never happened on-premises. That is the shape of what CVE-2026-56155 puts within reach of anyone who already has a low-privileged foothold on a federation server.

What the patch does not fix

Apply the July update and the escalation path closes. Nothing else does.

If the key left the building before you patched, you have patched a door that the attacker no longer needs. The forged tokens keep validating, because the certificate that signs them is still the certificate your relying parties trust. This is the same property that makes stolen-credential and planted-webshell cleanups fail: the vulnerability and the persistence are two different objects, and only one of them is addressed by a patch.

CISA appears to be making that point with unusual bluntness. The KEV entry's required action cites BOD 26-04 and the Forensics Triage Requirements — standard. But the notes field also links Microsoft's AD FS decommission guide. A KEV entry whose reference material includes instructions for removing the product is not subtle. Microsoft's own guidance has for years pushed federation customers toward Entra ID with password hash sync or certificate-based authentication; the decommission guide's final steps tell you to re-image the AD FS servers with full disk formatting and purge the CertificateSharingContainer DN. Those steps exist because of what the box holds.

The detection problem: a login with no authentication

Here is the asymmetry that makes Golden SAML worth an article rather than a patch ticket. A forged token produces a successful application login with no corresponding authentication event on the identity provider — because the identity provider was never involved.

Hunters' AD FS threat-hunting research makes this the primary signal: a login recorded in the relying party's logs with no matching AD FS event 1200 (which represents an actual authentication against AD FS) means the token was likely forged. You are not hunting for a bad event. You are hunting for a missing one, and only by correlating two log sources that most organisations never join.

Layer	What a real sign-in looks like	What a forged sign-in looks like
AD FS server (event 1200)	Token issued, user authenticated	Nothing. No record at all.
Relying party / cloud app	Successful federated sign-in	Successful federated sign-in — identical
MFA system	Challenge issued and satisfied	No challenge; token asserts MFA already occurred
Signature validation	Valid	Valid — same key, genuinely correct
Network	Session from expected client population	Session from wherever the attacker is

Four of the five rows are either identical or structurally blind. The identity layer cannot tell you the difference, by design — it is doing exactly what it was built to do. The last row is where the difference lives.

Remediation

Treat this as two separate jobs: close the escalation path, then determine whether the key is already gone. The second job is the one that decides whether you are done.

1. Am I affected?

You are in scope if you run the AD FS role on any supported Windows Server build (2012 through 2025). Check whether the role is present and whether the July update is on:

# Is this box a federation server?
Get-WindowsFeature ADFS-Federation | Where-Object Installed

# Confirm the July 14, 2026 cumulative update is installed
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOn

# Enumerate relying parties — this is your blast radius, inventory it now
Get-AdfsRelyingPartyTrust | Select-Object Name, Identifier, Enabled

Note the third command. Before you decide how urgent this is, enumerate what trusts the box. That list is the actual severity.

2. Patch — exact fixed versions

Install the 14 July 2026 cumulative update for your Windows Server build. CVE-2026-56155 is fixed in the bundled Windows and Windows Server updates released that day, covering Server 2012, 2012 R2, 2016, 2019, 2022 and 2025 including Server Core, plus Windows 10 1607 and 1809. Take the KB number for your specific build from Microsoft's Security Update Guide entry for CVE-2026-56155 rather than from any third-party summary — the KB differs per build and a wrong number means an unpatched server that reports as done. CISA's KEV due date for federal agencies is 28 July 2026.

3. Can't patch now? Compensating controls

• Treat AD FS servers as Tier 0. They are domain-controller-equivalent, because owning one produces the same outcome. Administrative access only from privileged access workstations; no general-purpose logins; no browsing; no email.
• Cut the toehold. AV:L is the whole precondition. Remove local admin, remove interactive login rights, remove every service that does not need to be on a federation server.
• Never expose the AD FS server directly. Proxy access through WAP; the federation server itself has no business taking traffic from the internet.
• Set an alert on the relying-party trust list. A new relying party you did not create is an attacker federating their own application against your identity provider.

4. Hunt for compromise

Assume the toehold existed. Map to MITRE ATT&CK:

• T1552.004 / T1649 — steal or forge authentication certificates. The core objective. Look for unexpected LDAP queries to domain controllers from unknown process contexts on the AD FS server: that is the signature of DKM extraction via tooling like ADFSDump, per Hunters' research.
• T1078 — valid accounts. Non-service logon types against the AD FS service account. That account should only ever perform logon type 5 (service) in event 4624. A type 10 (RDP) login to the AD FS service account is a finding, not a curiosity.
• T1606.002 — forge web credentials: SAML tokens. The Golden SAML technique itself. The query that matters: relying-party and cloud sign-in events with no matching AD FS event 1200. If you have never joined those two log sources, you have never been able to detect this.
• T1068 — exploitation for privilege escalation. The CVE itself. Local privilege changes on the federation server around the exploitation window.
• T1550.001 — application access tokens. Sign-ins to federated apps from ASNs, geographies or client populations that have never appeared before, for accounts that show no on-premises authentication.

Pull the AD FS event logs and cloud sign-in logs for the full window back to the date your foothold could plausibly have been established — not just since Patch Tuesday.

5. Eradicate and verify

If you find evidence the key was accessible to an attacker, patching is step one of five:

1. Rotate the token-signing certificate — then rotate it again. The standard Golden SAML remediation is a double rotation, because AD FS publishes a secondary certificate for rollover and a single rotation can leave a key the attacker still holds inside the valid set. Rotate, allow relying parties to pick up the new metadata, then rotate a second time so anyone holding an old certificate is locked out. Confirm every relying party has consumed the new metadata — one that hasn't is both an outage and a hole.
2. Re-image the server. Microsoft's own decommission guidance calls for full disk formatting, and for good reason: you cannot prove a box that held a stolen private key is clean.
3. Audit relying-party trusts and claim rules for anything added or modified. A malicious claim rule can grant an attacker-chosen identity elevated roles without any token forgery at all.
4. Rotate credentials the AD FS box could reach, including the service account and the DKM key material.
5. Verify after patching, not before. A rogue relying party, a modified claim rule and a copied certificate all survive the update.

If your estate can retire federation entirely, this CVE is a reasonable forcing function — which is, apparently, CISA's read too.

Where Zero Hunt fits

The article's operational question is not "is it patched." It is: did the key leave, and can you prove it? The identity layer cannot answer, because a forged token is indistinguishable from a real one at every layer that checks signatures. Four of five rows in the table above are blind by design. The row that isn't is the network.

That is what Zero Hunt's AI Traffic Analysis is built for. A proprietary deep-learning model trained on billions of PCAP sequences runs on the appliance GPU with four parallel inference heads — suspicious traffic, malware classification, attack type identification, application fingerprinting — at a 2.7+ Gbit/s baseline, entirely on-prem. It does not ask AD FS whether it issued a token, because AD FS does not know. It watches what the token does: federated sessions appearing from ASNs and client fingerprints that have never appeared in the baseline, for accounts with no corresponding authentication traffic to the federation server; the LDAP queries from an unexpected process context that precede DKM extraction; the assertion replayed into a relying party while it happens, not in the next morning's SIEM digest. The forged token is cryptographically perfect. The traffic carrying it is not the traffic your estate normally produces, and that discrepancy exists on the wire regardless of how correct the signature is.

The complementary half is validating the precondition. AV:L is doing enormous work in that 7.8, and the honest answer to "does an attacker have a toehold that reaches local admin on our federation server" is not available from a CVSS vector or a patch report — it is an empirical question about your environment. Zero Hunt's 10-agent swarm (Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, under an AI Controller) writes per-target exploit code with a local LLM rather than pulling a PoC, runs it in ephemeral Docker with optional gVisor hardening, and backtests every skill through the AI Gym before it touches production. Pointed at a federation server under an assumed-breach premise, the Post-Exploit and Pivot agents answer the question the score can't: from the foothold that actually exists in your estate, does the path to the token-signing key actually close — and every finding is ECDSA-signed with chain-of-custody, mapped across the 32 compliance frameworks, so "we verified the key was not reachable after patching" is an artefact you can hand an auditor rather than an assertion you make.

Patching CVE-2026-56155 takes an afternoon. Knowing whether it mattered takes evidence.