Overview of CVE-2026-119079: Quadratic ASN.1 Decoding Lets Unauthenticated Clients Exhaust MIT Kerberos KDC CPU

Introduction

An anonymous client that can reach a Kerberos KDC over TCP can make krb5kdc perform quadratic amounts of memory copying while it parses a request, and all of that work happens before the KDC checks who sent it. For environments where logins, service tickets and single sign-on depend on an MIT Kerberos KDC, CVE-2026-119079 turns ASN.1 decoding into a way to degrade authentication availability without any credentials.

MIT Kerberos is MIT's free source implementation of the Kerberos network authentication protocol, which began as the authentication engine for Project Athena in 1983 and was released as open source in 1987. MIT states that Kerberos is available in many commercial products, and its documentation describes support for Windows, Solaris, GNU/Linux and BSD along with Microsoft interoperability features. That makes the MIT implementation a piece of shared infrastructure for many enterprise identity deployments, although the cited sources do not quantify its installed base.

Red Hat, acting as CNA, scores the issue CVSS 3.1 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and rates it Important. The impact is availability only. No confidentiality or integrity impact is documented. An upstream fix has been committed, but as of November 9, 2026 Red Hat lists its supported krb5 packages as affected with no errata issued. Active exploitation and threat actor attribution are not established in the available reporting. Discovery is credited to AISLE Research working with Red Hat.

Technical information

Root cause: one realloc() per element

decode_sequence_of() in lib/krb5/asn.1/asn1_encode.c is the generic decoder for every ASN.1 SEQUENCE OF type in libkrb5. In vulnerable versions (MIT krb5 1.11 and later), it grows its output array by exactly one slot for each element it decodes. The Red Hat Bugzilla report quotes the vulnerable loop:

/* src/lib/krb5/asn.1/asn1_encode.c */
while (len > 0) {
...
newseq = realloc(seq, (count + 1) * elemtype->size);
if (newseq == NULL) {
ret = ENOMEM;
goto error;
}
seq = newseq;
...
ret = decode_atype(&t, contents, clen, elemtype, elem);
...
count++;
}

When realloc() cannot grow a block in place, it allocates a new block and copies the old contents. Decoding n elements can therefore copy roughly 1+2+...+n element sizes, which is O(n^2) work. Each element can be tiny on the wire, so the attacker pays very little per element while the server pays an ever-growing copy cost.

Why it is reachable without credentials

The KDC calls decode_krb5_as_req() or decode_krb5_tgs_req() in src/kdc/dispatch.c before any authentication or request policy checks. The assigned weakness, CWE-408: Incorrect Behavior Order: Early Amplification, captures exactly this: a legitimate but expensive operation (decoding attacker-controlled ASN.1) is performed before the requester has proven anything. The attacker needs network reachability and nothing more. No account is required.

The Bugzilla report points to the name string field of PrincipalName, a SEQUENCE OF GeneralString, as a practical trigger. Real clients send principal names with a handful of components; nothing in the decoder stops a request from carrying a very large number of them.

Bounding factors that do not fix the problem

The Bugzilla report describes two limits in the examined code:

• A KDC TCP payload limit of approximately 1,048,572 bytes per request.
• A TCP/RPC active connection cap of 45.

The report is explicit that these limits constrain the worst case but do not eliminate the repeated allocation behavior. A request near the payload limit can still hold a very large number of short principal components, and an attacker can keep sending such requests. The original Bugzilla write-up is labelled as AI generated, so treat these figures as the reporter's analysis of the examined build and check them against your own KDC version and configuration.

Attack flow

Based on the Bugzilla report and the NVD description:

