- ceph-users - lists.ceph.io

Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
by Patrick Donnelly 21 Aug '26

21 Aug '26

On Thu, Aug 20, 2026 at 3:51 PM Salatiel Filho <ceph-users(a)ceph.io> wrote: > entity client.bootstrap-mds using insecure key type: aes > entity client.bootstrap-mgr using insecure key type: aes > entity client.bootstrap-osd using insecure key type: aes > entity client.bootstrap-rbd using insecure key type: aes > entity client.bootstrap-rbd-mirror using insecure key type: aes > entity client.bootstrap-rgw using insecure key type: aes Bootstrap keys should be safe to delete. -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D

1 0

Re: Question on so-called tenant level roles in tentacle
by Manuel Rios - EDH 21 Aug '26

21 Aug '26

I don’t know how this patch become online without an auto-rotation... -----Mensaje original----- De: Casey Bodley <ceph-users(a)ceph.io> Enviado el: Thursday, August 20, 2026 7:15 PM Para: Christopher Durham <caduceus42(a)aol.com> CC: ceph-users(a)ceph.io Asunto: [ceph-users] Re: Question on so-called tenant level roles in tentacle On Wed, Aug 19, 2026 at 5:20 PM Christopher Durham <ceph-users(a)ceph.io> wrote: > > > The release notes for ceph tentacle, at: > https://docs.ceph.com/en/latest/releases/tentacle/ > state the following > "RGW: The User Account feature introduced in Squid provides first-class support for IAM APIs and policy. Our preliminary STS support was based on tenants, and exposed some IAM APIs to admins only. This tenant-level IAM functionality is now deprecated in favor of accounts. While we’ll continue to support the tenant feature itself for namespace isolation, the following features will be removed no sooner than the V release: Tenant-level IAM APIs including CreateRole, PutRolePolicy and PutUserPolicy, Use of tenant names instead of accounts in IAM policy documents, Interpretation of IAM policy without cross-account policy evaluation, S3 API support for cross-tenant names such as Bucket=’tenant:bucketname’ STS Lite and sts:GetSessionToken." > > Does the 'V' release mean the Vampire release? Does this statement mean that those API calls will be available in all tentacle releases and umbrella, but maybe not vampire? that's right, Chris > I need to have the CreateRole,PutRolePolicy et al available in tentacle and do a planned transition to IAM users/roles. Any documentation on how to do this? I have STS roles for various groups of users to gain temporary access to solme number of buckets and I want to be sure my upgrade to tentacle will be ok. (I am on 19.2.5 squid). We are not using tenants but buckets owned by various s3 users and roles to give temporary access to buckets by other users. We have been doing this since either nautilus or octopus and it has worked well for us. (We do not use the gui for role management but have our own python scripts to add users/buckets to roles). https://docs.ceph.com/en/squid/radosgw/account/#migrate-an-existing-user-in… shows how to migrate existing users into an account, but not how to migrate existing roles. you'll need to create new roles in accounts and delete the old ones because the initial sts implementation treated the tenant like an account, the most direct mapping would be to create one account per tenant (in your case just the global/unnamed tenant) and migrate all of that tenant's users into it. you could then recreate the roles in that account, with role policy that names the same buckets and user principals. however, all buckets would be owned by the account and no users would have any access by default. so you'd have to use iam policy to control all permissions, not just to facilitate sharing between users/buckets if there are distinct groups of ownership/sharing, it would make more sense to create separate accounts for each. users within each account could be granted direct access to that account's buckets, and account roles could be used to share access to some of those buckets with other trusted accounts/users. you'd also have the option to give the account root user's credentials to someone in that group so they could use the iam apis to manage the sharing of their own resources. it's this self-service aspect of accounts that most differentiates it from the tenant-level sts support, which was an admin-only feature if you do decide to put all of the users in a single account, you might consider using iam groups rather than roles. you could use group policy to grant access to specific buckets in the account, then manage group membership with iam:AddUserToGroup/RemoveUserFromGroup. this would avoid the need for role trust policy to name all of the individual users, and those users wouldn't need to go through AssumeRole for that shared access > -Chris > > > > > > > > > > > > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an > email to ceph-users-leave(a)ceph.io > _______________________________________________ ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: Question on so-called tenant level roles in tentacle
by Casey Bodley 21 Aug '26

21 Aug '26

