Ceph patches four CVEs: the package closes three, the fourth is on you

Yesterday, Wednesday, the Ceph project shipped two releases under a headline you do not see every year: "[CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released". Four CVEs at once. And, in the critical-steps section, one sentence that rewrites a lot of people's week: CephX is getting a new key type. It is the first time that has ever happened.

The project's advice is the usual one, and it is right: "We strongly recommend that all Ceph operators upgrade to one of these releases as soon as possible." But it is worth reading what comes next, because three of the four flaws go away with the package and one does not. The fourth goes away once somebody has rotated, one by one, every key in the cluster. That does not fit in a half-hour maintenance window.

The four, in one table

All four are listed as High in the project's own vulnerability index, and all four open the same way under affected versions: all prior versions. No old branch is spared. It is worth looking underneath that label, because the per-dimension CVSS breakdown on each page does not match: all four are High on confidentiality, but only two are also High on integrity. And the two RGW ones only touch you if you run an S3 gateway.

A read-only key and the entire keyring

CVE-2026-50152 is the uncomfortable one. Ceph's own description leaves no room for interpretation: "Any CephX user holding mon allow r caps can read the entire Monitor config-key store by sending a single crafted MMonSubscribe message." One message. No extra conditions.

The interesting part is what lives in there, and the page says that too: "This includes OSD LUKS passphrases and, on cephadm-managed clusters, the SSH private key cephadm uses to authenticate on every Ceph host." The impact breakdown finishes the thought: "An attacker can exfiltrate the entire cluster secret store, including dm-crypt keys, dashboard secrets, and gateway credentials."

The next bit is our reading, but it is not much of a stretch: mon allow r is the floor for any client credential. Every node that maps an RBD has it, and so does every CephFS client. If you encrypted your OSDs at rest — which is what gets asked for as soon as sensitive data is involved — the passphrase that opens those disks was sitting in the same store that client could read in one go, so the disk stayed encrypted while the key was in plain view of half the cluster.

The package closes the read. What the package cannot do is change the secrets that have been sitting there since you built the cluster. And here Ceph is honest to the point of being unsettling: "Formal guidance on rotating all secrets stored in the Monitor config-key store will be forthcoming." For now there is an established procedure for exactly one of them, the cephadm SSH key. For the rest, the literal advice is that each operator "assess their cluster's potential exposure".

The CephX one repeats a 2004 mistake

CVE-2025-30156 is the big one, and its diagnosis reads almost like a confession: "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 identically, which is already ugly. The missing authentication is the serious part: you can flip bits in the ciphertext, change what sits underneath, and nothing notices.

There is a long path, cryptographically entertaining, where the attacker acts as an encryption oracle by creating specially named identities to harvest the right ciphertext blocks. And there is a short path, which is the frightening one: "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." David Mohren, of CLYSO, has a demonstrated proof of concept that reaches cluster admin.

The fix is called aes256k: AES256-CTS-HMAC-SHA384-192, the RFC 8009 scheme Kerberos 5 uses. A random 128-bit confounder per operation, HMAC-SHA384 to catch tampering, and ciphertext stealing so no padding is needed. The credits list is worth a line too: it was reported by Erin Shepherd of e43.eu, then independently by David Mohren and Mark Nelson of CLYSO; and also reported and validated by David Korczynski of Ada Logics, because it was found by Anthropic "using agents to study the security of open-source projects".

Why installing is not enough for this one

Because the keys you already have are still of type aes. The new binary understands the new type, but it does not rewrite your credentials: it keeps backward compatibility on purpose so the cluster does not fall over during the upgrade. What it does is start complaining, with six new health checks the documentation warns you to expect: AUTH_INSECURE_KEYS_CREATABLE, AUTH_INSECURE_KEYS_ALLOWED, AUTH_INSECURE_SERVICE_KEY_TYPE, AUTH_INSECURE_SERVICE_TICKETS, AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE and AUTH_INSECURE_CLIENT_KEY_TYPE.

Two of those six are not warnings, they are errors. ceph health detail prints them with [ERR]: AUTH_INSECURE_SERVICE_TICKETS and AUTH_INSECURE_SERVICE_KEY_TYPE. Translated into what your monitoring sees: the cluster sits in HEALTH_ERR from the moment you upgrade until you finish rotating, which can be weeks. Worth knowing before the phone rings at three in the morning, and worth telling whoever is on call.

