Ceph is an open-source distributed storage platform providing object, block, and file storage. In versions prior to 20.2.4 and 19.2.6, the CephX authentication protocol encrypts tickets with AES-128-CBC in an unauthenticated mode that uses a hard-coded initialization vector and no message authentication, allowing an attacker to forge credentials and gain cluster-wide access. Because the ciphertext is malleable and the monitor will encrypt attacker-chosen entity names, an attacker holding one low-privilege key and able to observe CephX traffic can use the monitor as an encryption oracle and splice ciphertext blocks into valid tickets for privileged entities such as Manager, MDS, and OSD. The same lack of authentication also lets an attacker with CephX permissions escalate privileges by flipping a single bit in a service ticket to set its allowall field to true. This issue is fixed in versions 20.2.4 and 19.2.6.

OSSN-0108: Multiple authentication vulnerabilities in Ceph ---

Summary ###

The latest Ceph releases of Ceph 20.2.4 and Ceph 19.2.6 patch four CVEs across several components (CVE-2025-30156, CVE-2026-39944, CVE-2026-50152 Ceph servers should be upgraded and their CephX keyrings should be rotated. to be restarted or live migrated in order to load the new keyring.

Affected Services / Software ###

- Ceph: all versions prior to v20.2.4 or v19.2.6 - OpenStack services with CephX keyrings: Nova, Cinder, Glance, Manila - Ceph RADOS Gateway (RGW), when used as an Object Store (Swift/S3) backend

Discussion ###

Any OpenStack service with a CephX keyring (Nova, Cinder, Glance, Manila) is at risk. Data-at-rest encryption is not affected by CVE-2025-30156 but is affected by CVE-2026-50152. Both are fixed by the update in addition to CVE-2026-39944 and CVE-2026-54330.

For an OpenStack cloud using RBD, RGW or NFS, this can be considered an internal vulnerability, potentially enabling an insider to escalate privilege. For example, a Nova guest using Cinder RBD does not have access to the CephX key or Ceph's storage network; the Nova host has access to them but only an insider should have access to the Nova host. However, if an OpenStack tenant is using Manila with native CephFS (not with NFS-Ganesha), then those tenants could exploit these CVEs.

The hardcoded initialization vector means identical plaintexts produce identical ciphertexts. The missing HMAC allows CBC bit-flipping. An attacker who compromises any CephX entity (or obtains its shared secret from network traffic) can tamper with a ticket's permissions without detection and forge credentials for privileged services.

The fix modifies Ceph to use AES256-CTS-HMAC-SHA384-192 (RFC 8009), a new CephX key type named aes256k. Both Ceph server and client packages must be upgraded to use it. If krbd (in place of librbd) or CephFS kernel mounts (in place of ceph-fuse or NFS-Ganesha) are used, the client also requires Linux kernel 7.0 or later. Upgrading the servers and rotating their keys to aes256k resolves the vulnerabilities; clients that have not yet been upgraded continue to authenticate with their existing aes keys in the meantime.

Recommended Actions ###

- Upgrade Ceph to a patched release and update Ceph clients on OpenStack. - Re-create every CephX credential with the new aes256k cipher. - Every OpenStack Nova guest must be live migrated (or restarted) to pick up the new CephX key.

OpenStack Service Keyrings (Nova, Cinder, Glance) ####

To use RBD with Nova, Cinder or Glance, these services should be configured with a Ceph user that uses a CephX key to authenticate to the Ceph cluster. This OSSN will refer to a single client.openstack key for simplicity but configurations with multiple keys are possible. Before rotating or replacing this key:

- The Ceph cluster should be using the new cipher for its internals. For example, the Ceph Monitor, OSD, RGW, MDS and other services should already have rotated their CephX keys so they use the new cipher.

- The Ceph cluster should allow connections from both the old and new cipher as confirmed by the following command.

~~~ ceph mon dump | grep allowedciphers authallowedciphers aes, aes256k ~~~

There are two strategies:

1. Rotate: Use ceph auth rotate to rotate client.openstack. 2. Replace: Create a new CephX key (e.g. client.openstack2), which uses the new cipher, and switch clients to use the new key.

If you are concerned about the time required to migrate Nova guests (so they start using the new key), then use the replacement strategy.

There is no immediate downtime when the credential is rotated but there is limited time to switch to the new credential. The client will continue to function until it tries to reauthenticate with the Ceph Monitors to get new tickets. During that time you can rotate and then restart clients incrementally. Knowing exactly how long you have to rotate the key for all clients can be difficult to predict given the distributed nature of Ceph but we believe it to be a matter of hours, not days.

Rather than be bound by the above, you can have complete control of when the old credential is no longer valid by having two valid credentials and rotating them on your own schedule and then disabling support for the old credential's cipher.

The new CephX key must be distributed to every OpenStack node which connects to Ceph and be imported into libvirt prior migrating Nova guests to have them pick up the new key.

Manila with Native CephFS ####

With Manila, users create CephX keys for native CephFS share access. These keys are exposed to tenant VMs. To rotate, for each share:

1. Grant new share access (new CephX key with aes256k) 2. Remount the share using the new credentials 3. Revoke the old share access

All shares for a tenant must be covered. Partial rotation leaves the old CephX user and key valid for any shares not yet rotated.

Manila with NFS-Ganesha ####

The main NFS-Ganesha CephX key can be rotated and the service redeployed. Per-export CephX keys (created automatically per share) do not have a rotation mechanism yet. To rotate these, delete and recreate access rules for each share. This requires unmount/remount and is disruptive.

These per-export keys are internal to the Ceph cluster and not exposed to tenants. Operators can defer their rotation until Ceph provides a rotation mechanism if the risk is tolerable.

Enforcing the New Cipher ####

After all CephX keys have been rotated, enforce the new cipher: ~~~ ceph mon set authallowedciphers aes256k ~~~

Credits ###

- Erin Shepherd, e43.eu - David Mohren, Clyso - Mark Nelson, Clyso

Contacts / References ###

Authors: - John Fulton, Red Hat - Goutham Pacha Ravi, Red Hat - Sage McTaggart, IBM

This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0108 Original LaunchPad Bug: None Mailing List : [security-sig] tag on openstack-discuss () lists openstack org OpenStack Security : https://security.openstack.org/ CVE: CVE-2025-30156, CVE-2026-39944, CVE-2026-50152, CVE-2026-54330

Today, August 19th 2026, the Ceph project has released Tentacle 20.2.4<https://github.com/ceph/ceph/releases/tag/v20.2.4> and Squid 19.2.6<https://github.com/ceph/ceph/releases/tag/v19.2.6>.

These releases include 4 security fixes.

CVE-2025-30156 AES-CBC misuse in CephX facilitating authentication bypass

CVE-2025-30156[1][2] stems from a broken cryptographic implementation in CephX, similar to the vulnerability class described in the Perils paper[3] on Kerberos 4. CephX used AES-CBC without authentication and with a hardcoded initialization vector. As a result, identical plaintexts produced identical ciphertexts, and an attacker with any compromised credentials on the Ceph network could exploit this in two ways: by observing ciphertext patterns to infer plaintext, and by flipping bits in the ciphertext to alter data undetected, including expanding the scope of their own credentials. No user interaction is required. The impact to confidentiality and integrity is high; the impact to availability is low. The CVSS score is 8.9 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L). Ceph has replaced AES-CBC with AES-256-CTS-HMAC-SHA384-192. This required substantial changes across userspace daemons and drew on significant upstream Linux kernel work. This vulnerability was reported by Erin Shepherd of e43.eu and later independently by David Mohren and Mark Nelson of CLYSO as well as and David Korczynski of Ada Logics.