On Wed, Aug 19, 2026 at 5:20 PM Christopher Durham <ceph-users(a)ceph.io> wrote: > > > The release notes for ceph tentacle, at: > https://docs.ceph.com/en/latest/releases/tentacle/ > state the following > "RGW: The User Account feature introduced in Squid provides first-class support for IAM APIs and policy. Our preliminary STS support was based on tenants, and exposed some IAM APIs to admins only. This tenant-level IAM functionality is now deprecated in favor of accounts. While we’ll continue to support the tenant feature itself for namespace isolation, the following features will be removed no sooner than the V release: Tenant-level IAM APIs including CreateRole, PutRolePolicy and PutUserPolicy, Use of tenant names instead of accounts in IAM policy documents, Interpretation of IAM policy without cross-account policy evaluation, S3 API support for cross-tenant names such as Bucket=’tenant:bucketname’ STS Lite and sts:GetSessionToken." > > Does the 'V' release mean the Vampire release? Does this statement mean that those API calls will be available in all tentacle releases and umbrella, but maybe not vampire? that's right, Chris > I need to have the CreateRole,PutRolePolicy et al available in tentacle and do a planned transition to IAM users/roles. Any documentation on how to do this? I have STS roles for various groups of users to gain temporary access to solme number of buckets and I want to be sure my upgrade to tentacle will be ok. (I am on 19.2.5 squid). We are not using tenants but buckets owned by various s3 users and roles to give temporary access to buckets by other users. We have been doing this since either nautilus or octopus and it has worked well for us. (We do not use the gui for role management but have our own python scripts to add users/buckets to roles). https://docs.ceph.com/en/squid/radosgw/account/#migrate-an-existing-user-in… shows how to migrate existing users into an account, but not how to migrate existing roles. you'll need to create new roles in accounts and delete the old ones because the initial sts implementation treated the tenant like an account, the most direct mapping would be to create one account per tenant (in your case just the global/unnamed tenant) and migrate all of that tenant's users into it. you could then recreate the roles in that account, with role policy that names the same buckets and user principals. however, all buckets would be owned by the account and no users would have any access by default. so you'd have to use iam policy to control all permissions, not just to facilitate sharing between users/buckets if there are distinct groups of ownership/sharing, it would make more sense to create separate accounts for each. users within each account could be granted direct access to that account's buckets, and account roles could be used to share access to some of those buckets with other trusted accounts/users. you'd also have the option to give the account root user's credentials to someone in that group so they could use the iam apis to manage the sharing of their own resources. it's this self-service aspect of accounts that most differentiates it from the tenant-level sts support, which was an admin-only feature if you do decide to put all of the users in a single account, you might consider using iam groups rather than roles. you could use group policy to grant access to specific buckets in the account, then manage group membership with iam:AddUserToGroup/RemoveUserFromGroup. this would avoid the need for role trust policy to name all of the individual users, and those users wouldn't need to go through AssumeRole for that shared access > -Chris > > > > > > > > > > > > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io >

2 1

Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
by Salatiel Filho 21 Aug '26

21 Aug '26

