A storage identity with read permission should not reach encryption keys or administrative host credentials. In CVE-2026-50152, that separation failed inside the Ceph Monitor: any CephX entity with the mon allow r capability could send a crafted subscription and receive the cluster's entire config-key store.
Red Hat assigns the flaw a preliminary CVSS 3.1 score of 8.2, with vector CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L. The attacker must reach the cluster network and hold a valid low-privilege CephX key, but no interaction from another person is required. Ceph's documentation states that one crafted MMonSubscribe message deterministically returns the secrets.
Who is exposed and which versions are fixed
The Ceph advisory declares all prior versions vulnerable. Fixes are available in the still-supported branches, Tentacle 20.2.4 or later and Squid 19.2.6 or later, both released on August 19, 2026. Older unsupported versions have no listed fixed release, so remaining on them is not a mitigation strategy.
- Access condition: cluster connectivity and a valid CephX identity
- Sufficient capability on a vulnerable system: mon allow r
- User interaction: none
- Fixed versions: Tentacle 20.2.4+ and Squid 19.2.6+
- Earlier versions: treated as vulnerable by the Ceph project
- CWE: 862, missing authorization
How a subscription becomes vault access
The Monitor processes subscriptions for different internal maps and channels. Before the fix, the generic Monitor read check also accepted subscriptions whose names started with kv:, the prefix used by the config-key store. Holding mon allow r was therefore enough to cross an authorization boundary that should have been specific to the secret repository.
} else if (p->first.starts_with("kv:")) {
if (!s->is_capable("config-key", MON_CAP_R)) {
dout(5) << __func__ << " " << op->get_req()->get_source_inst()
<< " not enough caps for " << p->first << " -- dropping"
<< dendl;
continue;
}
}The patch moves the decision ahead of subscription registration and drops the request when the config-key capability is missing. That detail matters in code review: checking authorization only when data is delivered can leave other subscription paths or side effects reachable. The project confirmed the MMonSubscribe vector but did not publish the message bytes. We therefore do not fabricate a payload that only appears functional without being verifiable.
The contents of config-key change the impact
The config-key store does not contain only harmless configuration. Ceph lists OSD LUKS passphrases, dashboard secrets, and gateway credentials. In clusters managed by cephadm, it may also contain the private SSH key used to authenticate to every managed host. An unauthorized read becomes more than a disclosure when that key enables root access to cluster machines.
CVSS describes the base condition, but configuration determines the blast radius. A cluster without cephadm has a different chain from an environment where one SSH key administers every node. Secret inventory, credential reuse, network reach, and usage records must be part of the impact analysis.
How to validate exposure without reading secrets
Initial triage does not need to reproduce the extraction. Confirm the versions actually running across the daemons and list only the Monitor capabilities assigned to entities. The command below drops the key field in the filter and displays only the name and mon cap. The output should still be treated as administrative information and collected in a controlled session.
ceph versions --format json-pretty
ceph auth ls --format json |
jq -r '.auth_dump[]
| select(.caps.mon? != null)
| [.entity, .caps.mon]
| @tsv'Look for mon allow r, combinations such as allow rw or allow rwx, allow *, and profiles that resolve to read access. Do not treat the absence of an obvious identity as proof of safety: service accounts, CephFS clients, backup integrations, and old credentials may hold this capability. Dynamic confirmation belongs only in an isolated lab or an authorized pentest with explicit permission to manipulate the Monitor protocol.
Updating closes the read but does not invalidate leaked material
Installing Tentacle 20.2.4 or Squid 19.2.6 blocks new subscriptions without the specific capability, but it does not revoke a secret that was already obtained. The project specifically recommends immediately rotating the cephadm SSH key on clusters managed by it. For other secrets, operators should assess exposure and follow the relevant product or integration procedure, preserving evidence before changing the environment when abuse is suspected.
- Update every daemon and confirm that no Monitor remains on a vulnerable version
- Inventory identities with any Monitor read capability and remove unnecessary access
- Rotate the cephadm SSH key and distribute the new key through the official procedure
- Map OSD passphrases, dashboard secrets, and gateway credentials stored in config-key
- Review authentication logs, Monitor connections, and SSH access inconsistent with expected operations
- Preserve evidence and expand the investigation to every host reachable with exposed credentials
- Move unsupported clusters to a branch that receives security fixes
What this flaw adds to infrastructure pentesting
Read permission is not synonymous with low impact. In distributed systems, an apparently restricted principal may query metadata, subscribe to internal channels, or reach vaults used by the control plane. A Ceph pentest should test every identity's effective capabilities, Monitor protocol boundaries, and the destinations of administrative secrets. The useful question is not only what the account can read. It is which new identities it can assume after that read.