Ceph: four flaws break trust across CephX, STS, Monitor and SigV4

Four CVE records published on 28 August describe separate paths from limited access to broad privileges in Ceph. CVE-2025-30156 concerns unsafe cryptography in CephX, CVE-2026-39944 concerns malleable STS session tokens in RADOS Gateway, CVE-2026-50152 concerns unauthorised access to the Monitor config-key store, and CVE-2026-54330 concerns unsigned additional x-amz-* headers in SigV4 requests.

All four issues are fixed in Ceph 20.2.4 and 19.2.6. The project advisories are dated 19 August; today’s development is publication of coherent CVE records in public catalogues. That distinction matters operationally: systems that did not act on the vendor mailing may now open findings from CVE identifiers.

The shared theme extends beyond Ceph. Confidentiality without integrity does not protect a credential, a signature covering only part of a request does not authorise the whole request, and permission to read Monitor status should not automatically expose a secret store. Each case is a version of one rule: the security decision must cover the complete object and context later consumed by the system.

CVE-2025-30156: CephX encrypts data without authenticating it

CephX used AES-128-CBC without a message authentication code and with a fixed initialisation vector. Encryption could conceal plaintext, but it did not detect modification of ciphertext. In CBC mode, a controlled change to one block can predictably change part of the decrypted data. When a protocol does not check integrity, the receiver may accept altered data as authentic.

The advisory describes two escalation mechanisms. In the first, an attacker has a compromised low-privilege key and a position from which CephX traffic can be observed. The Monitor can then act as an encryption oracle for chosen entity names. Ciphertext blocks can be spliced into credentials for privileged components such as Manager, MDS or OSD. In the second, a user with CephX permission changes one bit in a service ticket so that its allow_all field becomes true.

The advisory assigns CVSS 3.1 8.9 (High). This is not a no-prerequisite attack: it starts with a key or ticket and the first variant also needs visibility of ciphertext. The resulting impact can nevertheless cover the cluster because a forged daemon identity crosses the client’s original security scope.

CVE-2026-39944: the same cryptographic problem in an RGW STS token

RADOS Gateway used the same unauthenticated AES-CBC handler to protect STS session tokens. A holder of any valid token could alter ciphertext without detection and affect the acct_type, perm_type and is_admin fields. Setting the administrative value activated a global override of capability checks in RGW.

Its exposure differs from the CephX flaw. This path is remotely reachable through the S3 endpoint when STS is enabled. It needs neither observation of the internal messenger network nor an encryption oracle. The starting point is a legitimate, potentially unprivileged STS token. GitHub assigns CVSS 3.1 8.5 (High).

This is why “the token is encrypted” is not a sufficient requirement. A credential carries authorization decisions and therefore must resist modification. A modern design should use authenticated encryption or a correctly bound MAC and reject a token before interpreting its fields whenever integrity verification fails.

CVE-2026-50152: mon allow r opens a secret store

The third flaw is not cryptographic. The Monitor subscription handler did not correctly authorise access to the config-key store. A CephX user holding mon allow r capability could retrieve its full contents through a subscription message.

The store may contain OSD LUKS passphrases and, in cephadm-managed clusters, the SSH private key used to connect to every host. Under the default cephadm arrangement, that key gives root access. A constrained monitoring account can thus become a route to compromise data, the management plane and node operating systems.

The advisory assigns CVSS 3.1 8.2 (High) and requires a compromised account with mon allow r plus cluster-network access. Administrators should not infer that a “read-only” account is harmless by definition. Scope matters in a distributed system: reading health is a different class of action from reading secrets that can change the entire state.

CVE-2026-54330: SigV4 does not cover every relevant header

In a correctly validated AWS Signature Version 4 request, X-Amz-SignedHeaders identifies signed headers, but a server must also reject additional security-sensitive x-amz-* headers that are absent from the signature. Ceph RGW validated the listed set without rejecting additional members of that header family.

A holder of a presigned PUT URL could therefore attach unsigned information that RGW honoured. The signature remained mathematically correct for the original set, while the request executed by the server had broader semantics than the issuer intended. The advisory assigns CVSS 3.1 8.2 (High).

This does not mean every presigned URL exposes the entire bucket. The path requires a write URL and suitable additional headers. The architectural lesson remains clear: a verifier cannot permit an unsigned field to alter an authorised outcome. The canonical request must include every security-sensitive input or reject it explicitly.

Identifying affected clusters

The project marks releases before 20.2.4 and 19.2.6 as affected. Organisations using Red Hat, IBM, OpenShift Data Foundation or CLYSO distributions should map the product release to its actual Ceph build and apply the vendor backport. The parent platform version alone is not enough.

Assess exposure separately. For CephX, inventory client keys, messenger-network segmentation and traffic-observation opportunities. For STS, establish whether it is enabled and who can obtain a token. For config-key, identify every subject with mon allow r and the secrets present in the store. For SigV4, locate systems issuing presigned PUT URLs and the headers allowed by gateways, proxies and SDKs.

Upgrade and remediation order

Prepare a controlled upgrade to 20.2.4, 19.2.6 or the corresponding vendor build. Check Monitor quorum, PG state, OSD health, client compatibility and rollback procedure. A cluster holding critical data should not update every node simultaneously without a validated availability plan.

After patching, assess rotation of authentication material. Rotation is particularly justified if an untrusted account held mon allow r, STS was broadly available or anomalies were found. Scope may include CephX keys, the cephadm SSH key, tokens and potentially LUKS passphrases. Order matters: establish a functioning new administration path before invalidating its predecessor.

Clearing active RGW sessions alone is insufficient. If an attacker created durable capabilities, users, bucket policies or objects, defenders must reconstruct the state from logs and compare it with an approved baseline.

Detection and incident readiness

For CephX, look for unusual entity names, bursts of ticket requests, new clients and daemon identities used from unexpected addresses. For RGW, correlate STS issuance with later administrative operations. A token created with a small scope should not suddenly perform global actions.

For Monitor, examine config-key subscriptions and reads performed by accounts with mon allow r, especially subjects without historical use of these messages. For SigV4, log the signed-header list and the actual x-amz-* header set. A difference is a strong investigation signal, though proxies may need additional telemetry.

Preserve entity-to-key mappings, capability audit history, Monitor and RGW logs, STS issuance data and policy history. Do not place complete tokens or secrets in a central SIEM. Stable identifiers and secure hashes are usually enough for correlation.

Primary facts and Breachroad conclusions

Mechanisms, prerequisites, CVSS scores and fixed releases come from the Ceph project advisories and CVE records. Recommendations about rotation order, telemetry correlation and evaluating the four paths separately are Breachroad’s defensive conclusions. Public sources do not report exploitation in a specific incident; an affected version is evidence of exposure, not evidence of compromise.

Primary sources

• GHSA-7q3q-3975-qw3q — AES-CBC in CephX
• GHSA-j73r-qrgx-jvq2 — RGW STS tokens
• GHSA-rg9p-5xcp-wm8h — Monitor config-key store
• GHSA-rmjq-ffrm-j6vj — unsigned SigV4 headers
• Ceph 20.2.4
• Ceph 19.2.6

These flaws emerge at the seam between cryptography, protocol design and permissions. Our cybersecurity training for technical teams teaches engineers to test token integrity and authorization scope in distributed systems. When you need validation of a live exposure, web and API penetration testing can cover S3 gateways, identity federation and administrative paths within an agreed scope.