In MIT Kerberos 5 (aka krb5) before 1.22.3, there is a NULL pointer dereference if an application calls gssacceptseccontext() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, causing the process to terminate in parsenegomessage.

In MIT Kerberos 5 (aka krb5) before 1.22.3, there is an integer underflow and resultant out-of-bounds read if an application calls gssacceptseccontext() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, possibly causing the process to terminate in parsemessage.

In MIT Kerberos 5 (aka krb5) before 1.22.3, there is an integer underflow and resultant out-of-bounds read if an application calls gssacceptseccontext() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, possibly causing the process to terminate in parsemessage.

In MIT Kerberos 5 (aka krb5) before 1.22.3, there is a NULL pointer dereference if an application calls gssacceptseccontext() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, causing the process to terminate in parsenegomessage.

Hi,

just a quick note that MIT krb5 has fixed two unauthenticated network NegoEx parsing vulnerabilities.

Affected versions:

MIT krb5 1.18 and later, when an application calls gssacceptseccontext() on a system with a NegoEx mechanism registered in /etc/gss/mech

Description:

CVE-2026-40355 is a null pointer dereference in parsenegomessage(). The result of the second vectorbase() call was not checked before being dereferenced. An unauthenticated remote attacker can trigger this issue and crash the process.

CVE-2026-40356 is a read overrun of up to 52 bytes in parsemessage(). A short headerlen could cause an integer underflow while calculating the remaining message length. An unauthenticated remote attacker can trigger this issue and possibly crash the proces. Exfiltration of the bytes read appears unlikely.

MIT krb5 security confirmed the following CVSS v3.1 vectors:

CVE-2026-40355: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5

CVE-2026-40356: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 5.9

Users are recommended to apply the upstream patch or update to a version containing the fix.

Credit: Cem Onat Karagun

References: https://github.com/krb5/krb5/commit/2e75f0d9362fb979f5fc92829431a590a130929f https://cems.fun/2026/04/27/krb5-two-unauthenticated-network-vulnerabilities.html https://www.youtube.com/watch?v=zpBrriAJxCQ

An integer underflow vulnerability was found in MIT krb5 in the berval2tldata() function in plugins/kdb/ldap/libkdbldap/ldapprincipal2.c. The function performs an unsigned subtraction (bvlen - 2) without a prior bounds check. When bvlen is 0 or 1, the subtraction wraps to a large value which is then truncated to uint16t, yielding 0xFFFE (65534) or 0xFFFF (65535). The subsequent malloc succeeds and memcpy reads up to 65534 bytes from a 0-1 byte buffer, resulting in a heap out-of-bounds read.

The attack vector involves a malicious or compromised LDAP KDB backend returning a krbExtraData attribute with bvlen < 2, triggering the underflow when the KDC or kadmind reads principal data.

Upstream fix: https://github.com/krb5/krb5/commit/2a5fd83 MIT ticket: https://krbdev.mit.edu/rt/Ticket/Display.html?id=9206

An integer underflow vulnerability was found in MIT krb5 in the berval2tldata() function in plugins/kdb/ldap/libkdbldap/ldapprincipal2.c. The function performs an unsigned subtraction (bvlen - 2) without a prior bounds check. When bvlen is 0 or 1, the subtraction wraps to a large value which is then truncated to uint16t, yielding 0xFFFE (65534) or 0xFFFF (65535). The subsequent malloc succeeds and memcpy reads up to 65534 bytes from a 0-1 byte buffer, resulting in a heap out-of-bounds read.

The attack vector involves a malicious or compromised LDAP KDB backend returning a krbExtraData attribute with bvlen < 2, triggering the underflow when the KDC or kadmind reads principal data.

Upstream fix: https://github.com/krb5/krb5/commit/2a5fd83 MIT ticket: https://krbdev.mit.edu/rt/Ticket/Display.html?id=9206

Hi ,

Apologies for the Outlook formatted response. I'll keep this short. I had shared this directly with Alexandar and Raul but Alexander suggested I write something up for the list.

The issues described are at their heart real in that threat actors (and people like me) absolutely do dump memory and steal files from /tmp when abusing KRB5 trust relationships. The two questions for me are a) given AI's usage in crafting the report, is it novel or is it discussing something that has previously been discussed with vendors - it's not, see https://github.com/CiscoCXSecurity/linikatz and various other (un)related works, Linikatz itself was published in 2018 and b) if this is a vulnerability - aside the subtleties of specific KRB5 implementations, for me, this feels more like either a configurational weakness than a vulnerability per se.

As an aside, abusing ccache is specifically tracked within ATT&CK here: https://attack.mitre.org/techniques/T1558/005/

Tim

Tim Wadhwa-Brown

