Database/Container, Kubernetes & orchestration
Slurm: Incorrect access control leading to information disclosure across users' jobs
Impact
Incorrect access control leading to information disclosure across users' jobs
Who can reach it
Any user who can submit a job
What to do
Upgrade Slurm
Fleet impact
How widespread
Very common - Slurm is the default scheduler on HPC-style GPU clouds and on most bare-metal H100/GB200 clusters sold to AI labs
Cost to remediate
daemon-restart fleet-wide - SchedMD is explicit that the cluster stays vulnerable until *every* slurmdbd, slurmctld and slurmd has restarted, i.e. a coordinated restart across all compute nodes
Why it hits the whole fleet
Credential-handling flaw lets an unprivileged user impersonate SlurmUser and then run arbitrary processes as root; affects every Slurm release since 1.0.0, so one bug covers the whole scheduler estate
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.