CVE-2026-25506: 
NixOS vulnerability analysis and mitigation

CVE-2026-25506 is a heap buffer overflow vulnerability in the MUNGE authentication daemon (munged) that allows a local attacker to leak cryptographic key material from process memory and subsequently forge arbitrary credentials. It affects MUNGE versions 0.5 through 0.5.17 and was discovered during a security audit by Titouan Lazard of LEXFO, with responsible disclosure and public advisory published on February 10, 2026. The vulnerability is fixed in MUNGE 0.5.18. It carries a CVSS v3.1 base score of 7.8 (High) per NVD, and 7.7 (High) per the upstream advisory (GitHub Advisory, Openwall OSS-Sec).

The root cause is an out-of-bounds write (CWE-787 / CWE-120) in the _msg_unpack() function within src/libcommon/m_msg.c. When unpacking a MUNGE_MSG_DEC_RSP message, the addr_len field (a uint8_t) is read from untrusted message data and passed directly to _copy() without bounds validation. Since the m_msg structure's addr field is only 4 bytes (a struct in_addr), setting addr_len to 255 causes _copy() to write 251 bytes past the end of the field, corrupting subsequent structure members including conf->mac_key. The overflow occurs during the unpacking phase — before message type validation in job_exec() rejects the response-type message — meaning any local user who can connect to munged's Unix socket can trigger it. The fix adds a single bounds check: if (m->addr_len > sizeof(m->addr)) goto err; (GitHub Commit, GitHub Advisory).

Successful exploitation allows a local attacker to extract the MAC subkey (conf->mac_key) and potentially other cryptographic secrets from munged's process memory, even on systems with modern mitigations (ASLR, PIE, NX, RELRO). With the leaked key material, the attacker can forge arbitrary MUNGE credentials to impersonate any user — including root — to any service relying on MUNGE for authentication. In HPC environments where workload managers (e.g., Slurm) use MUNGE, this could enable full privilege escalation across the cluster. If exploitation occurred before patching, the attacker may retain the ability to forge credentials even after the patch is applied, necessitating key regeneration (GitHub Advisory, Openwall OSS-Sec).

A proof-of-concept (PoC) exploit was developed by the reporting researcher (Titouan Lazard, LEXFO) that demonstrates successful MAC subkey extraction on systems with modern security mitigations enabled; however, the PoC does not implement the full credential forgery step, which is described as theoretically straightforward. There is no evidence of in-the-wild exploitation as of the disclosure date. The EPSS score is 0.018% (very low probability of near-term exploitation). The vulnerability is not listed in the CISA KEV catalog. No threat actor attribution has been reported (GitHub Advisory, Openwall OSS-Sec).

1. Gain local access: Obtain a low-privileged local account on a system running a vulnerable munged instance (MUNGE 0.5–0.5.17).
2. Connect to munged's Unix socket: Establish a connection to the munged Unix domain socket (typically /var/run/munge/munge.socket.2) using standard socket APIs available to any local user.
3. Craft a malicious MUNGE_MSG_DEC_RSP message: Construct a message of type MUNGE_MSG_DEC_RSP with the addr_len field set to 255 (maximum uint8_t value), far exceeding the 4-byte struct in_addr field size.
4. Trigger the buffer overflow: Send the crafted message to munged. The _msg_unpack() function reads addr_len=255 and calls _copy() without bounds validation, writing 251 bytes past the end of the addr field and corrupting subsequent structure members including conf->mac_key.
5. Extract the MAC subkey: Leverage the corrupted internal state to read leaked cryptographic material (the MAC subkey) from munged's process memory via the response or observable side effects.
6. Forge MUNGE credentials: Use the extracted MAC subkey to construct valid MUNGE credential tokens impersonating any user (including root) and present them to MUNGE-authenticated services (e.g., Slurm) to gain unauthorized access or escalate privileges (GitHub Commit, GitHub Advisory).

• Network/Socket: Unexpected or repeated connections to the munged Unix socket (/var/run/munge/munge.socket.2) from unprivileged user accounts, especially outside normal job submission patterns.
• Logs: munged log entries showing malformed or rejected MUNGE_MSG_DEC_RSP messages; unusual error messages related to message unpacking or address length validation in /var/log/munge/munged.log.
• Process Behavior: Unusual child processes or commands executed under the identity of privileged users (e.g., root or HPC service accounts) that cannot be attributed to legitimate job submissions.
• Authentication Events: MUNGE credential decode requests for high-privilege users (root, service accounts) originating from unexpected hosts or user sessions in workload manager logs (e.g., Slurm's slurmctld.log).
• File System: Presence of custom scripts or binaries in user home directories designed to interact with the munged socket or manipulate MUNGE tokens.

Upgrade MUNGE to version 0.5.18 or later, which adds a bounds check on addr_len before the copy operation in _msg_unpack() (GitHub Release). Vendor patches are available for Debian (DSA-6129-1, DLA-4477-1), Ubuntu (USN-8040-1), SUSE (SUSE-SU-2026:0448-1, SUSE-SU-2026:0451-1), Red Hat (RHSA-2026:2918, RHSA-2026:2923, RHSA-2026:2934, RHSA-2026:2954, RHSA-2026:3011, RHSA-2026:3033), Fedora, AlmaLinux, and Oracle Linux. After patching, regenerate MUNGE keys cluster-wide: stop munged on all nodes, generate a new key with sudo -u munge /usr/sbin/mungekey --create --force --verbose, distribute the new key to all nodes, and restart munged. As an interim measure, restrict local access to systems running vulnerable MUNGE versions where operationally feasible (GitHub Advisory, Openwall OSS-Sec).

The MUNGE maintainer Chris Dunlap disclosed the vulnerability directly to the oss-security mailing list on February 10, 2026, emphasizing responsible disclosure and the absence of in-the-wild exploitation (Openwall OSS-Sec). A follow-up post on February 17, 2026 by Sam James noted the publication of a detailed technical write-up by LEXFO (the reporting firm) at https://blog.lexfo.fr/munge-heap-buffer-overflow.html (Openwall Follow-up). The vulnerability received coverage in The Hacker News weekly recap and was picked up by multiple Linux security advisory aggregators (Debian, SUSE, Ubuntu, Red Hat, Fedora, AlmaLinux, Oracle). Social media activity was limited but present on Bluesky infosec feeds.