Security Consulting Senior Engineering Technical Leader

CX CoE Security

twadhwab () cisco com<mailto:twadhwab () cisco com>

Tel: +44 208 824 0239

Mail Stop BDLK09

9 New Square Park Bedfont Lakes TW14 8HA United Kingdom cisco.com | labs.portcullis.co.uk

From: Solar Designer <solar () openwall com> Sent: 19 February 2026 01:14 To: oss-security () lists openwall com <oss-security () lists openwall com> Cc: Raul Vega <raul.vega.dv () gmail com> Subject: [oss-security] MIT/Heimdal Kerberos credentials cache type FILE risks

Hi,

Raul Vega, CC'ed here, sent the below AI-generated message to linux-distros on Feb 5, without disclosing the use of AI, yet correctly set the public disclosure date to "2026-02-18 (14-day embargo per linux-distros policy)" (or maybe the AI assistant did). Unfortunately, there was no further correspondence (in particular, I got no reply to my reply, also included below), and Raul failed to bring this to oss-security on time on his own, so I am now doing it for him. And yes, I consider this borderline abuse of the list, which is why my tone.

My summary of Raul AI's message is that Kerberos defaultccachename FILE is relatively unsafe compared to certain other possible kinds of credentials cache supported via this setting, especially with respect to local file inclusion vulnerabilities in other software such as web apps running under the same user account. The message suggests to use KEYRING or KCM instead of FILE.

https://web.mit.edu/kerberos/krb5-1.22/doc/basic/ccachedef.html says FILE is the default. So it may be a case of unsafe default. Can the default reasonably be changed? "KCM caches work by contacting a daemon process", so will require this daemon to be running, and "KEYRING is Linux-specific, and uses the kernel keyring support". So maybe Linux packages can use KEYRING by default?

In Heimdal, this setting is called defaultccname, apparently with defaultccachename added as an alias for MIT compatibility a few years ago. I couldn't quickly find what the default for it is.

BTW, if this actually required pre-publication discussion, I'd have insisted on bringing it from linux-distros to the full distros list, since Kerberos is not Linux-specific (and predates Linux).

I'd appreciate follow-ups by those familiar with Kerberos (I'm not) and/or its packaging.

Alexander

On Thu, Feb 05, 2026 at 10:24:03AM +0100, Raul Vega wrote: [vs] ADV-2026-005: Kerberos Credential Cache Lifecycle Failure and Bearer Token Theft Vulnerability Type: Semantic Design Flaw / Credential Dumping

Affected Components: MIT/Heimdal Kerberos, Linux Core Dump Handlers, /tmp Defaults

Researcher: Raul Vega del Valle

CVSS 3.1 Base: 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

CVSS 3.1 Chain: 10.0 (Critical) (When chained with RCE/LFI)

Public Disclosure Date: 2026-02-18 (14-day embargo per linux-distros policy)

Executive Summary: The Semantic Gap The core of this vulnerability is a semantic failure in object lifecycle management. While the Kerberos protocol is syntactically secure, current Linux implementations fail to semantically bound the identity token (bearer ticket) to the process lifetime.

By weaponizing the "Crash and Trash" scenario, an attacker can transform a transient authentication secret into a persistent forensic artifact. This allows an unprivileged local attacker???or a remote attacker via an RCE/LFI chain???to bypass Kerberos protocol guarantees and achieve complete network-wide identity theft.

Technical Analysis 1. File-System Persistence Vector Most Linux distributions default to the FILE: ccache type, storing tickets in /tmp/krb5cc.

The Design Flaw: These tickets are bearer tokens. Possession of the file is equivalent to possession of the identity.

Exploitation: An LFI (Local File Inclusion) vulnerability in a web application can be used to "pull the trash" from /tmp, granting the attacker a valid TGT (Ticket Granting Ticket) with a ~10-hour TTL.

2. Memory Lifecycle Failure (Crash and Trash) When an application handling Kerberos authentication crashes, the system generates a core dump (if enabled).

The Semantic Gap: The credential remains in the heap or stack during the crash. Because many distributions do not restrict access to core dumps or leave them in unencrypted storage, these secrets become "trash" that is readily harvestable via standard string extraction.

Impact: This bridges the gap from a simple application crash (Availability) to a full authentication bypass (Confidentiality/Integrity).

The Grand Chain: The Case for CVSS 10.0 While the individual components may be rated "High," the Semantic Addressing of this flaw creates a critical chain:

Entry (RCE/LFI): Attacker gains limited execution or read access via a library flaw (e.g., Axios SSRF or Undici CRLF).

Pivot (ADV-2026-005): Attacker provokes a crash or reads /tmp to dump the Kerberos ccache.