Hi, I also miss in the docs the steps for those clients that are not daemons? ( cephadm managed ) entity client.admin using insecure key type: aes entity client.bootstrap-mds using insecure key type: aes entity client.bootstrap-mgr using insecure key type: aes entity client.bootstrap-osd using insecure key type: aes entity client.bootstrap-rbd using insecure key type: aes entity client.bootstrap-rbd-mirror using insecure key type: aes entity client.bootstrap-rgw using insecure key type: aes Atenciosamente/Kind regards, Salatiel On Thu, Aug 20, 2026 at 11:00 AM Pedro Macedo <ceph-users(a)ceph.io> wrote: > > Gotcha; in that case, sounds like the documentation and/or the > CVE-related docs should be updated to reflect these changes and steps > related to non- mgr/mon/osd/mds daemons. > > On 2026-08-20 3:43 PM, Adam King wrote: > > That command got removed for the time being as it used an old way of doing > > the key rotation that wasn't built to work with the changes for the cve and > > seemed to be broken for a number of daemon types. Since the name would make > > people want to use it it was decided to just temporarily disables it so we > > can fix it and reintroduce it in a new version as an easier way to rotate > > the keys. For any keys tied to a cephadm deployed daemon that aren't > > automatically rotated (cephadm handles mgr, mon, osd, and mds keyrings > > during upgrade) it's a matter of `ceph auth rotate <entity-name> --key-type > > aes256k` then `ceph orch daemon redeploy <daemon-name>`. For anyone using > > nfs exports managed through the nfs module the export's keyrings also need > > to be rotated. `ceph auth rotate <export-keyring-entity> --key-type > > aes256k`, `ceph nfs export info <nfs-cluster-name> <pseudo-path> > > > export_file`, `ceph nfs export apply <nfs-cluster-name> -i export_file`. > > Between rotating the keyrings for the nfs cluster/daemons and rotating the > > keyring for the individual export(s) those export(s) are unavailable iirc. > > > > On Thu, Aug 20, 2026 at 7:11 AM Pedro Macedo <ceph-users(a)ceph.io> wrote: > > > >> On 2026-08-20 12:57 PM, Maximilian Stinsky-Damke wrote: > >>> Hi, > >>> > >>> I upgraded a test cluster to Ceph Squid 19.2.6 via cephadm. The > >> following cephadm managed client keys were not rotated automatically: > >>> client.bootstrap-* (bootstrap-rgw, bootstrap-osd, ...) > >>> client.ceph-exporter. > >>> client.crash. > >>> client.osd-lockbox.. > >>> client.rgw. > >>> > >>> The Squid docs mention ceph orch daemon rotate-key <name>, but in 19.2.* > >> this command does not exist. > >> > >> Also seeing this on the 20.2.4 image via cephadm - rotate-key is missing > >> there, but present on 20.2.3. > >> > >> https://docs.ceph.com/en/squid/cephadm/services/#deploying-a-daemon-on-a-ho… > >> https://github.com/ceph/ceph/blob/v19.2.6/src/pybind/mgr/cephadm/module.py#… > >>> What is the correct way to rotate these client keys via cephadm as part > >> of the cve fix? > >>> Thanks for any guidance. > >>> Best Regards > >>> Max > >>> > >>> ________________________________ > >>> From: Patrick Donnelly <ceph-users(a)ceph.io> > >>> Sent: 19 August 2026 18:08 > >>> To: ceph-users <ceph-users(a)ceph.io> > >>> Subject: [ceph-users] [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 > >> released > >>> Warning: This email is from an unusual correspondent. > >>> Warning: Make sure this is someone you trust. > >>> > >>> Today, August 19th, 2026, the Ceph project has released Tentacle > >>> 20.2.4 and Squid 19.2.6 hotfixes for four CVEs across several > >>> components. > >>> > >>> This is the sixth backport release in the Squid series. > >>> > >>> This is the fourth backport release in the Tentacle series. > >>> > >>> Additional details will be posted on the Ceph website/blog: > >>> > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fceph.io%2Fen%2Fnews%2Fblog%2F… > >>> We strongly recommend that all Ceph operators upgrade to one of these > >>> releases as soon as possible. > >>> > >>> > >>> ## 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: > >>> > >>> > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> 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. You may notice that Cephadm spends more time than normal on the > >>> upgrade after updating all daemon images. This is due to a new process > >>> rotating the OSD and MDS keys. Please be patient. There are plans to > >>> improve this in the future. > >>> > >>> Deployments using Rook will also automate rotation of some client keys > >>> with some exclusions. Look to the Rook project’s announcement for more > >>> details. > >>> > >>> Client and kernel upgrades are recommended to support aes256k. Note > >>> that upstream Linux kernel client support began in kernel 7.0 and has > >>> been backported to CentOS Stream 9 and 10. Check with your > >>> distribution vendor for backported key support before rotating client > >>> keys used by the kernel. > >>> > >>> 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 here: > >>> > >>> > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> The CephX documentation has been brought up to date and vetted for > >>> accuracy. Those changes are live here: > >>> > >>> > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> Regarding the fix for CVE-2026-54330, RGW will now reject Sigv4 > >>> requests with `host` and `x-amz-` headers not included in the signed > >>> subset. Unfortunately, the REST client used in multisite was > >>> generating such improperly signed requests. > >>> > >>> 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. > >>> > >>> Regarding the fix for CVE-2026-50152, formal guidance on rotating all > >>> secrets stored in the Monitor config-key store will be forthcoming. In > >>> the meantime, operators of cephadm-managed clusters are strongly > >>> encouraged to rotate the cephadm SSH key, as an established process > >>> exists: > >>> > >>> See: > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> Rotating other secrets is advised but the process is not yet > >>> established. Operators should assess their cluster's potential > >>> exposure to determine if immediate Monitor config-key secret rotation > >>> is required for their environment. > >>> > >>> > >>> ## CVE Fixes > >>> > >>> * CVE-2025-30156 is an authentication bypass in CephX caused by misuse > >>> of AES-CBC. > >>> > >>> See: > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> * CVE-2026-39944 shares the unauthenticated-encryption root cause of > >>> CVE-2025-30156, but applies it to RGW's STS session tokens resulting > >>> in improper verification of a cryptographic signature. > >>> > >>> See: > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> * CVE-2026-50152 is an improper authorization flaw in the Ceph Monitor > >>> subscription handler. > >>> > >>> See: > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> * CVE-2026-54330 is a flaw in RGW not properly verifying its SigV4 > >>> cryptographic signatures in RGW's SigV4 verifier. > >>> > >>> See: > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> ## Other Media > >>> > >>> A Cephalocon 2025 talk covers some of the details surrounding the new > >>> CephX key upgrade process. > >>> > >>> > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fcephalocon2025.sched.com%2Fev… > >>> ## Getting Ceph > >>> ------------ > >>> * Source at > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Fceph%2Fceph&e=50… > >>> * v19.2.6 Tarball at > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdownload.ceph.com%2Ftarballs%… > >>> * v20.2.4 Tarball at > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdownload.ceph.com%2Ftarballs%… > >>> * Containers at > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fquay.io%2Frepository%2Fceph%2… > >>> * For packages, see > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> * For upgrade with cephadm, see: > >>> > >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > >>> * v19.2.6 Release git sha1: f9fd95b4335bad6a26d7a74468f55d269e8dbef4 > >>> * v20.2.4 Release git sha1: 7f793731f1b39eb4f465e960113d2363c311b964 > >>> > >>> -- > >>> Patrick Donnelly, Ph.D. > >>> He / Him / His > >>> Red Hat Partner Engineer > >>> IBM, Inc. > >>> GPG: 19F28A586F808C2402351B93C3301A3E258DD79D > >>> _______________________________________________ > >>> ceph-users mailing list -- ceph-users(a)ceph.io > >>> To unsubscribe send an email to ceph-users-leave(a)ceph.io > >>> > >>> -- > >>> This message has been checked by Libraesva ESG and is found to be clean. > >>> Follow this link to report as spam/bad: > >>> https://mx10.wiit.cloud/action/4hQBLz2RJPzTh0J/report-as-bad > >>> Follow this link to blocklist sender: > >>> https://mx10.wiit.cloud/action/4hQBLz2RJPzTh0J/blocklist > >>> > >>> _______________________________________________ > >>> ceph-users mailing list -- ceph-users(a)ceph.io > >>> To unsubscribe send an email to ceph-users-leave(a)ceph.io > >> _______________________________________________ > >> ceph-users mailing list -- ceph-users(a)ceph.io > >> To unsubscribe send an email to ceph-users-leave(a)ceph.io > >> > >> > > _______________________________________________ > > ceph-users mailing list -- ceph-users(a)ceph.io > > To unsubscribe send an email to ceph-users-leave(a)ceph.io > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
by Patrick Donnelly 21 Aug '26