CVE-2026-50152 Ceph MON config-key store improper authorization

CVE-2026-50152[6][7] is an improper authorization flaw in the Ceph Monitor subscription handler. Any CephX user with mon allow r caps can read the entire Monitor config-key store by sending a single crafted MMonSubscribe message. This exposes OSD LUKS passphrases and, on cephadm-managed clusters, the SSH private key cephadm uses to access every host; yielding root access under the default cephadm configuration. The attacker must have access to the Ceph cluster and a compromised account with mon allow r permissions. No user interaction is required. The scope may change depending on cluster management configuration. The impact to confidentiality and integrity is high. The CVSS score is 8.2 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L). This vulnerability was reported independently by David Mohren and Mark Nelson of CLYSO and David Korczynski of Ada Logics.

CVE-2026-54330 Ceph RGW SigV4 verifier error allows attachment of arbitrary x-amz- headers resulting in privilege escalation

CVE-2026-54330[6] involves improper verification of cryptographic signatures within Ceph RGW’s SigV4 handler. Anyone with a presigned PUT URL can attach arbitrary x-amz headers that RGW will then apply, granting more capabilities than the signer intended. AWS S3 requires every x-amz- header on SigV4 requests to be signed, and ensures any request carrying additional headers is rejected, but RGW does not check if new unsigned headers are present, only verifying the validity of the headers listed in X-Amz-SignedHeaders, bypassing the signature check. With minimal permissions, simply a pre-signed PUT URL, an attacker can escalate their privileges, and create a high impact to confidentiality and integrity. The CVSS score is 8.2(CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N). This vulnerability was reported by David Mohren and Mark Nelson of CLYSO.

