The Ceph project published Tentacle 20.2.4 and Squid 19.2.6 to fix four security vulnerabilities affecting CephX, RADOS Gateway (RGW), and the cluster monitors. The project itself classifies these versions as hotfixes and recommends operators update as soon as possible. The mitigation doesn’t necessarily end with installing the new packages: one of the issues requires paying special attention to CephX key rotation.
Ceph vulnerabilities in 30 seconds
- The Ceph team has fixed four CVEs in Tentacle 20.2.4 and Squid 19.2.6.
- The broader issue affects CephX and may allow privilege escalation starting from certain low-level valid credentials.
- The fix introduces a new key type called
aes256k. - RGW also faces issues related to STS tokens and SigV4 signatures.
- Cephadm automates much of the service key rotation but generally does not manage client credentials.
Updating requires some planning because CVE-2025-30156 impacts older Ceph versions that use credentials with the aes key type. However, this does not mean any Ceph cluster is directly exploitable from the Internet: the scenario involves having a valid low-privilege CephX key and network access to the cluster.
Therefore, the practical urgency may vary greatly between environments under tight control by a single administrator and those where credentials are issued to clients, tenants, or less-trusted systems.
Four vulnerabilities and a major change in CephX
The update addresses four distinct issues.
| Vulnerability | Component | Main Issue |
|---|---|---|
| CVE-2025-30156 | CephX | Authentication bypass related to the use of AES-CBC |
| CVE-2026-39944 | RGW STS | Incorrect cryptographic validation of session tokens |
| CVE-2026-50152 | Ceph Monitor | Incorrect authorization in subscription handler |
| CVE-2026-54330 | RGW SigV4 | Incorrect verification of SigV4 signatures |
The vulnerability requiring the most significant change is CVE-2025-30156.
CephX is the authentication system used by Ceph to verify the identity of clients and cluster components. The project’s technical documentation explains that the previous scheme employs AES-128-CBC without authentication, lacks HMAC, and uses a fixed initialization vector (IV).
This combination could allow modifying certain encrypted data without detection. Under the conditions described, an attacker with a valid low-privilege CephX credential and network access could potentially forge credentials with different permission scopes, including administrative credentials.
The solution isn’t just about changing a few lines of code. Ceph introduces for the first time a new credential key type: aes256k.
This is based on AES256-CTS-HMAC-SHA384-192, a scheme outlined in RFC 8009 that incorporates message authentication and additional protections absent in the previous system. Fresh installations will use this secure key type, while existing ones will initially maintain compatibility with older credentials to allow gradual migration.
Updating Ceph isn’t enough: you must review the keys
One of the key points to consider before maintenance is that.
After installing the updates, you may see warnings and health errors related to old keys. Ceph indicates that during the process, six new health states are introduced specifically to detect configurations still using older mechanisms.
For example, AUTH_INSECURE_SERVICE_KEY_TYPE identifies service credentials still using insecure key types, while AUTH_INSECURE_CLIENT_KEY_TYPE flags similar issues with client credentials.
Therefore, seeing alerts after an update does not necessarily mean the upgrade failed. It could mean the cluster is detecting keys pending migration.
The exact procedure also depends on how Ceph is deployed.
Cephadm automates the rotation of service keys, but generally does not manage client credentials. Rook also automates part of the process, including rotation of some client keys, with specific exceptions.
Clusters installed via packages require a more manual and careful process. The official documentation describes a phased migration: enabling aes256k, setting it as the preferred encryption method, rotating service credentials, and then migrating compatible client keys.
The compatibility of these client keys warrants particular attention.
Ceph states that support for the new key type in the Linux kernel client began with Linux 7.0, though backports exist for CentOS Stream 9 and 10. Administrators should verify whether their distribution has incorporated support through its own packages before rotating kernel client keys.
This allows temporarily maintaining older keys when dealing with legacy systems, though security warnings will continue to appear.
RGW also requires attention
The other vulnerabilities make this update especially relevant for organizations using Ceph as an S3-compatible object storage platform.
CVE-2026-39944 affects RGW STS session tokens and shares some cryptographic aspects with the CephX issue.
In these cases, installing the update does not automatically fix everything. Operators should review existing tokens and complete their migration to the new cryptographic standard.
Additionally, CVE-2026-54330 relates to the verification of SigV4 signatures used by RGW. After the fix, RGW rejects SigV4 requests where the host and x-amz- headers are not correctly included in the signed set.
There is also a specific consideration for multisite deployments.
The REST client previously used in Ceph multisite could generate requests now rejected. Ceph recommends configuring rgw_sigv4_insecure=true temporarily before starting a multisite update, and setting it back to false after all clusters have been updated.
Finally, CVE-2026-50152 impacts the Monitor component and concerns authorization issues. The project recommends evaluating the potential exposure of stored secrets and, in cephadm-managed environments, rotating the SSH key used by this system. The full guide for rotating other secrets was still pending when the advisory was released.
All four issues were resolved on August 19, 2026, with Squid 19.2.6 and Tentacle 20.2.4. For older installations, the practical advice is to consider upgrading to a currently maintained branch rather than assuming all backports are available.
This change is also significant beyond these four CVEs. Introducing aes256k marks an unusual modification in such a core component as authentication credentials between Ceph components. Thus, maintenance should be viewed as a software update combined with credential migration, especially in large, multi-tenant, or externally connected clusters.
Frequently Asked Questions
Which Ceph versions fix these vulnerabilities?
The fixes are available in Ceph Tentacle 20.2.4 and Squid 19.2.6, released on August 19, 2026.
Is updating just the packages enough?
Not always. CVE-2025-30156 introduces the new aes256k key type, so existing installations need to review and rotate their CephX credentials following the project’s procedure.
Does Cephadm rotate all keys automatically?
No. Cephadm automates service key rotation during updates but generally does not manage client credentials. Rook also automates some client key rotations, with certain exceptions.
Can a Ceph cluster be directly attacked from the Internet via CVE-2025-30156?
The scenario described requires a valid low-privilege CephX key and network access to the cluster. Therefore, exposure is particularly relevant in environments where credentials are provided to users, tenants, or external systems.