21 Aug '26

Hi Gary, On Thu, Aug 20, 2026 at 2:31 PM Gary Molenkamp <ceph-users(a)ceph.io> wrote: > > Hi Patrick > >> One question, though: is it possible to have a client with two keys, > >> aes and aes256? One of my cluster is mainly used for RBD with client.libvirt > >> user, and I have hundreds of running VMs, which I cannot restart at once. > >> So I would like to _add_ an aes256 key to the client.libvirt user, > >> and incrementally restart the qemu processes which use this secret. > > No, you cannot have two keys. I think a lesson (for everyone) here is > > that each node should have its own client key. It became prevalent to > > use the same key everywhere for simplicity but it makes deployments > > and updates more challenging. > > > >> Or what is the recommended way of gradually replacing a client key? > > Create new keys for each node. > > > > A challenge to that approach is that Proxmox PVE defines external RBD > pools at the datacenter level using a single user/key pair. This then > becomes the storage pool on each individual node in the proxmox > cluster. I believe ceph-csi K8 storage class also defines this once > cluster wide. I understand but the only way to change things is to spread the word. If the key is that challenging to rotate, then I would suggest leaving it as aes and push for changes in the product or deployment technology. Rook developers are already aware this should be reworked. -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D

1 0

Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
by Gary Molenkamp 21 Aug '26

21 Aug '26

Hi Patrick >> One question, though: is it possible to have a client with two keys, >> aes and aes256? One of my cluster is mainly used for RBD with client.libvirt >> user, and I have hundreds of running VMs, which I cannot restart at once. >> So I would like to _add_ an aes256 key to the client.libvirt user, >> and incrementally restart the qemu processes which use this secret. > No, you cannot have two keys. I think a lesson (for everyone) here is > that each node should have its own client key. It became prevalent to > use the same key everywhere for simplicity but it makes deployments > and updates more challenging. > >> Or what is the recommended way of gradually replacing a client key? > Create new keys for each node. > A challenge to that approach is that Proxmox PVE defines external RBD pools at the datacenter level using a single user/key pair. This then becomes the storage pool on each individual node in the proxmox cluster. I believe ceph-csi K8 storage class also defines this once cluster wide. Gary

1 0

Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
by Jan Kasprzak 20 Aug '26

20 Aug '26

Hi all, Patrick Donnelly wrote: > Today, August 19th, 2026, the Ceph project has released Tentacle > 20.2.4 and Squid 19.2.6 hotfixes for four CVEs across several > components. I have just upgraded one of my cluster from 20.2.3 to 20.2.4. The documentation seems to be clear (thanks!) and worked for me with the exception of step 4: > 4. Confirm the AUTH_INSECURE_SERVICE_KEY_TYPE is cleared. > > ceph --format=json health detail | jq '.checks | has("AUTH_INSECURE_SERVICE_KEY_TYPE") | not' > > output gives false. > > If it outputs true, there is another daemon that needs to be upgraded. > Check the output of ceph health detail. I might have done something wrong, but if I remember it correctly, at this point I still got 4 AUTH_INSECURE_SERVICE_KEY_TYPE keys, and had to do step 5 "ceph mon set auth_service_cipher aes256k" first and then step 6 "ceph auth wipe-rotating-service-keys". Only then the AUTH_INSECURE_SERVICE_KEY_TYPE disappeared from ceph health detail (together with AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE). One question, though: is it possible to have a client with two keys, aes and aes256? One of my cluster is mainly used for RBD with client.libvirt user, and I have hundreds of running VMs, which I cannot restart at once. So I would like to _add_ an aes256 key to the client.libvirt user, and incrementally restart the qemu processes which use this secret. Or what is the recommended way of gradually replacing a client key? Thanks! -Yenya -- | Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> | | https://www.fi.muni.cz/~kas/ GPG: 4096R/A45477D5 | I don't like Python; its lack of inline, anonymous, multi-statement functions makes me sad. --Eric Wastl

1 0

Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
by Chris Palmer 20 Aug '26

20 Aug '26