Ten steps, and the order matters

The procedure Ceph added to the CephX configuration reference has ten numbered steps. One of them, the sixth, comes with the documentation itself advising against it for most deployments. Here is the summary, with the commands that matter:

1. Allow the new type. On upgraded clusters the monitors do this on their own; check the auth_allowed_ciphers field in the output of ceph mon dump, where aes,aes256k should appear.
2. Change the default type for new keys: ceph mon set auth_preferred_cipher aes256k. You may skip this on purpose if you still have client applications that cannot handle it.
3. Rotate every daemon key: mon. first, then mgr, osd and mds, one by one, stopping the daemon first. Keep the mon.keyring the first command prints: if a monitor was out of quorum during the rotation, it will not have the new key and you will have to place it by hand.
4. Confirm the warning is gone: ceph health detail should no longer list AUTH_INSECURE_SERVICE_KEY_TYPE. If it still does, some daemon has not been rotated.
5. Upgrade the cipher for rotating service tickets: ceph mon set auth_service_cipher aes256k.
6. Wipe the old rotating tickets with ceph auth wipe-rotating-service-keys. Here the documentation literally says "This is not recommended for most deployments": better to let them expire on their own within hours.
7. Stop new insecure keys from being created: ceph config set mon 'mon auth allow insecure key' false.
8. Rotate client.admin. First create a rescue key (client.admin-backup) and check it works. Get this wrong without a net and recovery is long and ugly.
9. Rotate the remaining client keys, and copy each one to every machine that uses it. ceph health detail lists them by name.
10. Ban the old type: ceph mon set auth_allowed_ciphers aes256k. And here comes the document's sternest warning: do this with a single unrotated key still out there and you lock yourself out, with recovery through "Emergency Allowed Ciphers".

There is an escape valve acknowledged in the documentation itself, and it is good that it exists: if you cannot rotate a particular client key yet, you can mute the warning with ceph health mute AUTH_INSECURE_CLIENT_KEY_TYPE 8w. Eight weeks. The line next to the command reads "We expect this to be typical situation for some clusters", which is an elegant way of admitting this will take months on large installations.

We went and looked at Proxmox's repository

A good share of the Ceph clusters we see in Spain are installed by Proxmox VE, from the repositories Proxmox maintains. So this afternoon, before writing anything, we went to see what is actually published there. The command fits on one line:

curl -s http://download.proxmox.com/debian/ceph-squid/dists/trixie/\
no-subscription/binary-amd64/Packages.gz | gunzip \
  | awk '/^Package: ceph-common$/{p=1} p&&/^Version:/{print;p=0}'

The latest version it returns, today 20 August at 13:40, is 19.2.5-pve2. On the Tentacle branch, 20.2.2-pve1. On bookworm, for anyone still on Proxmox VE 8, 19.2.5-1~bpo12+2. Those indexes have not been touched since 27 July (Squid on trixie), 29 July (Squid on bookworm) and 7 July (Tentacle). None of the patched releases is there.

This is not a complaint: packaging a Ceph release with the care Proxmox puts into it takes time, and the advisory is less than twenty-four hours old. It is a fact that changes this week's plan, because if your Ceph is installed by Proxmox there is nothing to install today and quite a lot to prepare. And because it pays to have the reflex of checking the repository rather than trusting that an apt upgrade brings what you think it brings — it is the same reflex you need with end-of-support dates.

There is a second consequence, and this is the one with weight. Ceph's note says "deployments using cephadm will automate the process except for client keys". Proxmox manages the Ceph daemons itself, without cephadm. The automation, which on cephadm covers everything except client keys, is simply not there: on a Proxmox hyperconverged cluster the rotation is manual, all of it, monitor by monitor and OSD by OSD.

The kernel, which for once helps