CVE-2026-39944 Ceph RGW STS tokens vulnerable to CBC bit-flip privilege escalation to RGW admin

CVE-2026-39944[8][9] is an improper verification of a cryptographic signature in Ceph RGW's STS session tokens. The tokens use the same unauthenticated AES-128-CBC handler as the CephX flaw in CVE-2025-30156, and share its lack of integrity protection. An attacker holding any valid STS token can use the attack chain to obtain full RGW admin access. Unlike the CephX attack (CVE-2025-30156), which runs on the internal messenger network and relies on the attacker having access to the Ceph monitor, this one is a self-contained modification of a token the attacker already holds. It requires only a single valid, unprivileged STS token and STS enabled (rgws3authusests = true). The CVSS score is 8.5 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H). This vulnerability was reported by Erin Shepherd of e43.eu and later independently by David Mohren and Mark Nelson of CLYSO as well.

Please see our published advisories for more information on each CVE. Thank You to our open-source reporters and contributors for their work on this!

[1] https://github.com/ceph/ceph/security/advisories/GHSA-rmjq-ffrm-j6vj [2]https://docs.ceph.com/en/latest/security/CVE-2025-30156/ [3] <https://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf> https://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf [4] <https://github.com/ceph/ceph/security/advisories/GHSA-rg9p-5xcp-wm8h> https://github.com/ceph/ceph/security/advisories/GHSA-rg9p-5xcp-wm8h [5]https://docs.ceph.com/en/latest/security/CVE-2026-50152/ [6]https://github.com/ceph/ceph/security/advisories/GHSA-rmjq-ffrm-j6vj <https://github.com/ceph/ceph/security/advisories/GHSA-rmjq-ffrm-j6vj> [7] https://docs.ceph.com/en/latest/security/CVE-2026-54330 [8] https://github.com/ceph/ceph/security/advisories/GHSA-j73r-qrgx-jvq2 [9] <https://docs.ceph.com/en/latest/security/CVE-2026-39944> https://docs.ceph.com/en/latest/security/CVE-2026-39944

Best, Sage McTaggart My work hours may not be your work hours. Please don’t feel obligated to reply outside your normal schedule.

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix possible deadlock when holding Fwb to get inlinedata

1, mount with wsync. 2, create a file with ORDWR, and the request was sent to mds.0:

cephatomicopen()--> cephmdscdorequest(openc) finishopen(file, dentry, cephopen)--> cephopen()--> cephinitfile()--> cephinitfileinfo()--> cephuninlinedata()--> { ... if (inlineversion == 1 || / initial version, no data / inlineversion == CEPHINLINENONE) goto outunlock; ... }

The inlineversion will be 1, which is the initial version for the new create file. And here the ci->iinlineversion will keep with 1, it's buggy.

3, buffer write to the file immediately:

cephwriteiter()--> cephgetcaps(file, need=Fw, want=Fb, ...); genericperformwrite()--> aops->writebegin()--> cephwritebegin()--> netfswritebegin()--> netfsbeginread()--> netfsrreqsubmitslice()--> netfsreadfromserver()--> rreq->netfsops->issueread()--> cephnetfsissueread()--> { ... if (ci->iinlineversion != CEPHINLINENONE && cephnetfsissueopinline(subreq)) return; ... } cephputcaprefs(ci, Fwb);

The cephnetfsissueopinline() will send a getattr(Fsr) request to mds.1.

4, then the mds.1 will request the rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation from excl --> sync, but it need to revoke the Fxwb caps back from the clients.

While the kernel client has aleady held the Fwb caps and waiting for the getattr(Fsr).

It's deadlock!

URL: https://tracker.ceph.com/issues/55377

A flaw was found in the way the Ceph RGW Beast front-end handles unexpected disconnects. An authenticated attacker can abuse this flaw by making multiple disconnect attempts resulting in a permanent leak of a socket connection by radosgw. This flaw could lead to a denial of service condition by pile up of CLOSEWAIT sockets, eventually leading to the exhaustion of available resources, preventing legitimate users from connecting to the system.

In the Linux kernel, the following vulnerability has been resolved:

ceph: avoid kernel BUG for encrypted inode with unaligned file size

The generic/397 test hits a BUGON for the case of encrypted inode with unaligned file size (for example, 33K or 1K):