Can anyone confirm whether OSDs that were adopted into cephadm but remain unmanaged will be automatically rotated? (Currently on 20.2.3). On 20/08/2026 14:45, Adam King wrote: > That command got removed for the time being as it used an old way of doing > the key rotation that wasn't built to work with the changes for the cve and > seemed to be broken for a number of daemon types. Since the name would make > people want to use it it was decided to just temporarily disables it so we > can fix it and reintroduce it in a new version as an easier way to rotate > the keys. For any keys tied to a cephadm deployed daemon that aren't > automatically rotated (cephadm handles mgr, mon, osd, and mds keyrings > during upgrade) it's a matter of `ceph auth rotate <entity-name> --key-type > aes256k` then `ceph orch daemon redeploy <daemon-name>`. For anyone using > nfs exports managed through the nfs module the export's keyrings also need > to be rotated. `ceph auth rotate <export-keyring-entity> --key-type > aes256k`, `ceph nfs export info <nfs-cluster-name> <pseudo-path> > > export_file`, `ceph nfs export apply <nfs-cluster-name> -i export_file`. > Between rotating the keyrings for the nfs cluster/daemons and rotating the > keyring for the individual export(s) those export(s) are unavailable iirc. > > On Thu, Aug 20, 2026 at 7:11 AM Pedro Macedo <ceph-users(a)ceph.io> wrote: > >> On 2026-08-20 12:57 PM, Maximilian Stinsky-Damke wrote: >>> Hi, >>> >>> I upgraded a test cluster to Ceph Squid 19.2.6 via cephadm. The >> following cephadm managed client keys were not rotated automatically: >>> client.bootstrap-* (bootstrap-rgw, bootstrap-osd, ...) >>> client.ceph-exporter. >>> client.crash. >>> client.osd-lockbox.. >>> client.rgw. >>> >>> The Squid docs mention ceph orch daemon rotate-key <name>, but in 19.2.* >> this command does not exist. >> >> Also seeing this on the 20.2.4 image via cephadm - rotate-key is missing >> there, but present on 20.2.3. >> >> https://docs.ceph.com/en/squid/cephadm/services/#deploying-a-daemon-on-a-ho… >> https://github.com/ceph/ceph/blob/v19.2.6/src/pybind/mgr/cephadm/module.py#… >>> What is the correct way to rotate these client keys via cephadm as part >> of the cve fix? >>> Thanks for any guidance. >>> Best Regards >>> Max >>> >>> ________________________________ >>> From: Patrick Donnelly <ceph-users(a)ceph.io> >>> Sent: 19 August 2026 18:08 >>> To: ceph-users <ceph-users(a)ceph.io> >>> Subject: [ceph-users] [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 >> released >>> Warning: This email is from an unusual correspondent. >>> Warning: Make sure this is someone you trust. >>> >>> Today, August 19th, 2026, the Ceph project has released Tentacle >>> 20.2.4 and Squid 19.2.6 hotfixes for four CVEs across several >>> components. >>> >>> This is the sixth backport release in the Squid series. >>> >>> This is the fourth backport release in the Tentacle series. >>> >>> Additional details will be posted on the Ceph website/blog: >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fceph.io%2Fen%2Fnews%2Fblog%2F… >>> We strongly recommend that all Ceph operators upgrade to one of these >>> releases as soon as possible. >>> >>> >>> ## 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: >>> >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> 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. You may notice that Cephadm spends more time than normal on the >>> upgrade after updating all daemon images. This is due to a new process >>> rotating the OSD and MDS keys. Please be patient. There are plans to >>> improve this in the future. >>> >>> Deployments using Rook will also automate rotation of some client keys >>> with some exclusions. Look to the Rook project’s announcement for more >>> details. >>> >>> Client and kernel upgrades are recommended to support aes256k. Note >>> that upstream Linux kernel client support began in kernel 7.0 and has >>> been backported to CentOS Stream 9 and 10. Check with your >>> distribution vendor for backported key support before rotating client >>> keys used by the kernel. >>> >>> 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 here: >>> >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> The CephX documentation has been brought up to date and vetted for >>> accuracy. Those changes are live here: >>> >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> Regarding the fix for CVE-2026-54330, RGW will now reject Sigv4 >>> requests with `host` and `x-amz-` headers not included in the signed >>> subset. Unfortunately, the REST client used in multisite was >>> generating such improperly signed requests. >>> >>> 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. >>> >>> Regarding the fix for CVE-2026-50152, formal guidance on rotating all >>> secrets stored in the Monitor config-key store will be forthcoming. In >>> the meantime, operators of cephadm-managed clusters are strongly >>> encouraged to rotate the cephadm SSH key, as an established process >>> exists: >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> Rotating other secrets is advised but the process is not yet >>> established. Operators should assess their cluster's potential >>> exposure to determine if immediate Monitor config-key secret rotation >>> is required for their environment. >>> >>> >>> ## CVE Fixes >>> >>> * CVE-2025-30156 is an authentication bypass in CephX caused by misuse >>> of AES-CBC. >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * CVE-2026-39944 shares the unauthenticated-encryption root cause of >>> CVE-2025-30156, but applies it to RGW's STS session tokens resulting >>> in improper verification of a cryptographic signature. >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * CVE-2026-50152 is an improper authorization flaw in the Ceph Monitor >>> subscription handler. >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * CVE-2026-54330 is a flaw in RGW not properly verifying its SigV4 >>> cryptographic signatures in RGW's SigV4 verifier. >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> ## Other Media >>> >>> A Cephalocon 2025 talk covers some of the details surrounding the new >>> CephX key upgrade process. >>> >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fcephalocon2025.sched.com%2Fev… >>> ## Getting Ceph >>> ------------ >>> * Source at >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Fceph%2Fceph&e=50… >>> * v19.2.6 Tarball at >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdownload.ceph.com%2Ftarballs%… >>> * v20.2.4 Tarball at >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdownload.ceph.com%2Ftarballs%… >>> * Containers at >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fquay.io%2Frepository%2Fceph%2… >>> * For packages, see >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * For upgrade with cephadm, see: >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * v19.2.6 Release git sha1: f9fd95b4335bad6a26d7a74468f55d269e8dbef4 >>> * v20.2.4 Release git sha1: 7f793731f1b39eb4f465e960113d2363c311b964 >>> >>> -- >>> Patrick Donnelly, Ph.D. >>> He / Him / His >>> Red Hat Partner Engineer >>> IBM, Inc. >>> GPG: 19F28A586F808C2402351B93C3301A3E258DD79D >>> _______________________________________________ >>> ceph-users mailing list -- ceph-users(a)ceph.io >>> To unsubscribe send an email to ceph-users-leave(a)ceph.io >>> >>> -- >>> This message has been checked by Libraesva ESG and is found to be clean. >>> Follow this link to report as spam/bad: >>> https://mx10.wiit.cloud/action/4hQBLz2RJPzTh0J/report-as-bad >>> Follow this link to blocklist sender: >>> https://mx10.wiit.cloud/action/4hQBLz2RJPzTh0J/blocklist >>> >>> _______________________________________________ >>> ceph-users mailing list -- ceph-users(a)ceph.io >>> To unsubscribe send an email to ceph-users-leave(a)ceph.io >> _______________________________________________ >> ceph-users mailing list -- ceph-users(a)ceph.io >> To unsubscribe send an email to ceph-users-leave(a)ceph.io >> >> > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
by Pedro Macedo 20 Aug '26