The kernel Ceph client — the one krbd and CephFS mounts use — also has to understand aes256k, though Ceph qualifies that client and kernel upgrades "are recommended to support the new key type but not required to resolve the most serious aspects of the security vulnerability". On which kernel you need, it is specific: "Linux kernel support began in 7.0 and has been backported to CentOS Stream 9 and 10." Proxmox VE 9 runs the 7.0 series: today, in pve-no-subscription, the package is proxmox-kernel-7.0 at version 7.0.14-12, and it is the one proxmox-default-kernel pulls in. Proxmox VE 8 is still on proxmox-kernel-6.8.

That the series is the right one does not guarantee Proxmox's particular build carries the support, and that will have to be checked when the packages land; we say so because we have not verified it. What is certain is the other direction, and it is the one that breaks things: on a node running kernel 6.8, a client. key rotated to aes256k and used to map an RBD stops authenticating with the monitors. The order there is kernel first, key second. And in the meantime, the eight-week mute.

The two RGW ones, and the multisite trap

CVE-2026-54330 is simple to tell: RGW's SigV4 verifier only checked the headers listed in X-Amz-SignedHeaders and ignored the rest. With a presigned PUT URL in hand — the kind you hand out so someone can upload a file — you could hang x-amz-* headers on it that the signer never authorised. ACLs included. The patch rejects those requests.

CVE-2026-39944 is the CephX one's sibling: same root cause, different place. RGW's STS session tokens are encrypted with the same unauthenticated AES-CBC, so anyone holding a valid token can flip the acct_type and is_admin fields undetected and come out with gateway admin rights. It only affects you if STS is enabled (rgw_s3_auth_use_sts = true), which is normal if you hand temporary credentials to applications.

And here is the detail to write into the ticket: the REST client RGW multisite itself uses was generating exactly those requests. Ceph puts it plainly: "If you are running multisite, you must set the rgw_sigv4_insecure option to true before you begin to upgrade. After all clusters are upgraded, set the option to false again." Which means: to apply the patch you have to flip a switch that leaves the flaw open, and remember to flip it back once every zone is current. That "remember" is what gets lost. Write it down, with a date and an owner.

What we would do this week

• Inventory before patch. ceph auth ls, and count how many credentials carry mon allow r and who owns them. That number is the real size of step 9.
• Look at what is in the store. ceph config-key ls. If dm-crypt entries show up, you already know which secrets need a rotation plan, even if the formal procedure does not exist yet.
• If it is cephadm, rotate the SSH key now. It does not depend on the patch, and it is the one that grants root on every node.
• If it is Proxmox, prepare the window. With ten manual steps, a three-node cluster is not a quiet afternoon. And since you are stopping every OSD anyway, it is a good moment to check what each disk is really delivering.
• Do not roll out Tentacle at the same time. If you were thinking of jumping branches, split it up: patch where you are first. We already wrote here about what Tentacle brings and what it brings switched off, and none of those features deserves to be mixed into a key rotation.

The advisory asks you to upgrade as soon as possible, and it is right to. The next line is the one that changes your calendar: three of the four flaws leave with the package, and the fourth leaves the day you change the last key in the cluster. What sits between those two dates is a small project, with its window, its way back, and an emergency key stored somewhere you will not wipe.

Sources (verified on 20 August 2026): the advisory title, the 19 August date, the sentence about upgrading, the critical upgrade steps, the cephadm and Rook automation, the six new health warnings and the rgw_sigv4_insecure instruction for multisite, from the Squid 19.2.6 and Tentacle 20.2.4 announcement by Patrick Donnelly. The descriptions, impact breakdowns, affected and fixed versions, credits and verbatim quotes, from the CVE-2025-30156, CVE-2026-50152, CVE-2026-39944 and CVE-2026-54330 pages in Ceph's security documentation. The ten steps, the commands, the warnings and the eight-week mute line, from the CephX configuration reference, section "Upgrading and Rotating CephX Keys". The names of the six health checks, and the fact that two of them print with [ERR], from the health checks page. The High severity of all four, from Ceph's vulnerability index. Ours: the queries against Proxmox's public repositories (ceph-squid and ceph-tentacle for trixie and bookworm, and pve-no-subscription for the kernels), run today at 13:40 with the command shown in the text; the command is reproducible and returns the same answer from anywhere. Ours too is the reading about the reach of mon allow r on RBD and CephFS clients, declared as a reading in the text. Ceph quotes are left in English, their original language, so they can be verified word for word.