Escalation: The stolen ticket is replayed from the attacker's machine to access internal high-value targets (LDAP, S3 via IMDSv2, etc.).

Result: Total identity takeover across the infrastructure without triggering traditional "credential theft" alerts.

Actionable Remediations for Distributions Distributions are requested to evaluate the following systemic changes to their default configurations:

Restrict corepattern: Ensure core dumps are directed to a secure, root-only directory by default.

Default to KEYRING:: Shift the default defaultccachename in /etc/krb5.conf from FILE to KEYRING or KCM (Kerberos Credential Manager) to keep tickets in unswappable, process-bound kernel memory.

Enforce fs.suiddumpable: Harden kernel parameters to prevent unprivileged dumping of sensitive processes.

Researcher: Raul Vega del Valle

PGP Fingerprint: [Your Fingerprint] On Fri, Feb 06, 2026 at 10:06:18AM +0100, Solar Designer wrote: Hello Raul,

When you bring this to oss-security, please start by disclosing your use of AI to generate your message. Yes, there's a reason why I am so confident, and I find it borderline abuse when you send AI-generated messages without such disclosure. This is not the norm, at least not yet.

On Thu, Feb 05, 2026 at 10:24:03AM +0100, Raul Vega wrote: Public Disclosure Date: 2026-02-18 (14-day embargo per linux-distros policy) This is up to you, but personally and as linux-distros list admin I do not see the value in having this information under embargo. You could as well post this to oss-security right away. Just let us know of your decision on this.

What you describe reads like publicly known behavior of the software in question. The novelty, if any, may be in combining those pieces into an attack, yet this sounds like public discussion material to me. Technical Analysis 1. File-System Persistence Vector Most Linux distributions default to the FILE: ccache type, storing tickets in /tmp/krb5cc. What are the owners and permissions of those files? Exploitation: An LFI (Local File Inclusion) vulnerability in a web application can be used to "pull the trash" from /tmp, granting the attacker a valid TGT (Ticket Granting Ticket) with a ~10-hour TTL. Would a web application have permissions to read the /tmp/krb5cc files? Because many distributions do not restrict access to core dumps Which ones, for example? And what do you mean by "do not restrict"? Actionable Remediations for Distributions Distributions are requested to evaluate the following systemic changes to their default configurations:

Restrict corepattern: Ensure core dumps are directed to a secure, root-only directory by default. This is typical already. However, you can commonly access your own coredumps. Same with your own /tmp files.

So are you talking about potential restrictions within the same user account, so that sensitive information processed and available to the user previously does not remain available to the user for too long?

How exactly does fs.suiddumpable come into play, then? In other words, do your suggested attacks involve processes that are "dumpable" or/and those that are not? Which ones? Please be very specific.

I suggest that you clarify the above things in the public revision of your advisory. As it is, it reads like a mix of sensible content with everything else an LLM "thought" is relevant, plus the sensationalism.

Thanks,

Alexander

Jacob Bachmeyer <jcb62281 () gmail com> writes: On 2/19/26 21:26, Russ Allbery wrote:

That's also possible for services that accept usernames and passwords and validate them with Kerberos (common for POP and IMAP servers), although of course best practices in those cases is to immediately discard the resulting ticket after authentication.

I would that think in such a scenario, the client should be presenting a Kerberos service ticket to the POP/IMAP server. That requires Kerberos support in the client, which is notoriously not always available (mobile clients, for instance, often do not have Kerberos clients). It's been a problem in the mail world for a long time that we have a ton of better authentication protocols than PLAIN but a lot of mail clients still like using PLAIN, to such an extent that we have things like device-specific passwords to allow use of password authentication with less risk to the user's real credentials. If PAM is creating the ticket cache when the session is opened, then PAM should also be destroying the ticket cache when the session is closed. Yeah, definitely, it's a problem of not calling the right PAM functions to end the authentication (whether that involves a PAM session or not), which is a service bug, not a Kerberos bug. Across the open Internet is one thing, but I would expect (perhaps naively) that communications between web servers and the KDC would be on a secure internal network. The problem isn't so much the open Internet as it is load balancers, Kubernetes, VMs on bridge networks, and all the other network complexities that might be sitting between the server's understanding of its IP and the KDC, which is often segregated into an entirely separate secure network from general Internet-facing services and thus on the other side of some variety of NAT or the like. At least back in the day, the general feeling in the community I was part of was that address-locked tickets were operationally fragile and the security benefit wasn't really worth it. It's possible that changed, or that analysis is wrong. It stops the use of a stolen ticket in the report's scenario of a web service leaking files from /tmp.  :-) I'm not sure I would go to the effort of making address-locked tickets work just in case I configured a web server to serve /tmp for some reason, which comes back to your point about the merits of the original report (or lack thereof). Aha!  I did not know if the Kerberos cache stored tickets in separate files or all together.