20 Aug '26

Gotcha; in that case, sounds like the documentation and/or the CVE-related docs should be updated to reflect these changes and steps related to non- mgr/mon/osd/mds daemons. On 2026-08-20 3:43 PM, Adam King wrote: > That command got removed for the time being as it used an old way of doing > the key rotation that wasn't built to work with the changes for the cve and > seemed to be broken for a number of daemon types. Since the name would make > people want to use it it was decided to just temporarily disables it so we > can fix it and reintroduce it in a new version as an easier way to rotate > the keys. For any keys tied to a cephadm deployed daemon that aren't > automatically rotated (cephadm handles mgr, mon, osd, and mds keyrings > during upgrade) it's a matter of `ceph auth rotate <entity-name> --key-type > aes256k` then `ceph orch daemon redeploy <daemon-name>`. For anyone using > nfs exports managed through the nfs module the export's keyrings also need > to be rotated. `ceph auth rotate <export-keyring-entity> --key-type > aes256k`, `ceph nfs export info <nfs-cluster-name> <pseudo-path> > > export_file`, `ceph nfs export apply <nfs-cluster-name> -i export_file`. > Between rotating the keyrings for the nfs cluster/daemons and rotating the > keyring for the individual export(s) those export(s) are unavailable iirc. > > On Thu, Aug 20, 2026 at 7:11 AM Pedro Macedo <ceph-users(a)ceph.io> wrote: > >> On 2026-08-20 12:57 PM, Maximilian Stinsky-Damke wrote: >>> Hi, >>> >>> I upgraded a test cluster to Ceph Squid 19.2.6 via cephadm. The >> following cephadm managed client keys were not rotated automatically: >>> client.bootstrap-* (bootstrap-rgw, bootstrap-osd, ...) >>> client.ceph-exporter. >>> client.crash. >>> client.osd-lockbox.. >>> client.rgw. >>> >>> The Squid docs mention ceph orch daemon rotate-key <name>, but in 19.2.* >> this command does not exist. >> >> Also seeing this on the 20.2.4 image via cephadm - rotate-key is missing >> there, but present on 20.2.3. >> >> https://docs.ceph.com/en/squid/cephadm/services/#deploying-a-daemon-on-a-ho… >> https://github.com/ceph/ceph/blob/v19.2.6/src/pybind/mgr/cephadm/module.py#… >>> What is the correct way to rotate these client keys via cephadm as part >> of the cve fix? >>> Thanks for any guidance. >>> Best Regards >>> Max >>> >>> ________________________________ >>> From: Patrick Donnelly <ceph-users(a)ceph.io> >>> Sent: 19 August 2026 18:08 >>> To: ceph-users <ceph-users(a)ceph.io> >>> Subject: [ceph-users] [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 >> released >>> Warning: This email is from an unusual correspondent. >>> Warning: Make sure this is someone you trust. >>> >>> Today, August 19th, 2026, the Ceph project has released Tentacle >>> 20.2.4 and Squid 19.2.6 hotfixes for four CVEs across several >>> components. >>> >>> This is the sixth backport release in the Squid series. >>> >>> This is the fourth backport release in the Tentacle series. >>> >>> Additional details will be posted on the Ceph website/blog: >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fceph.io%2Fen%2Fnews%2Fblog%2F… >>> We strongly recommend that all Ceph operators upgrade to one of these >>> releases as soon as possible. >>> >>> >>> ## 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: >>> >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> 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. You may notice that Cephadm spends more time than normal on the >>> upgrade after updating all daemon images. This is due to a new process >>> rotating the OSD and MDS keys. Please be patient. There are plans to >>> improve this in the future. >>> >>> Deployments using Rook will also automate rotation of some client keys >>> with some exclusions. Look to the Rook project’s announcement for more >>> details. >>> >>> Client and kernel upgrades are recommended to support aes256k. Note >>> that upstream Linux kernel client support began in kernel 7.0 and has >>> been backported to CentOS Stream 9 and 10. Check with your >>> distribution vendor for backported key support before rotating client >>> keys used by the kernel. >>> >>> 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 here: >>> >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> The CephX documentation has been brought up to date and vetted for >>> accuracy. Those changes are live here: >>> >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> Regarding the fix for CVE-2026-54330, RGW will now reject Sigv4 >>> requests with `host` and `x-amz-` headers not included in the signed >>> subset. Unfortunately, the REST client used in multisite was >>> generating such improperly signed requests. >>> >>> 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. >>> >>> Regarding the fix for CVE-2026-50152, formal guidance on rotating all >>> secrets stored in the Monitor config-key store will be forthcoming. In >>> the meantime, operators of cephadm-managed clusters are strongly >>> encouraged to rotate the cephadm SSH key, as an established process >>> exists: >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> Rotating other secrets is advised but the process is not yet >>> established. Operators should assess their cluster's potential >>> exposure to determine if immediate Monitor config-key secret rotation >>> is required for their environment. >>> >>> >>> ## CVE Fixes >>> >>> * CVE-2025-30156 is an authentication bypass in CephX caused by misuse >>> of AES-CBC. >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * CVE-2026-39944 shares the unauthenticated-encryption root cause of >>> CVE-2025-30156, but applies it to RGW's STS session tokens resulting >>> in improper verification of a cryptographic signature. >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * CVE-2026-50152 is an improper authorization flaw in the Ceph Monitor >>> subscription handler. >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * CVE-2026-54330 is a flaw in RGW not properly verifying its SigV4 >>> cryptographic signatures in RGW's SigV4 verifier. >>> >>> See: >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> ## Other Media >>> >>> A Cephalocon 2025 talk covers some of the details surrounding the new >>> CephX key upgrade process. >>> >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fcephalocon2025.sched.com%2Fev… >>> ## Getting Ceph >>> ------------ >>> * Source at >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Fceph%2Fceph&e=50… >>> * v19.2.6 Tarball at >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdownload.ceph.com%2Ftarballs%… >>> * v20.2.4 Tarball at >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdownload.ceph.com%2Ftarballs%… >>> * Containers at >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fquay.io%2Frepository%2Fceph%2… >>> * For packages, see >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * For upgrade with cephadm, see: >>> >> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… >>> * v19.2.6 Release git sha1: f9fd95b4335bad6a26d7a74468f55d269e8dbef4 >>> * v20.2.4 Release git sha1: 7f793731f1b39eb4f465e960113d2363c311b964 >>> >>> -- >>> Patrick Donnelly, Ph.D. >>> He / Him / His >>> Red Hat Partner Engineer >>> IBM, Inc. >>> GPG: 19F28A586F808C2402351B93C3301A3E258DD79D >>> _______________________________________________ >>> ceph-users mailing list -- ceph-users(a)ceph.io >>> To unsubscribe send an email to ceph-users-leave(a)ceph.io >>> >>> -- >>> This message has been checked by Libraesva ESG and is found to be clean. >>> Follow this link to report as spam/bad: >>> https://mx10.wiit.cloud/action/4hQBLz2RJPzTh0J/report-as-bad >>> Follow this link to blocklist sender: >>> https://mx10.wiit.cloud/action/4hQBLz2RJPzTh0J/blocklist >>> >>> _______________________________________________ >>> ceph-users mailing list -- ceph-users(a)ceph.io >>> To unsubscribe send an email to ceph-users-leave(a)ceph.io >> _______________________________________________ >> ceph-users mailing list -- ceph-users(a)ceph.io >> To unsubscribe send an email to ceph-users-leave(a)ceph.io >> >> > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
by Adam King 20 Aug '26

