A padlock that still ships with a key from 1991, useful only if someone still trusts it
MIT Kerberos (krb5) uses the RC4-HMAC-MD5 encryption type as a legacy option for interoperability with older Windows/AD deployments. CVE-2025-3576 is a CWE-328 (weak hash) issue: because the GSSAPI per-message integrity checksum inside the RC4-HMAC codepath relies on MD5 — a hash with practical chosen-prefix collisions since 2007 — an on-path attacker who can observe and modify GSSAPI-protected traffic can craft a colliding message that verifies as authentic. Affected: all krb5 prior to the April 2025 fix, including distro packages krb5 < 1.21.3-x where x is the vendor backport (RHEL 8/9 via RHSA-2025:8411 and follow-ups, SUSE, Ubuntu, Amazon Linux, Rocky).
The vendor MEDIUM (5.9) rating is *fair*. The bug is real cryptography rot, but the CVSS vector (AV:N/AC:H/PR:N/UI:N/C:N/I:H/A:N) already prices in the two big constraints: attack complexity is High (you need MITM and a workable MD5 collision inside the message envelope) and only Integrity is impacted — no confidentiality break, no availability, no direct credential theft. This is not Zerologon and it is not a Kerberos auth bypass in the marketing sense; it is a cryptographic downgrade window that closes the moment your realm stops offering RC4.
4 steps from start to impact.
Gain on-path position between Kerberos client and service
bettercap, mitm6, Responder (LLMNR/NBT-NS poisoning to steer traffic).- Attacker already inside the routed path
- No IPsec / QUIC / TLS wrapping the Kerberos-authed application traffic
- Modern enterprises tunnel most auth traffic over TLS or VPN
- Switch port security, DHCP snooping, and 802.1X kill trivial LAN MITM
- Zero-trust segmentation reduces attacker reach
Responder-class toolingForce or observe RC4-HMAC negotiation
arcfour-hmac / RC4-HMAC-MD5. The attacker needs the client and server to negotiate this etype rather than AES256-CTS-HMAC-SHA1-96. In current Windows Server 2025 and RHEL 9 defaults, RC4 is *disabled* on the DC side. If it is still permitted (legacy trust, an old NAS, an SAP appliance), the attacker can wait for a naturally-negotiated RC4 session or downgrade via a rogue KDC referral.- RC4-HMAC etype enabled on KDC or service principal
msDS-SupportedEncryptionTypesbit 0x4 set on the target account
- Microsoft
KrbtgtFullPacSignatureand November 2022 hardening default-disable RC4 for new deployments - STIG / CIS baselines require
AES256_CTS_HMAC_SHA1_96only
0x17 (RC4-HMAC) — Splunk/Sentinel rules existCompute a collision on the GSSAPI MIC / wrap checksum
impacket module for this specific chain as of assessment date.- GPU compute or precomputed collision infrastructure
- Predictable message structure the attacker can influence
- HMAC keying constrains freedom of the collision
- No weaponized public PoC observed
Inject the forged GSSAPI message into the session
- Live GSSAPI-authed session to piggyback on
- Application-layer signing/sealing may still catch semantic anomalies
- SMB signing + LDAP signing add a second integrity layer that isn't MD5
The supporting signals.
| In-the-wild exploitation | None observed. No CISA KEV listing, no vendor IR reports, no ransomware crew tradecraft citing CVE-2025-3576. |
|---|---|
| Public PoC | No weaponized PoC. Academic MD5 chosen-prefix collision tooling (hashclash by Marc Stevens) is the theoretical building block, but no krb5-specific exploit is published. |
| EPSS | 0.00276 (~0.3%) — bottom-decile likelihood of exploitation in the next 30 days. |
| KEV status | Not listed. CISA has not added CVE-2025-3576. |
| CVSS | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N = 5.9 MEDIUM. High attack complexity is doing most of the work here; Integrity-only impact. |
| Affected versions | MIT krb5 prior to 1.21.3 with the RC4-HMAC-MD5 fix. Distro backports: RHEL 8/9 via RHSA-2025:8411, 9418, 9430; SUSE released updates April–May 2025; Ubuntu USN followed. |
| Fixed versions | krb5 1.21.3+ upstream; on Red Hat, patched krb5-libs shipped in the RHSA series above; check rpm -q --changelog krb5-libs | grep 3576. |
| Exposure / scan data | Not remotely fingerprintable — the flaw is in etype negotiation, not a banner. Shodan/Censys cannot enumerate. Internal telemetry (event 4769 etype 0x17) is the only reliable exposure metric. |
| Disclosure | 2025-04-15 via MIT krb5 security advisory. |
| Reporter | Reported to MIT via the krb5-bugs process; credit in upstream advisory (no independent researcher lionization). |
noisgate verdict.
The chain requires an on-path adversary AND an RC4-HMAC-negotiated session AND a working MD5 collision against a keyed GSSAPI checksum — three compounding preconditions with no public weaponization. The single most decisive factor is attack-complexity: chained MITM + cryptographic forgery with no public tooling, which caps realistic risk at MEDIUM even though the affected component (Kerberos) sits in the identity plane.
Why this verdict
- Friction 1 — MITM prerequisite: attacker must already be on-path between client and service. This implies post-initial-access positioning; unauthenticated internet exploitation is not a realistic scenario.
- Friction 2 — RC4 must be negotiated: modern AD (Windows Server 2022+/2025) and RHEL 9 defaults disable RC4-HMAC. Enterprises that followed Microsoft's November 2022 hardening have already closed the door.
- Friction 3 — no weaponization: MD5 collision against a keyed HMAC-style GSSAPI checksum is a research-grade operation, not an off-the-shelf
impacketmodule. EPSS 0.276% reflects this. - Role multiplier — Kerberos KDC / krb5 library: Kerberos is canonically identity-plane. However, the impact is Integrity-only inside an existing GSSAPI session — no ticket forgery, no TGT theft, no credential compromise. The chain does NOT end in domain takeover, so the identity-role floor does not lift this above MEDIUM. Contrast with Zerologon, where the chain ended in DC secret disclosure.
- Role multiplier — application servers (NFS, LDAP, SMB, HTTP-SPNEGO): in the worst case, a forged GSSAPI message could tamper with one RPC call in a live session. Blast radius = one session, one operation. Does not clear the HIGH floor.
- Detection asymmetry: you cannot see the forgery, but you *can* see RC4 in your 4769 events. Killing RC4 kills the vuln, which makes this a hygiene problem, not a fire drill.
Why not higher?
No credential theft, no lateral movement primitive, no TGT/service-ticket forgery, no availability impact. The integrity break lives inside a session the attacker already has to be on-path for. HIGH would require either public weaponization or a chain ending in identity compromise — neither exists.
Why not lower?
It is a real cryptographic weakness in a security-critical library on identity-plane infrastructure. Environments running legacy trusts with RC4 enabled — still common in banking, healthcare, and manufacturing — face genuine (if narrow) integrity risk. LOW would understate that.
What to do — in priority order.
- Disable RC4-HMAC etype fleet-wide — Set
msDS-SupportedEncryptionTypeson user, computer, and service accounts to 0x18 (AES128 + AES256 only). On MIT KDCs, removearcfour-hmacfrompermitted_enctypes,default_tkt_enctypes, anddefault_tgs_enctypesinkrb5.conf. No noisgate mitigation SLA for MEDIUM — but do this inside the 365-day remediation window and ideally in the next scheduled AD hardening sprint. - Hunt RC4 tickets in auth logs — Query Event ID 4769 for
Ticket Encryption Type = 0x17(RC4-HMAC) across the last 90 days. Every account that still requests RC4 is a migration ticket. Target: zero RC4 4769s before you flip the default. - Patch krb5 packages on the normal cadence — Roll
krb5-libsfrom RHSA-2025:8411 (and successors) through your standard monthly patch train. No emergency window required — noisgate remediation SLA is 365 days for MEDIUM. - Enforce LDAP signing and SMB signing — These add a second, non-MD5 integrity layer on top of Kerberos GSSAPI. A forged MIC still gets caught by SMB3 AES-CMAC signing. Free defense-in-depth that also mitigates NTLM-relay class attacks.
- Segment legacy RC4-required systems — If a NAS, mainframe gateway, or SAP appliance genuinely requires RC4, isolate it on a VLAN with IPsec transport policy so on-path MITM becomes physically implausible.
- Perimeter firewall rules — Kerberos MITM happens inside your L2/L3 fabric, not at the internet edge.
- MFA on user accounts — MFA gates initial auth; this attack lives inside an already-authenticated GSSAPI session.
- EDR on the KDC alone — the forgery happens on the wire between endpoints, not as code execution on the KDC.
- TLS termination at a load balancer — if Kerberos-authed traffic is decrypted upstream, the vulnerable window opens between the LB and the backend.
Crowdsourced verification payload.
Run on any Linux host that has krb5-libs / krb5-user installed. Invoke as bash check-cve-2025-3576.sh. No root required for the package version check; add sudo only if you also want the config sanity pass. Emits VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env bash
# check-cve-2025-3576.sh — MIT Kerberos RC4-HMAC-MD5 GSSAPI forgery check
# Usage: bash check-cve-2025-3576.sh
set -u
FIXED_UPSTREAM="1.21.3"
STATUS="UNKNOWN"
REASON=""
ver_ge() { # $1 >= $2 ?
[ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -1)" = "$2" ]
}
get_ver() {
if command -v rpm >/dev/null 2>&1; then
rpm -q --qf '%{VERSION}-%{RELEASE}\n' krb5-libs 2>/dev/null | head -1
elif command -v dpkg-query >/dev/null 2>&1; then
dpkg-query -W -f='${Version}\n' libkrb5-3 2>/dev/null | head -1
else
echo ""
fi
}
VER="$(get_ver)"
if [ -z "$VER" ]; then
echo "UNKNOWN: krb5 not installed or package manager not detected"
exit 2
fi
# Distro backport check (RHEL RHSA-2025:8411+ ships fix in older upstream versions)
if command -v rpm >/dev/null 2>&1; then
if rpm -q --changelog krb5-libs 2>/dev/null | grep -qiE 'CVE-2025-3576|3576'; then
STATUS="PATCHED"
REASON="changelog references CVE-2025-3576"
fi
fi
# Upstream version check as fallback
UPSTREAM_VER="$(echo "$VER" | awk -F- '{print $1}')"
if [ "$STATUS" != "PATCHED" ]; then
if ver_ge "$UPSTREAM_VER" "$FIXED_UPSTREAM"; then
STATUS="PATCHED"
REASON="krb5 $UPSTREAM_VER >= $FIXED_UPSTREAM"
else
STATUS="VULNERABLE"
REASON="krb5 $UPSTREAM_VER < $FIXED_UPSTREAM and no backport marker"
fi
fi
# Exposure amplifier: RC4 still permitted?
RC4_ENABLED="unknown"
if [ -r /etc/krb5.conf ]; then
if grep -Eiq 'arcfour-hmac|rc4-hmac' /etc/krb5.conf; then
RC4_ENABLED="yes"
else
RC4_ENABLED="no (or default)"
fi
fi
echo "krb5 version: $VER"
echo "RC4-HMAC in krb5.conf: $RC4_ENABLED"
echo "Status: $STATUS ($REASON)"
case "$STATUS" in
PATCHED) exit 0 ;;
VULNERABLE) exit 1 ;;
*) exit 2 ;;
esac
If you remember one thing.
krb5-libs update (RHSA-2025:8411 or your distro equivalent) into your normal monthly patch cadence, and — more importantly — use this CVE as the political cover to finally kill RC4-HMAC in your realm: query Event 4769 for etype 0x17, set msDS-SupportedEncryptionTypes = 0x18 on every account that no longer needs RC4, and target zero RC4 tickets in 90 days. That single hardening step ends this vuln *and* every other RC4-adjacent attack (Kerberoasting cracks in seconds, AS-REP roasting, downgrade tradecraft) at the same time.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.