MUNGE just announced a serious security issue as CVE-2026-25506:
https://github.com/dun/munge/security/advisories/GHSA-r9cr-jf4v-75gh
The issue is entirely within MUNGE - specifically in the munged daemon.
However, as most Slurm installations explicitly trust MUNGE as the
source of authentication, Slurm's security is immediately undermined if
an attacker were to exploit that issue and gain access to the MUNGE key.
On Slurm clusters you should treat that security issue as if it were
local-root exploit.
If you have switched to Slurm's built-in authentication ("auth/slurm"),
you are not impacted by this issue. (However, we do not recommend
switching over as a mitigation - you cannot safely change authentication
types in Slurm while jobs are currently running.)
I strongly encourage sites to get install the fixed packages from the
upstream distros and restart the munged daemon on all nodes. If you
install and restart munged promptly then Slurm should be unaffected.
You do not need to rebuild Slurm for this issue. The MUNGE ABI/API
remain unchanged, so there is no need to recompile Slurm, and there are
no patches to apply to Slurm related to this issue.
If you are concerned that an attacker could have compromised the MUNGE
key itself, you may want to rotate that key. Unfortunately there's no
mechanism to safely handle this key rotation with the cluster
operational, and I do not recommend key rotation as long as you're
installing and restarting MUNGE ASAP.
- Tim
--
Tim Wickberg
Director, System Software, Slurm and Slinky, NVIDIA
--
slurm-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
