CVE-2025-30156: AES-CBC misuse in CephX facilitating authentication bypass

Summary

CVE-2025-30156 is an authentication bypass in Ceph’s CephX implementation.

Patches are available in Tentacle 20.2.4 and Squid 19.2.6.

Background

CephX’s AES-128-CBC encryption is unauthenticated. It has no HMAC, and it uses a hard-coded initialization vector. This is the same weakness MIT documented in Kerberos 4 in the 2004 PERILS paper. The fixed IV means identical plaintexts encrypt to identical ciphertexts, which reveals when two encrypted values are equal. The missing authentication is worse. An attacker can flip bits in the ciphertext, change the underlying data, and nothing catches it.

That opens the door to credential forgery. The attacker needs one compromised low-privilege key, such as a client credential, or a position from which to observe CephX ciphertext on the network. From there, the attacker may manipulate the encrypted service tickets from the Montior. A proof of concept exploit by David Mohren of CLYSO has been demonstrated to leverage this vulnerability to gain administrative access to the cluster.

CVSS breakdown

Confidentiality: High. An attacker can decrypt or enumerate credential content.
Integrity: High. An attacker can rewrite credentials and impersonate any cluster identity.
Availability: Partial. An attacker can manipulate the cluster with forged MGR credentials, and forged OSD credentials let an attacker corrupt data.
Access Complexity: Low. There is an attack vector where one can simply perform a CBC bitflip on the allow_all field of the encrypted AuthTicket structure, gaining admin privileges for the OSD, MDS, and MGR services. The traditional attack is cryptographically non-trivial, but it is deterministic and well known. The attacker must act as an encryption oracle, crafting specially named entity identities and collecting the right ciphertext blocks, splicing them into forged credentials with correct block alignment.
Authentication: Yes. An attacker must have a valid low-privilege CephX key and access to the Ceph cluster network.
Gained Access: Yes. An attacker can forge credentials with a changed scope, including admin credentials.

Affected versions

All prior versions of Ceph and any credential using the aes key type.

Fixed versions

Tentacle 20.2.4 (and later)
Squid 19.2.6 (and later)

Fix Details

The patch introduces AES256-CTS-HMAC-SHA384-192, a cryptographically secure key type based on RFC 8009 (Kerberos 5 standard). A 128-bit random confounder is generated per encryption operation, ensuring identical plaintexts produce sufficiently random ciphertext. HMAC-SHA384 provides message authentication, detecting tampering and preventing bit-flipping attacks. Cipher text stealing eliminates padding, preventing padding oracle attacks. Key usage numbers ensure proper key separation across encryption contexts.

After upgrading, the system detects legacy insecure keys and displays health warnings. Fresh installations use the secure key type automatically. Existing deployments continue functioning but receive migration prompts, maintaining backward compatibility. All Ceph daemon packages/containers must be upgraded. Client/kernel upgrades are recommended to support the new key type but not required to resolve the most serious aspects of the security vulnerability. Linux kernel support began in 7.0 and has been backported to CentOS Stream 9 and 10. Check your kernel provider for any backports that may be available.

Recommendations

Users should upgrade immediately. Follow the recommendations of your product distributor or deployment tool.

Critical Upgrade Steps

The fix for CVE-2025-30156 introduces a new CephX key type, aes256k. This is the first time Ceph has introduced a new key type for CephX credentials. Therefore, a new procedure exists for upgrading and rotating Ceph daemon keys as part of this CVE. Before upgrading a Ceph cluster, the operator should familiarize themselves with the procedure documented at Upgrading and Rotating CephX Keys.

These steps are for package-based deployments of Ceph. In other sections, the document also includes new information about key rotation procedures, monitor authentication controls, and emergency recovery procedures.

Deployments using cephadm will automate the process except for client keys. Deployments using Rook will also automate rotation of some client keys with some exclusions. Look to the Rook project’s announcement for more details.

As part of upgrading a Ceph cluster, six new health warnings and errors will be generated. This is normal. As part of the process to upgrade/rotate entity keys, you will address the warnings and errors as you go. These are documented beginning at AUTH_INSECURE_KEYS_CREATABLE.

Improvements to the architectural documentation for CephX have been made at High Availability Authentication.

Credits

This vulnerability was reported by Erin Shepherd of e43.eu and later independently by David Mohren and Mark Nelson of CLYSO. It was also reported and validated by David Korczynski of Ada Logics, as it was found by Anthropic using agents to study the security of open-source projects.

Brought to you by the Ceph Foundation

The Ceph Documentation is a community resource funded and hosted by the non-profit Ceph Foundation. If you would like to support this and our other efforts, please consider joining now.