Ceph Security Update: Four CVEs and Key Rotation

On August 19, 2026, the Ceph project released two hotfix versions: Tentacle 20.2.4 and Squid 19.2.6. Both patch four CVEs in authentication and authorization code. Ceph asks all operators to upgrade as soon as possible.

That same month, French authorities disclosed several security incidents, including one at DGFiP involving data relating to 678,000 individuals and businesses. Some involved confirmed extraction. The scope of the France Titres and Education incidents was still under investigation when I wrote this. No source reviewed links Ceph or these CVEs to any of them. The comparison is operational context only: the release is a good moment to inspect identity, permissions, and detection on your own storage cluster.

Ceph security update at a glance

• Affected releases: Tentacle 20.2.4 and Squid 19.2.6 fix four authentication and authorization CVEs.
• Immediate action: Upgrade packages or container images, then plan the CephX key migration to aes256k. Package installation alone does not rotate every key.
• Operational dependencies: cephadm rotates daemon keys but not client keys. Rook automates some client rotations with exclusions. RGW multisite requires a coordinated upgrade sequence.
• Scope: The upstream sources reviewed do not report exploitation in the wild, and no reviewed source connects these CVEs to the French public-sector incidents below.

What the four CVEs are

All four advisories come from Ceph’s own documentation.

CVE-2025-30156: CephX authentication bypass. Legacy CephX aes keys use unauthenticated AES-128-CBC. The advisory says an attacker needs a compromised low-privilege key or a position from which to observe relevant CephX ciphertext. Under those conditions, the flaw can enable credential forgery and authentication bypass. The fix introduces a new aes256k key type based on AES256-CTS-HMAC-SHA384-192. Read the Ceph advisory for CVE-2025-30156.

That prerequisite matters. Installing new packages without rotating legacy keys is not the whole remediation.

CVE-2026-39944: RGW STS token escalation. STS session tokens share the same AES-CBC root cause. Someone holding a valid unprivileged STS token can alter protected fields and escalate to RGW admin access. Read the Ceph advisory for CVE-2026-39944.

CVE-2026-50152: Monitor config-key store exposure. A CephX identity with only mon allow r could read the entire Monitor config-key store, which may hold secrets. Read the Ceph advisory for CVE-2026-50152.

CVE-2026-54330: RGW SigV4 verification flaw. A holder of a presigned PUT URL could add unsigned x-amz-* headers and gain capabilities beyond the signer’s intent. Patched RGW rejects such headers when they are absent from the signed subset. Read the Ceph advisory for CVE-2026-54330.

Two points stand out. First, all four flaws concern authentication, signature verification, or authorization. None concerns data-path performance or replication correctness. Second, the advisory for CVE-2025-30156 documents a researcher proof of concept. That is not evidence of exploitation in the wild, and the upstream sources reviewed do not report any.

The upgrade is not a one-line command

Read the upgrade guidance before scheduling anything. The announcement and documentation specify several steps:

• Review the new CephX key-upgrade and rotation procedure first.
• cephadm automates daemon-key rotation but not client keys. Its post-upgrade rotation of OSD and MDS keys can extend the maintenance window.
• Rook automates some client-key rotation, with exclusions. Check them before you start.
• Client and kernel upgrades are recommended for aes256k support. Upstream Linux support began in kernel 7.0 and was backported to CentOS Stream 9 and 10. For other distributions, verify support with your vendor.
• Expect six new authentication-related health warnings and errors during migration. Ceph says this is normal, but operators must address them as keys are upgraded and rotated.
• Running RGW multisite? Set rgw_sigv4_insecure=true before upgrading. Restore it to false only after every cluster in the federation is patched.
• For CVE-2026-50152, cephadm users should rotate the cephadm SSH key. Guidance for rotating other config-key secrets is still forthcoming upstream.

Sources: the Ceph release announcement and the cephadm SSH configuration guidance.

What the Ceph users thread adds

The Ceph users mailing-list archive for this urgent release documents the operational questions that emerge after a test upgrade. Treat it as field experience and maintainer clarification. The maintained Ceph documentation remains the authority when it differs.

Inventory shared client identities before the maintenance window

Patrick Donnelly clarified that one Ceph client identity cannot hold both aes and aes256k keys at the same time. That makes a shared client.libvirt or application key a migration constraint. For gradual replacement, create a distinct client identity and key for each node or workload, distribute it to the replacement node, test it, then retire the old shared identity only after its consumers have moved. Do the identity inventory before changing the default cipher.

Make a worklist for daemons that cephadm does not rotate

