Ceph CVE-2026-50152

Requires a valid CephX identity with at least mon allow r capability and network reachability to a Ceph monitor daemon; no config-key capability and no admin/write privileges are needed - that missing authorization check is the entire bug. Exploitation is authenticated (PR:L): the attacker must already possess some CephX key, which limits it to insiders, compromised clients, or leaked keyrings rather than fully anonymous internet attackers. The catastrophic host-root escalation specifically requires a cephadm-managed cluster running its default configuration (where the cluster-wide SSH private key lives in config-key); OSD LUKS passphrase exposure requires that at-rest OSD encryption is in use. On a non-cephadm, non-encrypted cluster the impact is limited to whatever other secrets operators stored in the config-key store, which still typically includes sensitive material.

This is a genuine high-priority issue, not a high-CVSS-but-low-impact artifact. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C, base 9.1) is internally consistent with the description: network-reachable, low-complexity, requiring only a minimal read-only CephX identity, with a scope change reflecting that a monitor-level read yields secrets that compromise separate systems (the underlying hosts). The authorization bug itself is a confidentiality read, but the escalation path - leaked SSH key → root on every node under default cephadm configuration - realistically turns it into full integrity and availability loss, which is why I assess higher I/A impact than the published vector. No EPSS score, KEV entry, or public POC was provided, so probabilistic and in-the-wild signals are absent; the presence of a committed QA test that drives the kv: subscription lowers the bar for a working exploit but is not itself weaponized code. Any operator running a cephadm-managed or LUKS-encrypted Ceph cluster with more than a handful of CephX identities - down to a mid-sized team running a single storage cluster - should treat patching as urgent, because the prerequisite (a read-only account) is common and the payoff is total. Conflicting/missing-data caveat: EPSS and exploitation-status signals are not present in the input, so real-world exploitation frequency cannot be confirmed and should be verified against CISA KEV and vendor channels.

An attacker who has obtained a minimal read-only CephX key (for example, a monitoring or reporting account with mon allow r, or a leaked client keyring) connects to a monitor and sends a crafted MMonSubscribe message subscribing to kv: entries. The monitor streams back the entire config-key store, from which the attacker extracts the cephadm SSH private key and OSD LUKS passphrases, then SSHes as root into every cluster host. No public exploit is identified at time of analysis, but a QA reproduction driving the kv: subscription path ships in the fix commit.