If they are all stored in one file, along with the session keys needed to use them, then yes, distinctions between service tickets and TGTs are useless:  an attacker who steals a usable service ticket will also get a usable TGT, outside of very specialized scenarios where the service ticket endures after the TGT expires. I should add the substantial caveat that my experience is almost entirely with UNIX Kerberos. Windows uses its own way of managing ticket caches and it may well be mediated by some sort of process that, for instance, obtains service tickets and provides them without providing access to the TGT. I know nothing about how all that works except I know Microsoft did things to try to make it more secure.

But the report seemed to be primarily about UNIX Kerberos, and in that context generally the TGT and the service tickets are all in the same place (whether that be a file or keyring).

I don't know how KCM works. There's a daemon involved, so maybe it does something more sophisticated.

-- Russ Allbery (eagle () eyrie org) <https://www.eyrie.org/~eagle/>

On 2/19/26 14:29, Russ Allbery wrote: It's been some years since I've worked on Kerberos extensively, but I still maintain some Kerberos-related software and may be able to provide some context here. I have not been closely tracking developments in keyring formats and do not know how usable KEYRING caches are these days, so I may get some of these details wrong. Excellent, someone with more and/or more-recent knowledge on the topic!  :-) Jacob Bachmeyer<jcb62281 () gmail com> writes: On Thu, Feb 05, 2026 at 10:24:03AM +0100, Raul Vega wrote: The core of this vulnerability is a semantic failure in object lifecycle management. While the Kerberos protocol is syntactically secure, current Linux implementations fail to semantically bound the identity token (bearer ticket) to the process lifetime. Which process lifetime are we talking about here? My understanding is that the context of this report is services running with Kerberos credentials. [...]

[...]

In other words, this is a valid concern, but it's kind of a minor one. Having ticket caches lying around that live beyond the lifetime of the service creates some additional security risk, but in most cases it's less than the necessary security risk of having a keytab on the system that can be used to create new ticket caches at any time. [...] Exactly.  The risks here are already well-known; the report is bogus. [...] Arguable, but that is why you are supposed to invoke kdestroy in your logout script. A more typical design at institutions that use Kerberos heavily is to acquire Kerberos tickets on login via PAM (usually with sssd these days) and destroy them on logout via PAM as well so that users do not have to handle this in their shell files.

By weaponizing the "Crash and Trash" scenario, an attacker can transform a transient authentication secret into a persistent forensic artifact. This allows an unprivileged local attacker???or a remote attacker via an RCE/LFI chain???to bypass Kerberos protocol guarantees and achieve complete network-wide identity theft. Those are certainly all words. Some of them are even security-related. Exactly what LLMs are good at.  :-) [...] Exploitation: An LFI (Local File Inclusion) vulnerability in a web application can be used to "pull the trash" from /tmp, granting the attacker a valid TGT (Ticket Granting Ticket) with a ~10-hour TTL. Only if DAC is not being used properly.  If you are running a web application as root, you have bigger problems than stolen Kerberos tickets. I think the concern here is that the web application has its own tickets, which necessarily must be accessible to the web application. Therefore, if there is a vulnerability in the web application, that can be used to exfiltrate the Kerberos tickets for the web application.

Put that way, this is trivially and obviously correct. Maybe storing the tickets in a file in the file system makes it moderately easier to exfiltrate them given some sort of limited security flaw and keyring ticket caches might be less vulnerable, but this is highly speculative and depends on the exact nature of the vulnerability.

[...] 2. Memory Lifecycle Failure (Crash and Trash) When an application handling Kerberos authentication crashes, the system generates a core dump (if enabled).

The Semantic Gap: The credential remains in the heap or stack during the crash. Because many distributions do not restrict access to core dumps or leave them in unencrypted storage, these secrets become "trash" that is readily harvestable via standard string extraction. If, and only if, the application crashed during the authentication, or did not take proper steps to discard the credential after using it.  Again, this is (probably) an application bug, although I am not familiar enough with the Kerberos libraries to say what extent of care is taken to extinguish no-longer-needed in-memory copies of tickets. Yeah, this is just every piece of software in existence that manages its own secure credentials. The same can be said of software using X.509 credentials as well. If you want to use a differnet security system that stores all keys in a TPM, that may be the right choice in some security models, but that just means Kerberos is not a good fit for you.

Note that service tickets usually have much shorter lifetimes than TGTs, since they only need to be valid long enough to "run" from the KDC to the service, presenting the ticket at the latter. This varies a lot, and in my experience a more typical setup is for both TGTs and service tickets to have the same lifetimes. Regardless, though, for tickets for services that are managed externally, one can use a tool like kstart to regularly refresh the ticket cache, in which case you can set a short lifetime on both.