1. The attacker identifies a host running krb5kdc that accepts Kerberos over TCP port 88 from a network they can reach.
2. They build a syntactically valid KRB_AS_REQ or KRB_TGS_REQ whose principal name contains a very large number of short GeneralString components, sized just under the roughly 1,048,572-byte TCP payload limit.
3. They send it over TCP. Under RFC 4120, Kerberos over TCP prefixes each message with a 4-byte length field.
4. The KDC begins decoding the request before authentication. decode_sequence_of() calls realloc() once per component, and krb5kdc CPU usage climbs during ASN.1 decoding.
5. Since each request does a bounded amount of work, the attacker repeats requests, possibly over many concurrent connections or from several clients, to keep CPU usage high. Legitimate clients see slower responses or timeouts.

The documented transport is TCP. The Bugzilla report does not rely on UDP-sized requests, the cited sources do not establish an equivalent UDP path, and the report does not claim the same unauthenticated reach against other daemons.

Severity assessments

• Red Hat CNA score (displayed by NVD): 7.5 High, CVSS 3.1, availability impact High. NVD has not yet provided its own assessment.
• Red Hat product severity: Important.
• Original Bugzilla report: 5.3 Medium, CVSS 3.1, with availability impact Low.

The sources do not explain how this discrepancy was reconciled, so we report both.

Patch information

Upstream fix

The fix is MIT krb5 commit 782e5ac4fb1496a79de0b87e1fc485f897e97d6d, titled "Avoid repeated reallocation when decoding ASN.1", written by Greg Hudson and committed on November 5, 2026. The commit message names CVE-2026-119079 directly. It changes a single file, src/lib/krb5/asn.1/asn1_encode.c (20 lines added, 18 removed), and carries ticket: 9266 and tags: pullup metadata with a target version of the next 1.22 maintenance release, meaning it is marked for backport to the 1.22 branch. We could not confirm that any tagged krb5 release includes it yet.

How the patch works

Instead of growing the array as it goes, the decoder now reads the sequence twice:

