Post cover image

August 19, 2026

Rook Advisory for Ceph CVE-2025-30156

Ceph today announced security vulnerability CVE-2025–30156 impacting all Ceph clusters, including Rook clusters.

By Blaine Gardner

5 min read

Rook users are advised to follow the Quick Resolution Guide below as soon as possible to resolve the vulnerability.

More background information on the CVE is present after the resolution guide for interested readers.

Quick Resolution Guide

Follow these instructions to resolve CVE-2025–30156 as quickly as possible with minimal risk.

  1. Following Rook upgrade docs, upgrade to Rook v1.20.5 or higher (or v1.19.9 or higher)
  2. Upgrade to Ceph v20.2.4 or higher (or v19.2.6 or higher)
  3. Initiate key rotation for the keys you wish to rotate

Steps 2 and 3 can be done at once by applying the patch below to any CephCluster that hasn't already rotated CephX keys. This will rotate the required keys to resolve the CVE. PVCs will remain active throughout this process.

spec:
  cephVersion:
    image: quay.io/ceph/ceph:v20.2.4-20260818
  security:
    cephx:
      daemon:
        keyRotationPolicy: KeyGeneration
        keyGeneration: 2 # must be greater than the current keyGeneration

Update the patch to use Ceph v19.2.6–20260818 if needed for your environment.

Ceph health warnings will be present during rotation and while any key remains using AES. These warnings can be ignored or muted for now.

Ceph health errors will be present after the Ceph version is updated and while key rotation is still unfinished. These errors should resolve after the CephCluster is done upgrading. If any of the following errors persist for more than a few minutes after upgrade and rotation, file a GitHub issue or reach out on Rook's Slack for assistance:

  • AUTH_INSECURE_SERVICE_KEY_TYPE
  • AUTH_INSECURE_SERVICE_TICKETS

Following Rook's CephX key rotation documentation, use the CephCluster status.cephx to double check that keys are rotated. An example CephCluster cephx status is shown below, with some comments to help check at a glance.

    # ...
    "cephx": {
      "admin": {
        "keyCephVersion": "20.2.4-0",  # SHOULD MATCH CEPH VERSION
        "keyGeneration": 2
      },
      "cephExporter": {
        "keyCephVersion": "20.2.4-0",
        "keyGeneration": 2
      },
      "crashCollector": {
        "keyCephVersion": "20.2.4-0",
        "keyGeneration": 2
      },
      "csi": {
        "keyCephVersion": "19.2.4-0",  # EXAMPLE, WILL NOT MATCH CEPH VERSION
        "keyGeneration": 1,  # MAY BE ZERO
      },
      "mgr": {
        "keyCephVersion": "20.2.4-0",  # SHOULD MATCH CEPH VERSION
        "keyGeneration": 2,
        "keyType": "aes256k"
      },
      "mon": {
        "keyCephVersion": "20.2.4-0",  # SHOULD MATCH CEPH VERSION
        "keyGeneration": 2
      },
      "osd": {
        "keyCephVersion": "20.2.4-0",  # SHOULD MATCH CEPH VERSION
        "keyGeneration": 2,
        "keyType": "aes256k"
      },
      "rbdMirrorPeer": {
        "keyCephVersion": "19.2.4-0",  # EXAMPLE, WILL NOT MATCH CEPH VERSION
        "keyGeneration": 1  # MAY BE ZERO
      }
    },
    # ...

CephFilesystem users should check its staus.cephx as well.

    # ...
    "cephx": {
      "daemon": {
        "keyCephVersion": "20.2.4-0",  # SHOULD MATCH CEPH VERSION
        "keyGeneration": 2,
        "keyType": "aes256k"
      }
    },
    # ...

After this process is complete and verified, the CVE is resolved. It will no longer be possible to elevate the permissions of a CephX key. CephX authentication keys for core Ceph daemons, child Ceph daemons (e.g., RGW), and Rook's admin key will have been rotated to the new AES256K cipher.

Non-urgent follow-up tasks

Do not rush to perform further steps._ Additional key rotations have prerequisites and caveats that are important to understand before proceeding. As long as the process above is completed, cluster security is not immediately vulnerable. Take your time._