Or am I misremembering this part of Kerberos? If I remember correctly, stealing anything other than a TGT is useless, since service tickets are encrypted under a key in the TGT and contain a session key for talking to that service. No, this is not correct: If you have possession of the service ticket, you can authenticate as the user to that specific service. You do not need the TGT. Otherwise, limited ticket forwarding would not work.

-- Jacob

On 2/18/26 19:14, Solar Designer wrote: Hi,

Raul Vega, CC'ed here, sent the below AI-generated message to linux-distros on Feb 5, without disclosing the use of AI, yet correctly set the public disclosure date to "2026-02-18 (14-day embargo per linux-distros policy)" (or maybe the AI assistant did). That would be the first warning sign. Unfortunately, there was no further correspondence (in particular, I got no reply to my reply, also included below), and Raul failed to bring this to oss-security on time on his own, so I am now doing it for him. And yes, I consider this borderline abuse of the list, which is why my tone. And this would be a second strike. My summary of Raul AI's message is that Kerberos defaultccachename FILE is relatively unsafe compared to certain other possible kinds of credentials cache supported via this setting, especially with respect to local file inclusion vulnerabilities in other software such as web apps running under the same user account. The message suggests to use KEYRING or KCM instead of FILE. My summary up front:  this report is bogus. https://web.mit.edu/kerberos/krb5-1.22/doc/basic/ccachedef.html says FILE is the default. So it may be a case of unsafe default. Can the default reasonably be changed? "KCM caches work by contacting a daemon process", so will require this daemon to be running, and "KEYRING is Linux-specific, and uses the kernel keyring support". So maybe Linux packages can use KEYRING by default? I would not be so sure about FILE being unsafe at all. [...]

I'd appreciate follow-ups by those familiar with Kerberos (I'm not) and/or its packaging.

[...]

On Thu, Feb 05, 2026 at 10:24:03AM +0100, Raul Vega wrote: [vs] ADV-2026-005: Kerberos Credential Cache Lifecycle Failure and Bearer Token Theft Vulnerability Type: Semantic Design Flaw / Credential Dumping

Affected Components: MIT/Heimdal Kerberos, Linux Core Dump Handlers, /tmp Defaults

Researcher: Raul Vega del Valle

CVSS 3.1 Base: 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

CVSS 3.1 Chain: 10.0 (Critical) (When chained with RCE/LFI)

Public Disclosure Date: 2026-02-18 (14-day embargo per linux-distros policy)

Executive Summary: The Semantic Gap The core of this vulnerability is a semantic failure in object lifecycle management. While the Kerberos protocol is syntactically secure, current Linux implementations fail to semantically bound the identity token (bearer ticket) to the process lifetime.

By weaponizing the "Crash and Trash" scenario, an attacker can transform a transient authentication secret into a persistent forensic artifact. This allows an unprivileged local attacker???or a remote attacker via an RCE/LFI chain???to bypass Kerberos protocol guarantees and achieve complete network-wide identity theft.

Technical Analysis 1. File-System Persistence Vector Most Linux distributions default to the FILE: ccache type, storing tickets in /tmp/krb5cc.

The Design Flaw: These tickets are bearer tokens. Possession of the file is equivalent to possession of the identity.

Exploitation: An LFI (Local File Inclusion) vulnerability in a web application can be used to "pull the trash" from /tmp, granting the attacker a valid TGT (Ticket Granting Ticket) with a ~10-hour TTL.

2. Memory Lifecycle Failure (Crash and Trash) When an application handling Kerberos authentication crashes, the system generates a core dump (if enabled).

The Semantic Gap: The credential remains in the heap or stack during the crash. Because many distributions do not restrict access to core dumps or leave them in unencrypted storage, these secrets become "trash" that is readily harvestable via standard string extraction.

Impact: This bridges the gap from a simple application crash (Availability) to a full authentication bypass (Confidentiality/Integrity).

The Grand Chain: The Case for CVSS 10.0 While the individual components may be rated "High," the Semantic Addressing of this flaw creates a critical chain:

Entry (RCE/LFI): Attacker gains limited execution or read access via a library flaw (e.g., Axios SSRF or Undici CRLF).

Pivot (ADV-2026-005): Attacker provokes a crash or reads /tmp to dump the Kerberos ccache.

Escalation: The stolen ticket is replayed from the attacker's machine to access internal high-value targets (LDAP, S3 via IMDSv2, etc.).

Result: Total identity takeover across the infrastructure without triggering traditional "credential theft" alerts.

