Krb5: mit krb5 kadmind unauthenticated memory leak dos via gss-rpc auth flavor switching
Affects MIT Kerberos 5 (krb5) 1.4 and later where kadmind uses the GSS-RPC transport over persistent TCP connections; no fixed version is listed in the checked facts.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: Restrict network access to kadmind to trusted hosts, or disable it in favor of kadmin.local server-side command line tool for administration operations if possible.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 40/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The MIT Kerberos 5 kadmind administration service has a flaw in its GSS-RPC transport layer that lets a remote attacker cause a denial of service by exhausting server memory. The attacker can do this over the network without logging in, by repeatedly switching authentication flavors on the same TCP connection and abandoning the GSS contexts each time.
Read the original description
The GSS-RPC transport layer in MIT Kerberos 5 (aka krb5) 1.4 and later does not release the previous authentication context when a client switches from an RPCSEC_GSS or AUTH_GSSAPI flavor to a non-GSS flavor on the same TCP connection. This allows remote attackers to cause a denial of service (memory exhaustion in kadmind) by repeatedly establishing and abandoning GSS authentication contexts.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure17/25No login or user action needed, reachable over the network without a login · Unknown: Advisories don't say whether default setups are affected
- Reach10/20Shipped in major Linux distributions
- Severity7.5/10CVSS 7.5
- No patch5/5No patch listed yet
What would change the score
- Would score about 85 if added to CISA KEV
- Would score about 80 if CISA's SSVC rates exploitation active
- Would score about 45 if advisories confirm default setups are exposed
What to do
Workaround: Restrict network access to kadmind to trusted hosts, or disable it in favor of kadmin.local server-side command line tool for administration operations if possible.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- krb5
Version range not reported
- krb5
Version range not reported
- krb5
Version range not reported
- krb5
Version range not reported
- krb5
Version range not reported
- krb5
Version range not reported
Evidence 2
- Report
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-112320
Is CVE-2026-112320 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
When a client on the same persistent TCP connection switches from an RPCSEC_GSS or AUTH_GSSAPI authentication flavor to a non-GSS flavor, the previous authentication context is not released. Memory builds up in kadmind, which can exhaust memory and crash or stall the service.Source: access.redhat.com
Am I affected, and how do I check?
The GSS-RPC transport in MIT krb5 1.4 and later is affected, including kadmind over long-lived TCP connections with RPCSEC_GSS enabled. To check a system, look at the installed krb5 version and whether kadmind is running and reachable over the network.Source: access.redhat.com
How do I fix CVE-2026-112320?
The checked facts do not list a fixed version, so apply the vendor's krb5 update for your release once it is available and confirm the fix in the vendor advisory. Until then, use the workaround in the no-patch answer.Source: access.redhat.com
What if there's no patch?
Restrict network access to kadmind so only trusted hosts can reach it. If possible, disable kadmind and run administration tasks with the kadmin.local tool on the server itself.Source: access.redhat.com