20 Aug '26

That command got removed for the time being as it used an old way of doing the key rotation that wasn't built to work with the changes for the cve and seemed to be broken for a number of daemon types. Since the name would make people want to use it it was decided to just temporarily disables it so we can fix it and reintroduce it in a new version as an easier way to rotate the keys. For any keys tied to a cephadm deployed daemon that aren't automatically rotated (cephadm handles mgr, mon, osd, and mds keyrings during upgrade) it's a matter of `ceph auth rotate <entity-name> --key-type aes256k` then `ceph orch daemon redeploy <daemon-name>`. For anyone using nfs exports managed through the nfs module the export's keyrings also need to be rotated. `ceph auth rotate <export-keyring-entity> --key-type aes256k`, `ceph nfs export info <nfs-cluster-name> <pseudo-path> > export_file`, `ceph nfs export apply <nfs-cluster-name> -i export_file`. Between rotating the keyrings for the nfs cluster/daemons and rotating the keyring for the individual export(s) those export(s) are unavailable iirc. On Thu, Aug 20, 2026 at 7:11 AM Pedro Macedo <ceph-users(a)ceph.io> wrote: > > On 2026-08-20 12:57 PM, Maximilian Stinsky-Damke wrote: > > Hi, > > > > I upgraded a test cluster to Ceph Squid 19.2.6 via cephadm. The > following cephadm managed client keys were not rotated automatically: > > > > client.bootstrap-* (bootstrap-rgw, bootstrap-osd, ...) > > client.ceph-exporter. > > client.crash. > > client.osd-lockbox.. > > client.rgw. > > > > The Squid docs mention ceph orch daemon rotate-key <name>, but in 19.2.* > this command does not exist. > > Also seeing this on the 20.2.4 image via cephadm - rotate-key is missing > there, but present on 20.2.3. > > > > https://docs.ceph.com/en/squid/cephadm/services/#deploying-a-daemon-on-a-ho… > > > https://github.com/ceph/ceph/blob/v19.2.6/src/pybind/mgr/cephadm/module.py#… > > > > What is the correct way to rotate these client keys via cephadm as part > of the cve fix? > > > > Thanks for any guidance. > > Best Regards > > Max > > > > ________________________________ > > From: Patrick Donnelly <ceph-users(a)ceph.io> > > Sent: 19 August 2026 18:08 > > To: ceph-users <ceph-users(a)ceph.io> > > Subject: [ceph-users] [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 > released > > > > Warning: This email is from an unusual correspondent. > > Warning: Make sure this is someone you trust. > > > > Today, August 19th, 2026, the Ceph project has released Tentacle > > 20.2.4 and Squid 19.2.6 hotfixes for four CVEs across several > > components. > > > > This is the sixth backport release in the Squid series. > > > > This is the fourth backport release in the Tentacle series. > > > > Additional details will be posted on the Ceph website/blog: > > > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fceph.io%2Fen%2Fnews%2Fblog%2F… > > > > We strongly recommend that all Ceph operators upgrade to one of these > > releases as soon as possible. > > > > > > ## 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: > > > > > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > > > 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. You may notice that Cephadm spends more time than normal on the > > upgrade after updating all daemon images. This is due to a new process > > rotating the OSD and MDS keys. Please be patient. There are plans to > > improve this in the future. > > > > Deployments using Rook will also automate rotation of some client keys > > with some exclusions. Look to the Rook project’s announcement for more > > details. > > > > Client and kernel upgrades are recommended to support aes256k. Note > > that upstream Linux kernel client support began in kernel 7.0 and has > > been backported to CentOS Stream 9 and 10. Check with your > > distribution vendor for backported key support before rotating client > > keys used by the kernel. > > > > 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 here: > > > > > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > > > The CephX documentation has been brought up to date and vetted for > > accuracy. Those changes are live here: > > > > > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > > > Regarding the fix for CVE-2026-54330, RGW will now reject Sigv4 > > requests with `host` and `x-amz-` headers not included in the signed > > subset. Unfortunately, the REST client used in multisite was > > generating such improperly signed requests. > > > > 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. > > > > Regarding the fix for CVE-2026-50152, formal guidance on rotating all > > secrets stored in the Monitor config-key store will be forthcoming. In > > the meantime, operators of cephadm-managed clusters are strongly > > encouraged to rotate the cephadm SSH key, as an established process > > exists: > > > > See: > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > > > Rotating other secrets is advised but the process is not yet > > established. Operators should assess their cluster's potential > > exposure to determine if immediate Monitor config-key secret rotation > > is required for their environment. > > > > > > ## CVE Fixes > > > > * CVE-2025-30156 is an authentication bypass in CephX caused by misuse > > of AES-CBC. > > > > See: > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > > > * CVE-2026-39944 shares the unauthenticated-encryption root cause of > > CVE-2025-30156, but applies it to RGW's STS session tokens resulting > > in improper verification of a cryptographic signature. > > > > See: > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > > > * CVE-2026-50152 is an improper authorization flaw in the Ceph Monitor > > subscription handler. > > > > See: > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > > > * CVE-2026-54330 is a flaw in RGW not properly verifying its SigV4 > > cryptographic signatures in RGW's SigV4 verifier. > > > > See: > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > > > ## Other Media > > > > A Cephalocon 2025 talk covers some of the details surrounding the new > > CephX key upgrade process. > > > > > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fcephalocon2025.sched.com%2Fev… > > > > ## Getting Ceph > > ------------ > > * Source at > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Fceph%2Fceph&e=50… > > * v19.2.6 Tarball at > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdownload.ceph.com%2Ftarballs%… > > * v20.2.4 Tarball at > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdownload.ceph.com%2Ftarballs%… > > * Containers at > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fquay.io%2Frepository%2Fceph%2… > > * For packages, see > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > * For upgrade with cephadm, see: > > > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2… > > * v19.2.6 Release git sha1: f9fd95b4335bad6a26d7a74468f55d269e8dbef4 > > * v20.2.4 Release git sha1: 7f793731f1b39eb4f465e960113d2363c311b964 > > > > -- > > Patrick Donnelly, Ph.D. > > He / Him / His > > Red Hat Partner Engineer > > IBM, Inc. > > GPG: 19F28A586F808C2402351B93C3301A3E258DD79D > > _______________________________________________ > > ceph-users mailing list -- ceph-users(a)ceph.io > > To unsubscribe send an email to ceph-users-leave(a)ceph.io > > > > -- > > This message has been checked by Libraesva ESG and is found to be clean. > > Follow this link to report as spam/bad: > > https://mx10.wiit.cloud/action/4hQBLz2RJPzTh0J/report-as-bad > > Follow this link to blocklist sender: > > https://mx10.wiit.cloud/action/4hQBLz2RJPzTh0J/blocklist > > > > _______________________________________________ > > ceph-users mailing list -- ceph-users(a)ceph.io > > To unsubscribe send an email to ceph-users-leave(a)ceph.io > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > >

1 0