Actionable Remediations for Distributions Distributions are requested to evaluate the following systemic changes to their default configurations:

Restrict corepattern: Ensure core dumps are directed to a secure, root-only directory by default.

Default to KEYRING:: Shift the default defaultccachename in /etc/krb5.conf from FILE to KEYRING or KCM (Kerberos Credential Manager) to keep tickets in unswappable, process-bound kernel memory.

Enforce fs.suiddumpable: Harden kernel parameters to prevent unprivileged dumping of sensitive processes.

Researcher: Raul Vega del Valle

PGP Fingerprint: [Your Fingerprint]

On Fri, Feb 06, 2026 at 10:06:18AM +0100, Solar Designer wrote: Hello Raul,

[...]

On Thu, Feb 05, 2026 at 10:24:03AM +0100, Raul Vega wrote: [...] Technical Analysis 1. File-System Persistence Vector Most Linux distributions default to the FILE: ccache type, storing tickets in /tmp/krb5cc. What are the owners and permissions of those files?

Exploitation: An LFI (Local File Inclusion) vulnerability in a web application can be used to "pull the trash" from /tmp, granting the attacker a valid TGT (Ticket Granting Ticket) with a ~10-hour TTL. Would a web application have permissions to read the /tmp/krb5cc files? If it does, you have bigger problems than stolen Kerberos tickets. Because many distributions do not restrict access to core dumps Which ones, for example? And what do you mean by "do not restrict"? I believe that this means the AI was hallucinating. Actionable Remediations for Distributions Distributions are requested to evaluate the following systemic changes to their default configurations:

Restrict corepattern: Ensure core dumps are directed to a secure, root-only directory by default. This is typical already. However, you can commonly access your own coredumps. Same with your own /tmp files.

So are you talking about potential restrictions within the same user account, so that sensitive information processed and available to the user previously does not remain available to the user for too long?

How exactly does fs.suiddumpable come into play, then? In other words, do your suggested attacks involve processes that are "dumpable" or/and those that are not? Which ones? Please be very specific.

I suggest that you clarify the above things in the public revision of your advisory. As it is, it reads like a mix of sensible content with everything else an LLM "thought" is relevant, plus the sensationalism. -- Jacob

Hi,

Raul Vega, CC'ed here, sent the below AI-generated message to linux-distros on Feb 5, without disclosing the use of AI, yet correctly set the public disclosure date to "2026-02-18 (14-day embargo per linux-distros policy)" (or maybe the AI assistant did). Unfortunately, there was no further correspondence (in particular, I got no reply to my reply, also included below), and Raul failed to bring this to oss-security on time on his own, so I am now doing it for him. And yes, I consider this borderline abuse of the list, which is why my tone.

My summary of Raul AI's message is that Kerberos defaultccachename FILE is relatively unsafe compared to certain other possible kinds of credentials cache supported via this setting, especially with respect to local file inclusion vulnerabilities in other software such as web apps running under the same user account. The message suggests to use KEYRING or KCM instead of FILE.

https://web.mit.edu/kerberos/krb5-1.22/doc/basic/ccachedef.html says FILE is the default. So it may be a case of unsafe default. Can the default reasonably be changed? "KCM caches work by contacting a daemon process", so will require this daemon to be running, and "KEYRING is Linux-specific, and uses the kernel keyring support". So maybe Linux packages can use KEYRING by default?

In Heimdal, this setting is called defaultccname, apparently with defaultccachename added as an alias for MIT compatibility a few years ago. I couldn't quickly find what the default for it is.

BTW, if this actually required pre-publication discussion, I'd have insisted on bringing it from linux-distros to the full distros list, since Kerberos is not Linux-specific (and predates Linux).

I'd appreciate follow-ups by those familiar with Kerberos (I'm not) and/or its packaging.

Alexander

On Thu, Feb 05, 2026 at 10:24:03AM +0100, Raul Vega wrote: [vs] ADV-2026-005: Kerberos Credential Cache Lifecycle Failure and Bearer Token Theft Vulnerability Type: Semantic Design Flaw / Credential Dumping

Affected Components: MIT/Heimdal Kerberos, Linux Core Dump Handlers, /tmp Defaults

Researcher: Raul Vega del Valle

CVSS 3.1 Base: 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

CVSS 3.1 Chain: 10.0 (Critical) (When chained with RCE/LFI)

Public Disclosure Date: 2026-02-18 (14-day embargo per linux-distros policy)

Executive Summary: The Semantic Gap The core of this vulnerability is a semantic failure in object lifecycle management. While the Kerberos protocol is syntactically secure, current Linux implementations fail to semantically bound the identity token (bearer ticket) to the process lifetime.

