CVE-2026-50152: Ceph Monitor Flaw Exposes Cluster SSH Keys and Disk Encryption Secrets

Overview

A critical improper-authorization vulnerability has been disclosed in Ceph, the open-source distributed storage platform that underpins object, block, and file storage for a large share of private cloud and Kubernetes deployments. Tracked as CVE-2026-50152 (CVSS 9.1), the flaw lets any authenticated CephX user holding only the low-privilege mon allow r capability read the cluster's entire configuration-key store — including secrets an operator would reasonably assume were locked away from read-only accounts.

The config-key store is Ceph's internal key-value vault for sensitive cluster state. On cephadm-managed clusters, that vault holds the SSH private key cephadm uses to reach every node in the cluster — a key that grants root access by default. It also holds OSD LUKS disk-encryption passphrases. A read-only monitor role turning into a full cluster and host takeover primitive is what pushes this finding to critical severity.

Technical Details

How It Works

The vulnerability lives in Ceph's Monitor subscription handler. The handler is supposed to authorize requests against the config-key store before returning data, but it fails to properly validate that a requesting client's capabilities extend beyond basic monitor read access. By sending a single crafted MMonSubscribe message, an attacker who already holds a routine mon allow r CephX identity — the kind of low-privilege, read-only role commonly handed to monitoring tools, dashboards, and junior operators — can pull the full contents of the config-key store rather than the limited subset they were meant to see.

This is a disclosure bug, not a write primitive: the attacker cannot directly modify cluster state through this flaw alone. The severity comes entirely from what gets disclosed. On any cephadm-orchestrated cluster, the leaked SSH private key is enough to pivot straight to root on every host in the deployment, and leaked OSD LUKS passphrases undermine at-rest encryption entirely.

Impact Assessment

Who Is At Risk

• Any Ceph cluster running Squid releases prior to 19.2.6 or Tentacle releases prior to 20.2.4
• Clusters that grant mon allow r capabilities broadly — a common pattern for monitoring integrations (Prometheus exporters, dashboards, automation service accounts)
• cephadm-managed clusters specifically, since the cephadm SSH key sits in the exposed store and defaults to root-equivalent access on every node

Attack Chain

1. Low-privilege foothold — Attacker obtains or already holds any CephX identity with mon allow r (routine, widely distributed)
2. Config-key exfiltration — A single crafted MMonSubscribe request against the Monitor dumps the entire config-key store
3. Credential extraction — Attacker recovers the cephadm SSH private key and any OSD LUKS passphrases from the dump
4. Full cluster/host compromise — SSH key grants root on every cluster node by default; LUKS passphrases defeat disk-level encryption

Mitigation

Immediate Actions

• Upgrade to Ceph 19.2.6 (Squid) or 20.2.4 (Tentacle) — both released 2026-08-19 and fix the authorization check in the Monitor subscription handler
• Rotate the cephadm SSH key immediately, even on patched clusters, since any credential that may already have been read from the config-key store should be treated as compromised
• Rotate OSD LUKS passphrases where feasible, following Ceph's disk-encryption key-rotation procedure
• Audit CephX capability grants — review which identities hold mon allow r and tighten scope where broad monitor-read access isn't required

There is no formal workaround for unpatched clusters short of restricting network access to the Monitor daemons to trusted hosts only, which does not eliminate risk from any identity that already holds monitor-read capabilities.

Detection Opportunities

• Review Monitor logs for unexpected or repeated MMonSubscribe requests from identities that shouldn't need config-key access
• Audit which service accounts and automation tooling hold mon allow r and confirm none of them are internet- or tenant-exposed
• After upgrading, confirm the cephadm SSH key and OSD LUKS passphrases have actually been rotated — patching the code does not invalidate secrets already exposed

Background

CVE-2026-50152 was reported independently by David Mohren and Mark Nelson of CLYSO, and separately validated by David Korczynski of Ada Logics. It shipped as part of a bundled four-CVE Ceph security release alongside CVE-2025-30156, CVE-2026-39944, and CVE-2026-54330.

Notably, part of the discovery work behind this class of finding traces back to Anthropic's use of AI agents to systematically study open-source security — the same broader research effort behind recent large-scale zero-day discovery sweeps across major open-source systems. It's a useful reminder that agentic vulnerability research is increasingly surfacing subtle authorization logic bugs — like a read-only role reaching a privileged data store — that are easy to miss in manual review but straightforward to enumerate systematically.

Given how routinely mon allow r capabilities are handed out for monitoring and automation purposes, organizations running self-managed Ceph clusters — especially cephadm deployments — should treat this as an urgent patch-and-rotate priority rather than a routine update.

References

• NVD — CVE-2026-50152
• Ceph Security Advisories — CVE-2026-50152
• Ceph v20.2.4 / v19.2.6 Release Announcement