cephadm rotates the mgr, mon, osd, and mds keyrings during its upgrade path. The thread records a maintainer workaround for other cephadm-managed daemons: rotate the entity with ceph auth rotate <entity-name> --key-type aes256k, then redeploy the daemon with ceph orch daemon redeploy <daemon-name>. The convenience command ceph orch daemon rotate-key was temporarily removed in these releases. Verify the current command set against your exact Ceph version before executing it. NFS exports can have separate keyrings and may need a rotation and reapply cycle, so test their availability impact first.

Read the authentication health warnings by what they measure

AUTH_INSECURE_SERVICE_KEY_TYPE means a service such as an OSD is still authenticating to the Monitors with an aes key. It clears when that service key is rotated. AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE is different: it concerns rotating service keys, and the thread explains that setting auth_service_cipher to aes256k addresses it. Wiping the rotating key database is optional, not a substitute for rotating the service identities.

Treat RBD and virtualization as an application migration

For RBD clients behind hypervisor or cloud orchestration, a key rollover can touch libvirt secrets, VM templates, live migration, and the control plane. Community replies show that these details vary by platform. Do not assume that replacing a secret changes the Ceph username consumed by every running workload. Build a node-by-node cutover plan, test a representative migration or restart path, and keep a rollback credential until the new identity works in production.

Plan the maintenance window around key rotation and client compatibility, not package installation alone. Upstream warns that automated OSD and MDS rotation can extend the upgrade.

The same month: French public-sector disclosures

While Ceph shipped these fixes, French authorities disclosed several security incidents. I list them as operational context, not because any involves Ceph. No source reviewed connects Ceph, or any of these four CVEs, to an incident below.

DGFiP, the French tax administration. Intrusions in June and July 2026 used stolen credentials from an agent and an authorized third party. Data relating to 678,000 individuals and businesses was consulted and extracted. DGFiP states that taxpayer portals and passwords were not compromised. Read the Finance Ministry press release and the DGFiP notice.

FICOBA, the national bank-account register. In early 2026, impersonation of an authorized official’s credentials allowed unauthorized queries exposing information on roughly 1.2 million bank accounts. The accounts themselves were not accessed. Read the DGFiP FICOBA notice.

France Titres / ANTS. A serious incident potentially involved up to 11.7 million portal accounts. The Interior Ministry says it detected the incident on April 15, 2026. Read the Interior Ministry update.

Ministry of Education. The ministry confirmed an intrusion on July 25, 2026, with possible exfiltration of personnel data. The scope was still under investigation. Headline claims circulating online remained unverified. Read the Education Ministry notice.

DGFiP and FICOBA specifically involved stolen or impersonated credentials. The official France Titres and Education notices cited here do not establish the same attack vector. Together, these incidents motivate identity, least-privilege, and detection controls, but they do not prove one common failure pattern. None of the reviewed official notices attributes an incident to a storage-layer vulnerability.

For scale, ANSSI handled 3,586 security events in 2025. CNIL received 6,167 breach notifications that year, half involving hacking.

What this means for your storage platform

A patch release fixes four bugs. It does not make a platform resilient by itself. The Ceph upgrade remediates four specific vulnerabilities, but it is not a substitute for key management, least privilege, monitoring, tested recovery, and incident response. If you operate Ceph, MinIO, or another S3-compatible store, use this checklist:

1. Identity first. Rotate keys and credentials on a schedule. Scope every CephX identity and every RGW or S3 credential to the minimum capability. An identity with mon allow r should never be able to read your secret store.
2. Patch discipline. Track upstream security releases for your storage layer as closely as kernel CVEs. This release requires planning, so budget the window now.
3. Tested backups. An untested backup is not evidence of recoverability. Measure restore throughput and validate recovery ordering. Replication is not a backup because deletes and corruption propagate.
4. Least privilege at every boundary. Presigned URLs, STS tokens, and service accounts each delegate trust. Use short expiries where supported for delegated credentials. Define scope and rotation for service accounts.
5. Monitoring for anomalous access. Look for mass metadata reads, unusual token use, and queries outside normal business patterns. The disclosed record counts show why early detection matters, but the cited notices do not quantify how detection delay affected their scope.
6. Incident readiness. Decide who rotates each credential, who assesses notification duties and contacts CNIL when required, and who can take systems offline. DGFiP’s disclosures show why the response plan matters once access occurs.

Where to start

If you run Ceph in production, read the release announcement today and schedule the upgrade with the key-rotation steps included.

Then assess the surrounding controls. My Resilience and Disaster Recovery Assessment reviews measured restores, replication behavior, access controls, and your actual RTO and RPO. Book a free 15-minute introductory call to see whether it fits your platform.