GPU VulnDB

Database/Control plane, storage & DevOps

Ceph Monitor: any read-only CephX user can dump the config-key store, including cephadm's cluster-wide SSH key

CVE-2026-50152Control plane, storage & DevOpscurated

Impact

A CephX identity holding nothing more than mon allow r can send one crafted MMonSubscribe message and read the entire monitor config-key store. That store holds OSD LUKS disk-encryption passphrases and, on cephadm-managed clusters, the SSH private key cephadm uses to log into every host in the cluster - which is root by default. On a GPU fleet where Ceph backs the shared dataset and checkpoint tier, this turns any low-privileged read-only key handed to a tenant job, a monitoring agent, or a CSI provisioner into root on every storage host, and hands over the keys needed to decrypt OSD media offline. Credentials distributed to many clients are hard to recall, so rotation after exposure is a fleet-wide job, not a single change.

Who can reach it

Any authenticated CephX client that can reach the monitors and holds at least mon allow r. No elevated capability and no local access required.

What to do

Upgrade to Ceph 20.2.4 or 19.2.6 and restart the monitor daemons; this is a rolling restart of the mon quorum and does not require draining GPU nodes. Because the SSH key and LUKS passphrases may already have been read by anyone who held a read-only key, treat them as exposed: rotate the cephadm SSH key and review which clients hold mon allow r after upgrading. Until you can upgrade, audit and trim read-only CephX capabilities handed to tenants and side-car services.

References

Related entries

All Control plane, storage & DevOps entries

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.