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/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