Some Ceph health warnings (not errors) are likely to persist after this process. Rook's CephX key warnings documentation explains how to interpret, manage, and (if desired) mute them.

Ceph developers recommend that users rotate remaining CephX client authentication keys to the latest and most secure AES256K keys when possible to ensure their clusters have the best security.

For Rook users, review official CephX key rotation documentation to understand how to rotate authentication keys for CSI daemons, CephClients, and RBD-Mirror peers.

An optional, technical overview of the CVE follows, along with recommended Mitigations for users who are not able to resolve the CVE immediately.

Background

Ceph uses a custom implementation of Kerberos for securing communication between Ceph daemons and clients. This security implementation is called CephX, which (by design) most Rook users are unlikely to be familiar with. Rook keeps CephX details abstracted from most end users to avoid unnecessary complexity.

In order to understand the vulnerability and its resolution, we can provide a simplified view of how Ceph authentication works. This explanation is sufficient for basic understanding of the vulnerability and resolution but does not dive into technical nuances and caveats.

There are two sets of CephX keys in a Ceph cluster: authentication keys and service tickets. Authentication keys are used by Ceph entities (daemons and clients) to establish identity when first connecting to the Ceph cluster. Once an entity is authenticated, it is issued a series of encrypted service tickets that define its authorizations for the four core Ceph daemons: monitors, managers, OSDs, and filesystem MDses. Entities do not have keys to decrypt their service tickets, a second layer of security.

When a component communicates with any Ceph daemon, it includes its relevant service tickets in network packets. This allows core Ceph daemons to validate client entities in a decentralized manner.

Vulnerability Overview

CVE-2025–30156 affects the previously mentioned service tickets. The existing AES service tickets do not effectively implement integrity checks and can have their permissions modified without detection, even without decrypting the AES-secured ticket.

An attacker who is able to (through other methods) gain access to a CephX key and masquerade as a Ceph entity would be able to iteratively flip bits in the AES service ticket payload to attempt to gain elevated Ceph permissions. With this workflow, an attacker would be able to obtain admin-privileged permissions over the Ceph cluster in linear time.

Resolution Overview

To resolve this CVE, Ceph has introduced a new CephX key type for both authentication keys as well as service tickets. The new key type cipher is called AES256K. In order to resolve the CVE, Ceph must be upgraded, and CephX authentication keys for four core Ceph daemons must be migrated to the new key type. In Rook terms, CephCluster monitors, managers, and OSDs; and CephFilesystem MDSes must migrate.

Once these critical migrations are complete, all Ceph service tickets will use AES256K encryption. Any other Ceph client entities that continue using older AES authentication keys will receive new AES256K-encrypted service tickets. Thus, it will no longer be possible for any arbitrary CephX key to be elevated to have admin permissions.

Rook and Ceph anticipate that most users will need to continue using older AES authentication keys for non-core clients during a transition period in order to avoid storage service outages. This transition period may last years for organizations with large or complex environments.

IMPORTANT:_ CSI keys require Linux kernel version 7.0 or higher for AES256K authentication key support. Older kernels can still use AES authentication keys safely after Ceph is upgraded to issue AES256K service tickets._

Mitigations

This vulnerability is a good reminder of how important it is to ensure security at every layer to minimize the ability for any malicious actors to gain access where they shouldn't. Below are some mitigations to consider in all production environments, especially those where the upgrade outlined above cannot be done immediately:

  • Avoid deploying privileged pods whenever possible.
  • Drop NET_RAW permissions from pods whenever possible.
  • When keys can't yet be upgraded to AES256K, use Rook's key rotation API to rotate AES keys regularly. Rotating keys during any Ceph or Rook version update is a good starting point.
  • Use Kubernetes Network Policies. Rook's experimental policies can be found here.
  • Consider enabling full over-the-wire Ceph network encryption via ms_client_mode options. Be advised of performance effects.
  • Ensure networking environments are resilient to ARP spoofing attempts.
  • Use an immutable, container-optimized OS on Kubernetes nodes.
  • Keep up-to-date on all security updates for applications running in the Kubernetes cluster as well as applications on the same network.
  • Review Kubernetes Cluster Security recommendations.

There are more mitigations than we could possibly cover in one article. If community members have more hardening advice, reach out on Slack or GitHub Discussions.