The Ceph project has published Tentacle 20.2.4 and Squid 19.2.6 to fix four security vulnerabilities in CephX, the RADOS Gateway (RGW), and the cluster monitors. Ceph itself labels these releases as hotfixes and tells operators to update as soon as they can. Installing the new packages isn’t the whole job: one of the flaws also calls for careful CephX key rotation.
Ceph vulnerabilities in 30 seconds
- Ceph fixed four CVEs in Tentacle 20.2.4 and Squid 19.2.6.
- The biggest one affects CephX and can allow privilege escalation from certain valid low-level credentials.
- The fix adds a new key type called
aes256k. - RGW also has problems tied to STS tokens and SigV4 signatures.
- Cephadm automates most service-key rotation but usually doesn’t manage client credentials.
Planning matters here, because CVE-2025-30156 hits older Ceph versions that use credentials with the aes key type. That doesn’t mean any Ceph cluster is exploitable straight from the internet: the attack needs a valid low-privilege CephX key and network access to the cluster.
So the real urgency swings a lot between a cluster locked down by a single administrator and one that hands credentials to clients, tenants, or systems you trust less.
Four vulnerabilities and a big change in CephX
The update covers four separate 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 the subscription handler |
| CVE-2026-54330 | RGW SigV4 | Incorrect verification of SigV4 signatures |
The one that forces the biggest change is CVE-2025-30156.
CephX is the authentication system Ceph uses to check the identity of clients and cluster components. The project’s docs explain that the old scheme uses AES-128-CBC without authentication, has no HMAC, and relies on a fixed initialization vector (IV).
That mix could let someone alter certain encrypted data without being caught. Under the conditions described, an attacker with a valid low-privilege CephX credential and network access could forge credentials with different permission scopes, including administrative ones.
The fix goes beyond a few lines of code. For the first time, Ceph adds a new credential key type: aes256k.
It is based on AES256-CTS-HMAC-SHA384-192, a scheme from RFC 8009 that adds message authentication and other protections the old system lacked. Fresh installs use this secure key type, while existing ones keep working with older credentials at first so you can migrate gradually.
Updating Ceph isn’t enough: check the keys
One point deserves attention before you schedule maintenance.
After the updates land, you may see warnings and health errors about old keys. Ceph adds six new health states during the process, specifically to spot configurations still on the older mechanisms.
For instance, AUTH_INSECURE_SERVICE_KEY_TYPE flags service credentials still using insecure key types, and AUTH_INSECURE_CLIENT_KEY_TYPE does the same for client credentials.
So alerts after an update don’t necessarily mean it failed. They can just mean the cluster is spotting keys that still need migrating.
The exact steps depend on how you deployed Ceph.
Cephadm automates service-key rotation but usually leaves client credentials alone. Rook automates part of the process too, including rotation of some client keys, with specific exceptions.
Clusters installed from packages need a more manual, careful process. The official docs lay out a phased migration: enable aes256k, set it as the preferred encryption method, rotate service credentials, then migrate compatible client keys.
Client-key compatibility is worth a closer look.
Ceph says support for the new key type in the Linux kernel client arrived with Linux 7.0, though backports exist for CentOS Stream 9 and 10. Check whether your distribution has added support in its own packages before you rotate kernel-client keys.
That lets you keep older keys for a while on legacy systems, though the security warnings will keep showing up.
RGW needs attention too
The other flaws make this update especially relevant if you run Ceph as S3-compatible object storage.
CVE-2026-39944 affects RGW STS session tokens and shares some cryptography with the CephX issue.
Here too, installing the update doesn’t fix everything on its own. Operators should review existing tokens and finish migrating them to the new cryptographic standard.
CVE-2026-54330 concerns how RGW verifies SigV4 signatures. After the fix, RGW rejects SigV4 requests where the host and x-amz- headers aren’t correctly part of the signed set.
There is a specific note for multisite deployments.
The REST client Ceph multisite used before could produce requests that now get rejected. Ceph suggests setting rgw_sigv4_insecure=true temporarily before you start a multisite update, then switching it back to false once every cluster is updated.
Finally, CVE-2026-50152 hits the Monitor component and involves authorization. The project recommends checking whether stored secrets are exposed and, in cephadm-managed setups, rotating the SSH key this system uses. The full guide for rotating other secrets was still pending when the advisory came out.
All four issues were resolved on August 19, 2026, in Squid 19.2.6 and Tentacle 20.2.4. For older installations, the practical move is to upgrade to a currently maintained branch rather than assume every backport is available.
The change reaches past these four CVEs. Adding aes256k is an unusual edit to something as core as the authentication credentials between Ceph components. Treat the maintenance as a software update plus a credential migration, especially on large, multi-tenant, or externally connected clusters.
Frequently Asked Questions
Which Ceph versions fix these vulnerabilities?
The fixes are 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 usually doesn’t manage client credentials. Rook also automates some client-key rotations, with certain exceptions.
Can a Ceph cluster be attacked directly from the internet via CVE-2025-30156?
The scenario described needs a valid low-privilege CephX key and network access to the cluster. So the exposure matters most where credentials go out to users, tenants, or external systems.