[ 877.737811] run fstests generic/397 at 2025-01-03 12:34:40 [ 877.875761] libceph: mon0 (2)127.0.0.1:40674 session established [ 877.876130] libceph: client4614 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 877.991965] libceph: mon0 (2)127.0.0.1:40674 session established [ 877.992334] libceph: client4617 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.017234] libceph: mon0 (2)127.0.0.1:40674 session established [ 878.017594] libceph: client4620 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.031394] xfsio (pid 18988) is setting deprecated v1 encryption policy; recommend upgrading to v2. [ 878.054528] libceph: mon0 (2)127.0.0.1:40674 session established [ 878.054892] libceph: client4623 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.070287] libceph: mon0 (2)127.0.0.1:40674 session established [ 878.070704] libceph: client4626 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.264586] libceph: mon0 (2)127.0.0.1:40674 session established [ 878.265258] libceph: client4629 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.374578] -----------[ cut here ]------------ [ 878.374586] kernel BUG at net/ceph/messenger.c:1070! [ 878.375150] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 878.378145] CPU: 2 UID: 0 PID: 4759 Comm: kworker/2:9 Not tainted 6.13.0-rc5+ #1 [ 878.378969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 878.380167] Workqueue: ceph-msgr cephconworkfn [ 878.381639] RIP: 0010:cephmsgdatacursorinit+0x42/0x50 [ 878.382152] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 [ 878.383928] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287 [ 878.384447] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000 [ 878.385129] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378 [ 878.385839] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000 [ 878.386539] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030 [ 878.387203] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001 [ 878.387877] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000 [ 878.388663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 878.389212] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0 [ 878.389921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 878.390620] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 878.391307] PKRU: 55555554 [ 878.391567] Call Trace: [ 878.391807] <TASK> [ 878.392021] ? showregs+0x71/0x90 [ 878.392391] ? die+0x38/0xa0 [ 878.392667] ? dotrap+0xdb/0x100 [ 878.392981] ? doerrortrap+0x75/0xb0 [ 878.393372] ? cephmsgdatacursorinit+0x42/0x50 [ 878.393842] ? excinvalidop+0x53/0x80 [ 878.394232] ? cephmsgdatacursorinit+0x42/0x50 [ 878.394694] ? asmexcinvalidop+0x1b/0x20 [ 878.395099] ? cephmsgdatacursorinit+0x42/0x50 [ 878.395583] ? cephconv2tryread+0xd16/0x2220 [ 878.396027] ? rawspinunlock+0xe/0x40 [ 878.396428] ? rawspinrqunlock+0x10/0x40 [ 878.396842] ? finishtaskswitch.isra.0+0x97/0x310 [ 878.397338] ? schedule+0x44b/0x16b0 [ 878.397738] cephconworkfn+0x326/0x750 [ 878.398121] processonework+0x188/0x3d0 [ 878.398522] ? pfxworkerthread+0x10/0x10 [ 878.398929] workerthread+0x2b5/0x3c0 [ 878.399310] ? pfxworkerthread+0x10/0x10 [ 878.399727] kthread+0xe1/0x120 [ 878.400031] ? pfxkthread+0x10/0x10 [ 878.400431] retfromfork+0x43/0x70 [ 878.400771] ? pfxkthread+0x10/0x10 [ 878.401127] retfromforkasm+0x1a/0x30 [ 878.401543] </TASK> [ 878.401760] Modules l ---truncated---

A flaw was found in the way signature calculation is handled by cephx protocol. The signature calculation is encrypting a 29 byte struct with 16-byte block AES cipher, and then using the first 8 bytes of the result as signature. This only covers first (16 by tes) cipher block, datacrc falls on second block.There are no known exploits against this, If attacker can alter the message payload any changes in datacrc will not be noticed or checked by signature check.

Ceph is a distributed object, block, and file storage platform. In versions up to and including 19.2.3, using the argument x-amz-copy-source to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack. As of time of publication, no known patched versions exist.

In Ceph, a format string flaw was found in the way libradosstriper parses input from user. A user could crash an application or service using the libradosstriper library.

A flaw was discovered in ceph. Assertion in rgwiampolicy.cc can be reached by user input and fail through data passed in from a rest call causing it to crash.

Upstream patch:

https://github.com/ceph/ceph/commit/b3118cabb8060a8cc6a01c4e8264cb18e7b1745a

Red Hat Ceph Storage is a scalable, open, software-defined storage platform that combines the most stable version of the Ceph storage system with a Ceph management platform, deployment utilities, and support services.Security Fix(es): ceph: Unauthenticated malformed HTTP requests handled by rgwcivetweb.cc:RGW::initenv() can lead to denial of service (CVE-2018-7262) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.