Un vistazo en 30 segundos
- Ceph ha corregido cuatro CVE en Tentacle 20.2.4 y Squid 19.2.6, publicadas el 19 de agosto de 2026 y calificadas por el propio proyecto como hotfixes.
- El fallo de fondo está en CephX, el sistema con el que se autentican clientes y demonios del clúster: su cifrado AES-128-CBC no lleva autenticación, lo que permite manipular tickets y falsificar credenciales de administrador.
- La corrección introduce
aes256k, el primer tipo de clave nuevo en la historia de CephX. Instalar los paquetes no basta: hay que rotar las claves existentes.
- RGW suma dos problemas propios, en los tokens STS y en la verificación de firmas SigV4, con una advertencia específica para instalaciones multisite.
- Tras actualizar aparecerán avisos de salud nuevos. Es lo esperado: el clúster está señalando las claves que faltan por migrar.
Las actualizaciones de seguridad de un almacenamiento distribuido suelen resolverse instalando paquetes y reiniciando demonios en orden. Esta no. El 19 de agosto el proyecto Ceph publicó Squid 19.2.6 y Tentacle 20.2.4 con cuatro CVE corregidas, y una de ellas toca la pieza sobre la que se apoya todo lo demás: cómo se demuestran la identidad entre sí los componentes de un clúster Ceph.
La consecuencia práctica es que el mantenimiento tiene dos mitades. La primera es el upgrade de siempre. La segunda es una migración de credenciales que, según cómo esté desplegado tu clúster y cuántos clientes externos tenga, puede llevar bastante más tiempo que la primera.
Qué se ha roto exactamente en CephX
CephX es el protocolo con el que Ceph comprueba quién es quién. Los monitores emiten tickets cifrados, los clientes los presentan a los OSD, los MDS y el resto de demonios, y ese ticket lleva dentro el ámbito de permisos de la entidad que lo usa.
El problema, documentado por el proyecto en el aviso de CVE-2025-30156, es que ese cifrado emplea AES-128-CBC sin autenticar, sin HMAC y con un vector de inicialización fijo escrito en el código. De ahí salen dos consecuencias, y la segunda es la grave:
- Dos textos en claro idénticos producen exactamente el mismo criptograma, con la fuga de información que eso implica.
- El criptograma es maleable. Se pueden alterar bits, cambiar los datos que hay debajo y nada detecta la manipulación. En palabras del propio aviso, un atacante puede «flip bits in the ciphertext, change the underlying data, and nothing catches it».
El ataque concreto que describe la documentación consiste en tocar el campo allow_all dentro de la estructura AuthTicket cifrada. Cambiando bits en el sitio adecuado, una credencial de pocos permisos se convierte en una credencial administrativa sin que el clúster note nada raro.
Conviene poner el listón donde está: el atacante necesita una clave CephX válida de bajos privilegios y acceso a la red del clúster. No es algo que se dispare desde internet contra un puerto expuesto. Pero esa barrera es baja en cuanto entregas credenciales a terceros, y ahí está la diferencia real de urgencia entre un clúster que administra una sola persona y una plataforma multitenant donde cada cliente tiene su llave.
Las cuatro vulnerabilidades
| CVE | Componente | Problema |
|---|
| CVE-2025-30156 | CephX | Bypass de autenticación por mal uso de AES-CBC (sin HMAC, IV fijo) |
| CVE-2026-39944 | RGW STS | Verificación criptográfica incorrecta de los tokens de sesión |
| CVE-2026-50152 | Ceph Monitor | Autorización incorrecta en el manejador de suscripciones |
| CVE-2026-54330 | RGW SigV4 | Verificación incorrecta de firmas SigV4 |
Las versiones corregidas son Tentacle 20.2.4 y posteriores y Squid 19.2.6 y posteriores. Para CVE-2025-30156, el aviso considera afectada cualquier versión anterior de Ceph que use credenciales de tipo aes, que hasta ahora eran todas.
aes256k: el primer tipo de clave nuevo de CephX
Aquí está lo que convierte esto en algo más que un parche. Arreglar la maleabilidad del cifrado no se puede hacer sin cambiar el formato de las credenciales, así que Ceph ha introducido un tipo de clave nuevo, aes256k, y es la primera vez que lo hace.
Detrás hay AES256-CTS-HMAC-SHA384-192, un esquema basado en el RFC 8009 que trae justo lo que faltaba:
- Un confundidor aleatorio de 128 bits en cada operación, con lo que dos mensajes iguales dejan de cifrarse igual.
- Autenticación del mensaje mediante HMAC-SHA384, que es lo que detecta cualquier bit tocado.
- Cifrado con robo de espacio (CTS) para cerrar los ataques de oráculo de relleno.
- Números de uso de clave, para separar correctamente los distintos usos de un mismo material criptográfico.
Las instalaciones nuevas ya nacen con el tipo seguro. Las que ya existen mantienen de entrada compatibilidad con las claves antiguas, porque de lo contrario la actualización rompería a todos los clientes de golpe. Esa compatibilidad es la que permite migrar por fases, y también la razón por la que el clúster va a quejarse hasta que termines.
Actualizar y ver alertas no significa que algo haya fallado
Después de instalar las nuevas versiones aparecerán seis avisos y errores de salud nuevos, y el propio anuncio lo dice sin rodeos: «This is normal». Están ahí precisamente para localizar lo que sigue usando el mecanismo viejo.
Dos que verás seguro:
AUTH_INSECURE_SERVICE_KEY_TYPE: credenciales de demonios y servicios que aún usan un tipo de clave considerado inseguro.AUTH_INSECURE_CLIENT_KEY_TYPE: lo mismo para las credenciales de clientes.
Si tienes monitorización enganchada al estado de salud del clúster —y deberías—, cuenta con que va a saltar. Merece la pena avisar antes al equipo de guardia de que un HEALTH_WARN tras la ventana de mantenimiento forma parte del plan y no es motivo de dar marcha atrás.
Quién rota las claves por ti y quién no
El procedimiento depende de cómo esté desplegado el clúster, y esta es la parte que conviene mirar antes de tocar nada:
- Cephadm automatiza la rotación de las claves de los demonios durante la actualización. A cambio, el propio proyecto avisa de que «Cephadm spends more time than normal on the upgrade», así que dimensiona la ventana con holgura. Lo que generalmente no gestiona son las credenciales de los clientes.
- Rook automatiza también parte del trabajo, incluida la rotación de algunas claves de cliente, con excepciones concretas que hay que revisar en su documentación.
- Instalaciones por paquetes: procedimiento manual. Habilitar
aes256k, establecerlo como cifrado preferente, rotar las credenciales de los servicios y después las de los clientes que ya soporten el tipo nuevo.
En los tres casos, las credenciales que has repartido fuera del clúster son responsabilidad tuya. Si tienes un inventario de a quién le diste qué clave CephX, este es el momento en que agradeces haberlo mantenido. Si no lo tienes, este es el momento de hacerlo.
El freno está en los clientes del kernel
Hay una dependencia que puede marcar el ritmo de toda la migración: el cliente de Ceph que va dentro del kernel de Linux, el que usan las máquinas que montan RBD o CephFS directamente.
El soporte de aes256k en ese cliente empezó en Linux 7.0, aunque existen backports para CentOS Stream 9 y 10. Antes de rotar la clave que usa una máquina que monta CephFS por kernel, comprueba dos cosas: qué kernel corre y si tu distribución ha incorporado el soporte en sus propios paquetes, porque la versión que reporta uname -r no cuenta toda la historia cuando hay backports de por medio. En un parque razonablemente actualizado esto no debería doler, pero si arrastras servidores anclados a un kernel antiguo por drivers o por certificaciones, ahí tienes tu cuello de botella.
La compatibilidad hacia atrás te deja mantener las claves viejas en esos sistemas mientras resuelves el asunto. El precio es que las advertencias de seguridad seguirán encendidas, y no es mal precio: al menos sabes exactamente qué te queda pendiente en lugar de dar por cerrada una migración a medias.
RGW: tokens, firmas y una trampa en multisite
Si usas Ceph como almacenamiento de objetos compatible con S3 mediante RADOS Gateway, la actualización te toca por partida doble.
CVE-2026-39944 afecta a los tokens de sesión STS, los que emite RGW cuando una aplicación asume un rol temporal en lugar de usar credenciales fijas. Comparte parte de su origen criptográfico con el fallo de CephX, así que la lógica es la misma: instalar el parche no invalida por arte de magia los tokens ya emitidos, hay que revisarlos y completar su migración al esquema nuevo.
CVE-2026-54330 va por las firmas SigV4. Tras la corrección, RGW rechaza las peticiones cuyos encabezados host y x-amz- no estén correctamente incluidos en el conjunto firmado. Aquí hay que ser honesto sobre el riesgo de regresión: si alguna herramienta o SDK antiguo de tu casa firma de forma laxa, va a empezar a recibir errores. Mejor descubrirlo en preproducción que a las nueve de la mañana del lunes.
Y una advertencia que no conviene saltarse en instalaciones multisite: el cliente REST que usaba Ceph para la sincronización entre zonas genera peticiones que ahora serían rechazadas. La recomendación del proyecto es poner rgw_sigv4_insecure=true antes de empezar la actualización multisite y devolverlo a false cuando todos los clústeres estén actualizados. Si te lo saltas, la replicación entre zonas se te para en mitad del proceso.
El monitor y los secretos que guarda
CVE-2026-50152 es un fallo de autorización en el manejador de suscripciones del Monitor. Más allá del parche, el proyecto pide algo que se olvida con facilidad: valorar si los secretos almacenados han podido quedar expuestos. En instalaciones gestionadas con cephadm, la recomendación concreta es rotar la clave SSH que ese sistema usa para llegar a los nodos. La guía completa para rotar el resto de secretos todavía estaba pendiente cuando salió el aviso, así que este apartado conviene revisarlo de nuevo dentro de unas semanas.
Cómo plantearíamos la ventana
Si tuviéramos que ordenar el trabajo en un clúster de producción, iría más o menos así:
- Inventario primero. Qué versión corres, cómo está desplegado (cephadm, Rook o paquetes), cuántas credenciales de cliente hay repartidas y qué kernel tiene cada máquina que monta RBD o CephFS.
- Multisite, si lo hay:
rgw_sigv4_insecure=true antes de empezar.
- Actualizar a 20.2.4 o 19.2.6 según rama, avisando a monitorización de que van a saltar avisos de salud.
- Rotar claves de servicios, automáticamente con cephadm o a mano según el caso.
- Rotar claves de cliente por tandas, empezando por las que sabes compatibles y dejando para el final las que dependen de un kernel por actualizar.
- Rotar la clave SSH de cephadm y revisar el resto de secretos por lo de CVE-2026-50152.
- Volver
rgw_sigv4_insecure a false cuando todos los clústeres estén al día, y comprobar que los avisos de salud se han apagado.
Para instalaciones que corren una rama vieja, la recomendación práctica es planificar el salto a una rama mantenida en lugar de esperar a que aparezcan backports de todo esto. En una pieza tan sensible como la autenticación del clúster, quedarse fuera de soporte deja de ser una decisión de presupuesto.
Merece la pena, además, aprovechar la ventana para lo de siempre: comprobar que las copias del clúster se restauran de verdad, que el acceso administrativo está limitado y que sabes quién tiene credenciales. Es el mismo trabajo aburrido que hay detrás de mandar los backups fuera de sitio o de cerrar el acceso a un hipervisor, y es el que marca la diferencia cuando el aviso llega en agosto y hay media plantilla de vacaciones.
Lo que esto dice del almacenamiento propio
Ceph es una pieza excelente, y precisamente por eso este caso es interesante. La vulnerabilidad de CephX llevaba años ahí, en un componente que casi nadie mira porque «simplemente funciona», y ha hecho falta un cambio de formato de credenciales para cerrarla del todo. Ese trabajo —leer el aviso, montar el inventario, planificar la ventana, perseguir los kernels rezagados, verificar que ningún cliente se ha quedado colgado— es el coste real de operar almacenamiento distribuido en casa. No lo decimos para desanimar a nadie: para muchas organizaciones ese coste compensa de sobra frente a la factura y la dependencia de un hiperescalar, y hay alternativas mucho más ligeras cuando la escala no da para Ceph, como los servidores S3 en un solo binario.
Pero hay que contarlo entero. Un clúster Ceph no es software que se instala, es una plataforma que alguien tiene que operar, con guardias, con inventario de credenciales y con capacidad de reaccionar a un aviso urgente en agosto.
Si tienes almacenamiento distribuido en producción y esa parte te queda grande, o si estás valorando montarlo y prefieres que la operación —parches, ventanas, rotación de credenciales, quién responde a las tres de la mañana— la lleve alguien con equipo detrás, echa un vistazo a nuestras páginas de almacenamiento de objetos y servicios gestionados, o cuéntanos qué tienes montado.
Preguntas frecuentes
¿Qué versiones de Ceph corrigen estas vulnerabilidades?
Tentacle 20.2.4 y Squid 19.2.6, publicadas el 19 de agosto de 2026, y cualquier versión posterior de esas ramas.
¿Basta con actualizar los paquetes?
En clústeres ya existentes, no. CVE-2025-30156 introduce el tipo de clave aes256k, así que después del upgrade hay que revisar y rotar las credenciales CephX siguiendo el procedimiento del proyecto. Las instalaciones nuevas sí nacen ya con el tipo seguro.
¿Cephadm rota todas las claves automáticamente?
Las de los demonios sí, durante la actualización, y por eso el proceso tarda más de lo habitual. Las credenciales de clientes generalmente no las gestiona. Rook automatiza también algunas claves de cliente, con excepciones que conviene mirar en su documentación.
¿Se puede atacar un clúster Ceph desde internet con CVE-2025-30156?
El escenario documentado necesita una clave CephX válida de bajos privilegios y acceso a la red del clúster. La exposición importa sobre todo donde se reparten credenciales a usuarios, tenants o sistemas externos.
¿Por qué me salen avisos de salud después de actualizar?
Porque se han añadido seis estados de salud nuevos que detectan credenciales pendientes de migrar, como AUTH_INSECURE_SERVICE_KEY_TYPE y AUTH_INSECURE_CLIENT_KEY_TYPE. Es el comportamiento esperado y se apagan a medida que rotas las claves.
Tengo máquinas que montan CephFS por kernel, ¿me va a romper?
Depende del kernel. El soporte de aes256k en el cliente del kernel empezó en Linux 7.0, con backports disponibles para CentOS Stream 9 y 10. Comprueba también si tu distribución lo ha incorporado por su cuenta antes de rotar esas claves, y deja esos sistemas con la clave antigua mientras tanto si hace falta.
¿Y si tengo RGW en multisite?
Pon rgw_sigv4_insecure=true antes de empezar la actualización y devuélvelo a false cuando todos los clústeres estén actualizados. Si no, el cliente REST de la sincronización entre zonas genera peticiones que la nueva verificación SigV4 rechaza.
Fuentes
