Description

Ceph is an open-source distributed storage platform providing object, block, and file storage. In versions prior to 20.2.4 and 19.2.6, the CephX authentication protocol encrypts tickets with AES-128-CBC in an unauthenticated mode that uses a hard-coded initialization vector and no message authentication, allowing an attacker to forge credentials and gain cluster-wide access. Because the ciphertext is malleable and the monitor will encrypt attacker-chosen entity names, an attacker holding one low-privilege key and able to observe CephX traffic can use the monitor as an encryption oracle and splice ciphertext blocks into valid tickets for privileged entities such as Manager, MDS, and OSD. The same lack of authentication also lets an attacker with CephX permissions escalate privileges by flipping a single bit in a service ticket to set its allow_all field to true. This issue is fixed in versions 20.2.4 and 19.2.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.9",
  "pubDate": "2026-08-28T00:16:45.557Z",
  "pubdate": "2026-08-28T00:16:45.557Z",
  "executiveSummary": "Ceph is susceptible to a critical authentication protocol vulnerability within the CephX mechanism, arising from the use of unauthenticated AES-128-CBC encryption. This cryptographic failure allows an attacker to manipulate ticket data, leading to full cluster-wide unauthorized access.\nThe vulnerability manifests due to the absence of message authentication and the utilization of a hard-coded initialization vector, which exposes the protocol to ciphertext malleability attacks.\nAn attacker possessing low-privileged credentials and the ability to intercept CephX traffic can exploit the monitor as an encryption oracle to forge credentials for high-privilege entities, including Manager, MDS, and OSD services.\nAdditionally, the lack of integrity protection enables privilege escalation via bit-flipping attacks on service tickets, specifically targeting the allow_all boolean field.\nThe security implications are severe, as successful exploitation results in total compromise of the storage cluster's administrative control. Affected versions include all Ceph releases prior to 20.2.4 and 19.2.6. Remediation requires an immediate upgrade to the patched versions.",
  "technicalDetails": "The root cause of this vulnerability is the implementation of the CephX authentication protocol using AES-128-CBC in an unauthenticated mode. By failing to implement a Message Authentication Code (MAC) or authenticated encryption (AEAD), the protocol lacks integrity validation for the encrypted ticket structures.\nThe use of a hard-coded initialization vector (IV) in CBC mode significantly reduces the entropy of the encryption, facilitating deterministic ciphertext manipulation. Because the CBC mode is inherently malleable, an attacker capable of observing valid CephX traffic can alter the ciphertext blocks to produce predictable changes in the decrypted plaintext.\nThe exploitation flow leverages the Ceph monitor as an encryption oracle. Since the monitor performs encryption on attacker-supplied entity names, an adversary with low-privilege access can induce the monitor to encrypt specific data structures. By combining this oracle capability with the ability to splice ciphertext blocks, an attacker can construct valid, forged tickets that masquerade as highly privileged entities such as the Manager, MDS (Metadata Server), or OSD (Object Storage Daemon).\nFurthermore, the absence of integrity checks allows for surgical bit-flipping. By identifying the specific ciphertext block corresponding to the ticket's internal permission structure, an attacker can modify individual bits to toggle the 'allow_all' field to true. This effectively elevates a low-privilege key to an administrative 'allow_all' privilege level within the context of the service ticket, bypassing the intended authorization constraints of the Ceph cluster.\nThe scope of impact is cluster-wide; once a forged ticket or escalated key is obtained, the attacker can interact with the Ceph cluster services as if they possessed legitimate, high-level credentials. This permits unauthorized data access, metadata modification, and potential administrative manipulation of the distributed storage environment. The vulnerability persists in all versions prior to 20.2.4 and 19.2.6, necessitating a complete version transition to mitigate the systemic flaw in the authentication handshake."
}