Una identidad de almacenamiento con permiso de lectura no debería alcanzar claves de cifrado ni credenciales administrativas de los hosts. En CVE-2026-50152, esa separación falló dentro del Ceph Monitor: cualquier entidad CephX con la capacidad mon allow r podía enviar una suscripción preparada y recibir todo el config-key store del clúster.
Red Hat asigna a la falla un CVSS 3.1 preliminar de 8.2, con vector CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L. El atacante necesita alcanzar la red del clúster y poseer una clave CephX válida con privilegios bajos, pero no depende de la interacción de otra persona. La documentación de Ceph afirma que un único mensaje MMonSubscribe preparado devuelve los secretos de forma determinista.
Quién está expuesto y qué versiones corrigen la falla
El aviso de Ceph declara vulnerables todas las versiones anteriores. Las correcciones están en las ramas todavía soportadas, Tentacle 20.2.4 o posterior y Squid 19.2.6 o posterior, ambas publicadas el 19 de agosto de 2026. Las versiones antiguas y sin soporte no tienen una versión corregida listada, por lo que permanecer en ellas no es una estrategia de mitigación.
- Condición de acceso: conectividad con el clúster y una identidad CephX válida
- Capacidad suficiente en el sistema vulnerable: mon allow r
- Interacción del usuario: ninguna
- Versiones corregidas: Tentacle 20.2.4+ y Squid 19.2.6+
- Versiones anteriores: consideradas vulnerables por el proyecto Ceph
- CWE: 862, ausencia de autorización
Cómo una suscripción se convierte en acceso a la bóveda
El Monitor procesa suscripciones para diferentes mapas y canales internos. Antes de la corrección, la verificación genérica de lectura del Monitor también aceptaba suscripciones cuyos nombres comenzaban con kv:, el prefijo usado por el config-key store. Tener mon allow r era suficiente para atravesar un límite de autorización que debería haber sido específico del repositorio de secretos.
} else if (p->first.starts_with("kv:")) {
if (!s->is_capable("config-key", MON_CAP_R)) {
dout(5) << __func__ << " " << op->get_req()->get_source_inst()
<< " not enough caps for " << p->first << " -- dropping"
<< dendl;
continue;
}
}El parche adelanta la decisión al registro de la suscripción y descarta la solicitud cuando falta la capacidad config-key. Ese detalle importa en una revisión de código: verificar la autorización solamente al entregar el dato puede dejar accesibles otras rutas de suscripción o efectos secundarios. El proyecto confirmó el vector mediante MMonSubscribe, pero no publicó los bytes del mensaje. Por eso no fabricamos un payload que parezca funcional sin poder verificarse.
El contenido de config-key cambia el impacto
El config-key store no guarda solamente configuración inofensiva. Ceph enumera passphrases LUKS de los OSD, secretos del dashboard y credenciales de gateways. En clústeres administrados por cephadm, también puede contener la clave SSH privada usada para autenticarse en todos los hosts gestionados. Una lectura indebida deja de ser solo una filtración cuando esa clave permite obtener acceso root en las máquinas del clúster.
CVSS describe la condición base, pero la configuración determina el radio de impacto. Un clúster sin cephadm tiene una cadena distinta de un entorno donde la misma clave SSH administra todos los nodos. El inventario de secretos, la reutilización de credenciales, el alcance de red y los registros de uso deben formar parte del análisis de impacto.
Cómo validar la exposición sin leer los secretos
La primera revisión no necesita reproducir la extracción. Confirma las versiones que realmente ejecutan los daemons y enumera solamente las capacidades del Monitor asignadas a las entidades. El comando siguiente descarta el campo de clave en el filtro y muestra solo el nombre y mon cap. La salida aun debe tratarse como información administrativa y recopilarse en una sesión controlada.
ceph versions --format json-pretty
ceph auth ls --format json |
jq -r '.auth_dump[]
| select(.caps.mon? != null)
| [.entity, .caps.mon]
| @tsv'Busca mon allow r, combinaciones como allow rw o allow rwx, allow * y perfiles que resulten en acceso de lectura. No consideres la ausencia de una identidad evidente como prueba de seguridad: cuentas de servicio, clientes de CephFS, integraciones de respaldo y credenciales antiguas pueden tener esta capacidad. La confirmación dinámica debe realizarse solo en un laboratorio aislado o durante un pentest autorizado, con permiso explícito para manipular el protocolo del Monitor.
Actualizar cierra la lectura, pero no invalida lo filtrado
Instalar Tentacle 20.2.4 o Squid 19.2.6 bloquea nuevas suscripciones sin la capacidad específica, pero no revoca un secreto ya obtenido. El propio proyecto recomienda rotar de inmediato la clave SSH de cephadm en clústeres administrados por esta herramienta. Para los demás secretos, la orientación es evaluar la exposición y seguir el procedimiento del producto o la integración correspondiente, preservando evidencias antes de cambiar el entorno cuando exista sospecha de abuso.
- Actualizar todos los daemons y confirmar que ningún Monitor permanezca en una versión vulnerable
- Inventariar identidades con cualquier capacidad de lectura en el Monitor y eliminar accesos innecesarios
- Rotar la clave SSH de cephadm y distribuir la nueva clave mediante el procedimiento oficial
- Mapear passphrases de OSD, secretos del dashboard y credenciales de gateway almacenados en config-key
- Revisar logs de autenticación, conexiones al Monitor y accesos SSH incompatibles con la operación esperada
- Preservar evidencias y ampliar la investigación a todos los hosts alcanzables mediante credenciales expuestas
- Migrar clústeres sin soporte a una rama que reciba correcciones de seguridad
Qué aporta esta falla al pentest de infraestructura
Permiso de lectura no es sinónimo de impacto bajo. En sistemas distribuidos, un principal aparentemente restringido puede consultar metadatos, suscribirse a canales internos o alcanzar bóvedas usadas por el plano de control. Un pentest de Ceph debe probar las capacidades efectivas de cada identidad, los límites del protocolo del Monitor y el destino de los secretos administrativos. La pregunta útil no es solo qué puede leer la cuenta. Es qué nuevas identidades puede asumir después de esa lectura.