Re: [CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released
On Fri, Aug 21, 2026 at 10:08 AM Nico Schottelius <ceph-users@ceph.io> wrote:
Good morning list,
some of you already mentioned the issue in relation to proxmox, but virtually all VPS/VM hostings are affected that are running qemu/kvm.
The situation is even worse, if I see it correctly:
a) All VPS/VMs need to be restarted To be able to rotate keys, aside from the almost impossible flow to actually doing the rotation (more to that below), this will affect every consumer of VMs. The usual setup is that all hypervisors are using the same key.
b) Key support in qemu/kvm From my understanding, qemu/kvm + librbd does at the moment not have support for the new key type. Thus there will be major waiting periods until the packages have been updated and eventually make it back into the distros. If they are being done at all, depending on your setup there might be old qemu versions which cannot easily be upgraded.
c) Key rotation Assuming that the support actually has landed in qemu/kvm (and that can still take months), one will need to rotate potentially update/edit generade libvirtd xml that contains the reference to the ceph key or the key itself.
I'm not saying anything cannot be done, but the way how this vulnerabilty is solved will cause major headache around the industry.
Again, rotating the client keys is not necessary to address the main vulnerabilities associated with the CVE. You may mute the AUTH_INSECURE_CLIENT_KEY_TYPE warning on an extended basis or permanently if it cannot be resolved for the forseeable future. -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
Hello Patrick, Patrick Donnelly <pdonnell@redhat.com> writes:
[ kvm/qemu situation ] Again, rotating the client keys is not necessary to address the main vulnerabilities associated with the CVE. You may mute the AUTH_INSECURE_CLIENT_KEY_TYPE warning on an extended basis or
On Fri, Aug 21, 2026 at 10:08 AM Nico Schottelius <ceph-users@ceph.io> wrote: permanently if it cannot be resolved for the forseeable future.
I think that is probably the most important information and I'm sorry if I've overread it before. Just one question: what is the security and maintenance impact of not changing the key type for let's say the next 5 years or so? If there is a muted warning that can be disabled and also if ceph continues to support the old key types, that will solve the maintenance issue for the next years. However there was a good reason to add a new key type to address the vulnerability - and my question is, what type of attacks is the cluster still vulnerable against when continuing to use old keys? Wouldn't it imply that attackers with access to the ceph network can still corrupt data written by clients? BR, Nico -- Sustainable and modern Infrastructures by ungleich.ch
On Fri, Aug 21, 2026 at 10:49 AM Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
Just one question: what is the security and maintenance impact of not changing the key type for let's say the next 5 years or so?
There is a non-zero chance an adversary on the network could figure out the AES128 key. But, if you have an adversary sniffing your Ceph cluster network, you have larger problems.
If there is a muted warning that can be disabled and also if ceph continues to support the old key types, that will solve the maintenance issue for the next years.
At this time, we have no plans to deprecate the aes key type. It would needlessly break compatibility with legacy clients/kernels.
However there was a good reason to add a new key type to address the vulnerability - and my question is, what type of attacks is the cluster still vulnerable against when continuing to use old keys? Wouldn't it imply that attackers with access to the ceph network can still corrupt data written by clients?
There are no known practical attacks on the cluster where only client keys use the "aes" key type. -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
participants (2)
-
Nico Schottelius
-
Patrick Donnelly