By weaponizing the "Crash and Trash" scenario, an attacker can transform a transient authentication secret into a persistent forensic artifact. This allows an unprivileged local attacker???or a remote attacker via an RCE/LFI chain???to bypass Kerberos protocol guarantees and achieve complete network-wide identity theft.

Technical Analysis 1. File-System Persistence Vector Most Linux distributions default to the FILE: ccache type, storing tickets in /tmp/krb5cc.

The Design Flaw: These tickets are bearer tokens. Possession of the file is equivalent to possession of the identity.

Exploitation: An LFI (Local File Inclusion) vulnerability in a web application can be used to "pull the trash" from /tmp, granting the attacker a valid TGT (Ticket Granting Ticket) with a ~10-hour TTL.

2. Memory Lifecycle Failure (Crash and Trash) When an application handling Kerberos authentication crashes, the system generates a core dump (if enabled).

The Semantic Gap: The credential remains in the heap or stack during the crash. Because many distributions do not restrict access to core dumps or leave them in unencrypted storage, these secrets become "trash" that is readily harvestable via standard string extraction.

Impact: This bridges the gap from a simple application crash (Availability) to a full authentication bypass (Confidentiality/Integrity).

The Grand Chain: The Case for CVSS 10.0 While the individual components may be rated "High," the Semantic Addressing of this flaw creates a critical chain:

Entry (RCE/LFI): Attacker gains limited execution or read access via a library flaw (e.g., Axios SSRF or Undici CRLF).

Pivot (ADV-2026-005): Attacker provokes a crash or reads /tmp to dump the Kerberos ccache.

Escalation: The stolen ticket is replayed from the attacker's machine to access internal high-value targets (LDAP, S3 via IMDSv2, etc.).

Result: Total identity takeover across the infrastructure without triggering traditional "credential theft" alerts.

Actionable Remediations for Distributions Distributions are requested to evaluate the following systemic changes to their default configurations:

Restrict corepattern: Ensure core dumps are directed to a secure, root-only directory by default.

Default to KEYRING:: Shift the default defaultccachename in /etc/krb5.conf from FILE to KEYRING or KCM (Kerberos Credential Manager) to keep tickets in unswappable, process-bound kernel memory.

Enforce fs.suiddumpable: Harden kernel parameters to prevent unprivileged dumping of sensitive processes.

Researcher: Raul Vega del Valle

PGP Fingerprint: [Your Fingerprint] On Fri, Feb 06, 2026 at 10:06:18AM +0100, Solar Designer wrote: Hello Raul,

When you bring this to oss-security, please start by disclosing your use of AI to generate your message. Yes, there's a reason why I am so confident, and I find it borderline abuse when you send AI-generated messages without such disclosure. This is not the norm, at least not yet.

On Thu, Feb 05, 2026 at 10:24:03AM +0100, Raul Vega wrote: Public Disclosure Date: 2026-02-18 (14-day embargo per linux-distros policy) This is up to you, but personally and as linux-distros list admin I do not see the value in having this information under embargo. You could as well post this to oss-security right away. Just let us know of your decision on this.

What you describe reads like publicly known behavior of the software in question. The novelty, if any, may be in combining those pieces into an attack, yet this sounds like public discussion material to me. Technical Analysis 1. File-System Persistence Vector Most Linux distributions default to the FILE: ccache type, storing tickets in /tmp/krb5cc. What are the owners and permissions of those files? Exploitation: An LFI (Local File Inclusion) vulnerability in a web application can be used to "pull the trash" from /tmp, granting the attacker a valid TGT (Ticket Granting Ticket) with a ~10-hour TTL. Would a web application have permissions to read the /tmp/krb5cc files? Because many distributions do not restrict access to core dumps Which ones, for example? And what do you mean by "do not restrict"? Actionable Remediations for Distributions Distributions are requested to evaluate the following systemic changes to their default configurations:

Restrict corepattern: Ensure core dumps are directed to a secure, root-only directory by default. This is typical already. However, you can commonly access your own coredumps. Same with your own /tmp files.

So are you talking about potential restrictions within the same user account, so that sensitive information processed and available to the user previously does not remain available to the user for too long?

How exactly does fs.suiddumpable come into play, then? In other words, do your suggested attacks involve processes that are "dumpable" or/and those that are not? Which ones? Please be very specific.

I suggest that you clarify the above things in the public revision of your advisory. As it is, it reads like a mix of sensible content with everything else an LLM "thought" is relevant, plus the sensationalism.

Thanks,

Alexander

A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.

