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.
An issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. The pre-defined function "strlen" is getting a "NULL" string as a parameter value in plugins/kdb/ldap/libkdbldap/ldapprincipal2.c in the Key Distribution Center (KDC), which allows remote authenticated users to cause a denial of service (NULL pointer dereference) via a modified kadmin client.
An issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->nkeydata" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data.
An unspecified third-party database module for the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) 1.10.x allows remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) via a crafted request, a different vulnerability than CVE-2013-1418.
A null pointer dereference flaw was found in Kerberos's GSS-API spnego security mechanism implemenation. A local user could use this flaw to cause a denial of service (krb5 daemon crash) via invalid ContextFlags for the reqFlags field in the NegTokenInit (RFC 4178).
References: http://krbdev.mit.edu/rt/Ticket/Display.html?user=guest&pass=guest&id=6402
Upstream patch: http://src.mit.edu/fisheye/changelog/krb5/?cs=22099
Certain weaknesses in the implementation of version 4 of the Kerberos protocol (krb4) in the krb5 distribution, when triple-DES keys are used to key krb4 services, allow an attacker to create krb4 tickets for unauthorized principals using a cut-and-paste attack and "ticket splicing."
Version 4 of the Kerberos protocol (krb4), as used in Heimdal and other packages, allows an attacker to impersonate any principal in a realm via a chosen-plaintext attack.
The Key Distribution Center (KDC) in Kerberos 5 (krb5) 1.2.7 and earlier allows remote, authenticated attackers to cause a denial of service (crash) on KDCs within the same realm using a certain protocol request that causes the KDC to corrupt its heap (aka "buffer underrun").
The Key Distribution Center (KDC) in Kerberos 5 (krb5) 1.2.7 and earlier allows remote, authenticated attackers to cause a denial of service (crash) on KDCs within the same realm using a certain protocol request that causes an out-of-bounds read of an array (aka "array overrun").
Buffer overflow in ksu in Kerberos 5 allows local users to gain root privileges.
Buffer overflow in krshd in Kerberos 5 allows remote attackers to gain root privileges.
Buffer overflow in krbrdreq function in Kerberos 4 and 5 allows remote attackers to gain root privileges.
Buffer overflow in krb425convprincipal function in Kerberos 5 allows remote attackers to gain root privileges.
Buffer overflow in ssh 1.2.26 client with Kerberos V enabled could allow remote attackers to cause a denial of service or execute arbitrary commands via a long DNS hostname that is not properly handled during TGT ticket passing.
Kerberos 4 key servers allow a user to masquerade as another by breaking and generating session keys.
Use-after-free vulnerability in kadmin/server/serverstubs.c in kadmind in MIT Kerberos 5 (aka krb5) 1.5 through 1.6.3 allows remote authenticated users to cause a denial of service (daemon crash) via a request from a kadmin client that sends an invalid API version number.
The Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) 1.7 before 1.7.2, and 1.8 alpha, allows remote attackers to cause a denial of service (assertion failure and daemon crash) via an invalid (1) AS-REQ or (2) TGS-REQ request.
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
Buffer overflow in BSD-based telnetd telnet daemon on various operating systems allows remote attackers to execute arbitrary commands via a set of options including AYT (Are You There), which is not properly handled by the telrcv function.
Buffer overflow in Kerberos 4 KDC program allows remote attackers to cause a denial of service via the emsg variable in the kerberrreply function.
Kerberos 4 KDC program does not properly check for null termination of AUTHMSGKDCREQUEST requests, which allows remote attackers to cause a denial of service via a malformed request.
Buffer overflow in Kerberos 4 KDC program allows remote attackers to cause a denial of service via the localrealm variable in the processv4 function.
Buffer overflow in Kerberos 4 KDC program allows remote attackers to cause a denial of service via the lastrealm variable in the settgtkey function.
Kerberos 4 KDC program improperly frees memory twice (aka "double-free"), which allows remote attackers to cause a denial of service.
Kerberos 4 (aka krb4) allows local users to overwrite arbitrary files via a symlink attack on new ticket files.
Double free vulnerabilities in error handling code in krb524d for MIT Kerberos 5 (krb5) 1.2.8 and earlier may allow remote attackers to execute arbitrary code.