1. Count and validate. A first loop walks the encoding using only get_tag() (which reads each element's header) and check_atype_tag(). It counts elements and rejects a bad tag with ASN1_BAD_ID before allocating any memory. Nothing is decoded in this pass, so its cost is proportional to the input size.
2. Allocate once. A single k5calloc(count, elemtype->size, &ret) call sizes the array exactly and zeroes it, so the old per-element memset() is no longer needed.
3. Decode in place. A second loop runs over the known count and decodes each element into its slot with decode_atype().

The cleanup path also changed. The error label now frees n elements, the number the second loop actually reached, rather than count, which now holds the total from the first pass.

-    while (len > 0) {
+
+    /* Count the elements in the sequence and check their tags. */
+    for (p = asn1, l = len, count = 0; l > 0; count++) {
+        ret = get_tag(p, l, &t, &contents, &clen, &p, &l);
+        if (ret)
+            return ret;
+        if (!check_atype_tag(elemtype, &t))
+            return ASN1_BAD_ID;
+    }
+
+    seq = k5calloc(count, elemtype->size, &ret);
+    if (seq == NULL)
+        return ret;
+
+    for (n = 0; n < count; n++) {
         ret = get_tag(asn1, len, &t, &contents, &clen, &asn1, &len);
 ...
-        newseq = realloc(seq, (count + 1) * elemtype->size);
 ...
-        elem = (char *)seq + count * elemtype->size;
-        memset(elem, 0, elemtype->size);
+        elem = (char *)seq + n * elemtype->size;
         ret = decode_atype(&t, contents, clen, elemtype, elem);
 ...
 error:
-    free_sequence_of(elemtype, seq, count);
+    free_sequence_of(elemtype, seq, n);

Decoding a sequence now costs time proportional to its length with exactly one allocation, regardless of how many elements an attacker packs in. Because the change is in the shared decoder, it covers every SEQUENCE OF field in the library, not only principal names, and it protects both the KDC and application servers that decode the same structures.

Alternative proposal (not adopted)

The original Red Hat Bugzilla report (2479231) included a different patch: start at 8 slots, double capacity whenever the buffer fills, check for overflow with ASN1_OVERFLOW, and optionally shrink the buffer once at the end. That would also have removed the quadratic behavior, with amortized O(n) cost. The Bugzilla entry describes this proposal as AI generated, and upstream chose the count-then-allocate approach instead.

Downstream status

As of November 9, 2026, Red Hat lists krb5 in RHEL 7, 8, 9 and 10 and in Red Hat Hardened Images as Affected, with no errata issued. A RHEL 10.3 tracker (issue 189015) and a Fedora tracker bug (2569219) exist. Until vendor packages ship, rebuilding with the upstream commit applied is the code-level fix.

Watch for one counterexample. Red Hat erratum RHSA 2026:16799 is a krb5 security update, but it addresses CVE-2026-40356 and CVE-2026-40355, not CVE-2026-119079. Installing it does not resolve this issue.

Interim containment

• Restrict TCP port 88. Red Hat recommends limiting inbound TCP 88 on KDCs to trusted internal networks or authorized administrative hosts using firewalld, and notes that KDCs restricted to trusted subnets carry lower operational risk. The tradeoffs are documented. Clients outside the permitted networks cannot fall back to TCP for large Kerberos ticket exchanges, and reloading firewalld may briefly disrupt traffic.
• Rate limit or filter large repeated requests. The Bugzilla report suggests network-level rate limiting or filtering of repeated large Kerberos TCP requests. No validated thresholds or configurations are supplied, so tune to your own traffic.

Both measures reduce exposure to the unauthenticated parsing path, but neither removes the vulnerable code.

Detection methods

No public Sigma, YARA, Snort/Suricata or EDR rules exist yet for CVE-2026-119079, and no fixed indicators of compromise (IPs, hashes, domains) have been published. The flaw leaves no payload or files behind. It only consumes CPU. Detection therefore has three parts: find exposed KDCs, spot the unusual traffic, and correlate that traffic with CPU impact on the server.

1. Source-level signature

If you audit products that bundle their own copy of MIT krb5, look for the one-at-a-time (count + 1) growth pattern with realloc() inside decode_sequence_of(), as shown in the vulnerable loop above. Code carrying the upstream fix instead counts elements first and performs a single k5calloc().

2. Exposure inventory

Only hosts running krb5kdc and accepting Kerberos over TCP are in scope for the documented attack. A practical sequence:

1. List every host with the krb5 package installed (Red Hat lists RHEL 7, 8, 9, 10 and Red Hat Hardened Images as affected).
2. Narrow that list to hosts where krb5kdc listens on 88/TCP.
3. Test whether 88/TCP is reachable from outside your trusted networks.

Red Hat publishes a machine-readable VEX document for scanners. Since no errata had been released for any listed product at the time of writing, treat every installed version as affected.

3. Network signals on TCP/88

• Size outliers. Legitimate KRB_AS_REQ and KRB_TGS_REQ messages are normally far smaller than 1 MiB. Repeated requests near the roughly 1,048,572-byte limit are a strong anomaly. Because Kerberos over TCP prefixes each message with a 4-byte length field (RFC 4120), a sensor can read the claimed size without fully parsing the ASN.1.
• Repetition and concurrency. With per-request work bounded and a reported cap of 45 active TCP/RPC connections, an attacker must keep sending, possibly from several clients. Look for one source, or a small group, holding many simultaneous TCP/88 sessions, each carrying a large request.
• Abnormal principal structure. If your tooling decodes Kerberos, a principal name with thousands of components is not something real clients produce. Flag name string element counts far above normal.

The Bugzilla report's suggested interim control, filtering repeated large Kerberos TCP requests, doubles as a detection condition.

4. Host signals

The Bugzilla reproduction names two server-side symptoms: high CPU usage in krb5kdc during ASN.1 decoding, before authentication finishes, and slower responses to legitimate requests. Alert on sustained krb5kdc CPU above baseline and on rising authentication latency or client timeouts, then check whether inbound TCP/88 volume, especially large request volume, spiked at the same time. Failed authentication logs are not a reliable signal here, because the CPU is consumed during decoding whether or not the request would later be rejected.

5. Lab confirmation

To confirm that a build or a CPU event matches this bug, the Bugzilla report suggests instrumenting decode_sequence_of() and checking that the number of realloc() calls rises with the number of elements in the sequence. With the upstream commit applied, the decoder performs one allocation per sequence, so that per-element growth should disappear.

Caveat: these behavioral signals do not prove an attack. A busy KDC can hit high CPU for ordinary reasons, so tune thresholds to your environment and correlate network and host signals before escalating.

Affected systems and versions

• MIT Kerberos 5 (krb5): version 1.11 and later, per the CVE description. The upstream fix (commit 782e5ac4fb1496a79de0b87e1fc485f897e97d6d, November 5, 2026) is marked for backport to the 1.22 maintenance branch. No tagged release containing it is confirmed.
• Red Hat Enterprise Linux 7, 8, 9 and 10: Affected, no errata issued as of November 9, 2026.
• Red Hat Hardened Images: Affected.
• Red Hat Enterprise Linux 6: listed by Red Hat as out of support scope. The CVE record shows its status as unknown, which should not be read as confirmed unaffected.
• Documented reproduction configuration: krb5 1.21.3, release 8.el10_0, on RHEL 10 with a reachable KDC TCP listener.

Vulnerable configuration: krb5kdc accepting Kerberos over TCP port 88, with the highest risk where that port is reachable from untrusted networks. The documented attack is TCP only, and a UDP path is not established. The cited sources do not establish the status of other distributions or other Kerberos implementations, and protocol compatibility alone does not imply that a product shares this code.

Vendor security history

This is not the first time MIT's ASN.1 decoder has been the source of a security advisory:

• 2004 (MITKRB5 SA 2004 003): an ASN.1 decoder infinite loop allowed an unauthenticated remote attacker to hang a KDC or application server. MIT identified affected releases, supplied patches, and stated that release 1.3.5 would contain the fixes.
• 2009 (MITKRB5 SA 2009 002): an ASN.1 decoder freed an uninitialized pointer, with potential crashes and possible arbitrary code execution. MIT identified fixes in 1.7 and 1.6.4 and provided a patch along with a signed patch resource.

The consequences of those older bugs should not be transferred to CVE-2026-119079, whose documented impact is CPU denial of service. Taken together, they show a recurring class of decoder risk alongside an established disclosure and patching process. MIT's security contact is [email protected], with PGP-encrypted reports requested. For operators, the practical lesson in this case is to track upstream fixes and downstream package availability separately. The upstream commit exists, but distribution packages have not yet shipped.

References

• NVD: CVE-2026-119079
• CVE Record: CVE-2026-119079
• Red Hat Customer Portal: CVE-2026-119079
• Red Hat Bugzilla 2479231: MIT krb5 KDC unauthenticated CPU DoS via quadratic ASN.1 SEQUENCE OF decoding
• MIT krb5 commit 782e5ac: Avoid repeated reallocation when decoding ASN.1
• GitHub API: commit 782e5ac metadata
• CWE 408: Incorrect Behavior Order: Early Amplification
• VulDB: CVE-2026-119079
• Red Hat erratum RHSA 2026:16799 (unrelated krb5 update)
• MIT Kerberos Security Advisories
• MIT advisory 2004 003: ASN.1 decoder infinite loop
• MIT advisory 2009 002: ASN.1 decoder frees uninitialized pointer
• Kerberos: The Network Authentication Protocol (MIT)
• MIT Kerberos Consortium: Software
• MIT Kerberos Documentation: Resources
• MIT Kerberos Documentation: MIT Kerberos features
• Kerberos 5 Release 1.18.5
• CISA Known Exploited Vulnerabilities Catalog
• CISA KEV JSON feed