Under specific configurations where RC4-HMAC-MD5 is negotiated for GSSAPI-secured communication, attackers can sniff messages and use MD5 collision techniques to craft altered messages that retain the same MIC (Message Integrity Code). The vulnerable checksum function from RFC4757 allows this due to its flawed use of MD5. The attack relies on RC4 being chosen over stronger encryption options and presumes attacker access to the network traffic.

In MIT krb5 release 1.7 and later with incremental propagation enabled, an authenticated attacker can cause kadmind to write beyond the end of the mapped region for the iprop log file, likely causing a process crash.

In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdblog.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash.

https://mailman.mit.edu/pipermail/kerberos-announce/2024q2/000207.html and https://web.mit.edu/kerberos/www/krb5-1.21/ have announced the release on Wed. June 26 of Kerberos 1.21.3 with these changes: Fix vulnerabilities in GSS message token handling [CVE-2024-37370, CVE-2024-37371].

Fix a potential bad pointer free in krb5cccolhavecontents().

Fix a memory leak in the macOS ccache type. https://krbdev.mit.edu/rt/Ticket/Display.html?id=9128 and https://github.com/krb5/krb5/commit/b0a2f8a5365f2eec3e27d78907de9f9d2c80505a give this info for the issues assigned CVEs: In gsskrb5intunsealtokenv3() and gsskrb5intunsealv3iov(), verify the Extra Count field of CFX wrap tokens against the encrypted header. Reported by Jacob Champion.

In gsskrb5intunsealtokenv3(), check for a decrypted plaintext length too short to contain the encrypted header and extra count bytes. Reported by Jacob Champion.

In kgunsealiovtoken(), separately track the header IOV length and complete token length when parsing the token's ASN.1 wrapper. This fix contains modified versions of functions from k5-der.h and utiltoken.c; this duplication will be cleaned up in a future commit.

CVE-2024-37370:

In MIT krb5 release 1.3 and later, an attacker can modify the plaintext Extra Count field of a confidential GSS krb5 wrap token, causing the unwrapped token to appear truncated to the application.

CVE-2024-37371:

In MIT krb5 release 1.3 and later, an attacker can cause invalid memory reads by sending message tokens with invalid length fields. -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can modify the plaintext Extra Count field of a confidential GSS krb5 wrap token, causing the unwrapped token to appear truncated to the application.

Reference and upstream patch: https://github.com/krb5/krb5/commit/55fbf435edbe2e92dd8101669b1ce7144bc96fef

In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields.

Reference and upstream patch: https://github.com/krb5/krb5/commit/55fbf435edbe2e92dd8101669b1ce7144bc96fef

In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can modify the plaintext Extra Count field of a confidential GSS krb5 wrap token, causing the unwrapped token to appear truncated to the application.

In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields.

MIT IdentiBot is an open-source Discord bot written in Node.js that verifies individuals' affiliations with MIT, grants them roles in a Discord server, and stores information about them in a database backend. A vulnerability that exists prior to commit 48e3e5e7ead6777fa75d57c7711c8e55b501c24e impacts all users who have performed verification with an instance of MIT IdentiBot that meets the following conditions: The instance of IdentiBot is tied to a "public" Discord application—i.e., users other than the API access registrant can add it to servers; and the instance has not yet been patched. In affected versions, IdentiBot does not check that a server is authorized before allowing members to execute slash and user commands in that server. As a result, any user can join IdentiBot to their server and then use commands (e.g., /kerbid) to reveal the full name and other information about a Discord user who has verified their affiliation with MIT using IdentiBot. The latest version of MIT IdentiBot contains a patch for this vulnerability (implemented in commit 48e3e5e7ead6777fa75d57c7711c8e55b501c24e). There is no way to prevent exploitation of the vulnerability without the patch. To prevent exploitation of the vulnerability, all vulnerable instances of IdentiBot should be taken offline until they have been updated.

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/kdc/ndr.c.

References:

https://github.com/LuMingYinDetect/krb5defects/blob/main/krb5detect3.md

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.

References:

https://github.com/LuMingYinDetect/krb5defects/blob/main/krb5detect2.md

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmaprmt.c.

References:

https://github.com/LuMingYinDetect/krb5defects/blob/main/krb5detect1.md

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/kdc/ndr.c.

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmaprmt.c.

kdc/dotgsreq.c in MIT Kerberos 5 (aka krb5) 1.21 before 1.21.2 has a double free that is reachable if an authenticated user can trigger an authorization-data handling failure. Incorrect data is copied from one ticket to another.

lib/kadm5/kadmrpcxdr.c in MIT Kerberos 5 (aka krb5) before 1.20.2 and 1.21.x before 1.21.1 frees an uninitialized pointer. A remote authenticated user can trigger a kadmind crash. This occurs because xdrkadm5principalentrec does not validate the relationship between nkeydata and the keydata array count.