Vulnerabilidad 9.9 en OpenShift Virtualization permite a un usuario de un namespace tomar el control del host (CVE-2026-7374)
La brecha en el virt-handler de KubeVirt permite que un usuario con permisos de edición en un único namespace secuestre el socket de CRI-O y comprometa todo el nodo. Red Hat ha publicado parches para las líneas a partir de la versión 4.12.
Un usuario con permisos de edición en un único namespace de OpenShift puede escapar al host y comprometer todo el nodo. Red Hat divulgó el 26 de mayo la CVE-2026-7374, una falla en el componente virt-handler de KubeVirt que sostiene OpenShift Virtualization (anteriormente Container Native Virtualization), con una puntuación de 9.9 en el CVSS, a un décimo del máximo de la escala.
La ruptura de la frontera entre namespace y host
El problema radica en una validación laxa de symlink en el momento en que el virt-handler se conecta a los sockets de consola de las máquinas virtuales. Según el registro de Red Hat, un usuario autenticado de OpenShift con permiso de edición en un namespace puede sustituir el socket de consola por un enlace simbólico que apunta al socket del runtime de contenedores del host, el CRI-O. Al hacerlo, secuestra la conexión privilegiada del virt-handler y logra acceder a cualquier socket Unix del host, lo que allana el camino para el control completo del nodo. La clasificación es CWE-787 por resolución inapropiada de enlace antes del acceso al archivo, el antiguo problema de seguir un atajo sin verificar a dónde apunta.
El vector explica por qué la puntuación llega a 9.9. El ataque proviene de la red (AV:N), tiene baja complejidad (AC:L), solo requiere privilegios bajos (PR:L) y ninguna interacción del usuario (UI:N). El punto decisivo es el alcance alterado (S:C): la explotación comienza dentro de un namespace y termina fuera de él, en el host. La confidencialidad, integridad y disponibilidad caen todas a un impacto alto. En un clúster multitenencia, esto significa que la credencial de menor privilegio dentro de un espacio aislado se convierte en la llave de todo el piso.
Lo que asusta en el arreglo es el tamaño del prerequisito. No se trata de ser administrador del clúster ni de acceso al plano de control: solo se necesita un permiso de edición en un namespace, el nivel que se otorga a los equipos de desarrollo para gestionar sus propias máquinas virtuales. En clústeres que albergan decenas de equipos, la población que cumple esta condición es amplia, y cada cuenta de servicio con este derecho se convierte en un vector. El ataque tampoco requiere suerte de tiempo ni ingeniería social, ya que el vector marca interacción de usuario nula.
Por qué esto afecta a quienes salieron de VMware
El tiempo importa. Desde que Broadcom reposicionó la licencia de VMware en paquetes de suscripción más caros, una ola de empresas salió en busca de alternativas, y OpenShift Virtualization se ha consolidado como uno de los destinos para ejecutar máquinas virtuales junto a contenedores en la misma plataforma. La promesa central de esta migración es la consolidación con aislamiento: varios equipos, o varios clientes, compartiendo el mismo clúster bajo fronteras de namespace.
La CVE-2026-7374 apunta exactamente a esta promesa. Un bug que parte de un namespace y llega al host no es un detalle técnico: es la anulación del modelo multitenencia que justifica la consolidación. Los parches se han publicado en una serie de avisos de Red Hat, entre ellos RHSA-2026:20720, RHSA-2026:20736, RHSA-2026:20763 y RHSA-2026:20782, cubriendo las líneas afectadas a partir de la versión 4.12.
Lo que cambia para Brasil
La migración fuera de VMware no es abstracta aquí. Bancos, operadores de telecomunicaciones, minoristas de gran tamaño y la administración pública concentran enormes stock de máquinas virtuales y están entre los que más han sentido el ajuste de licencias. Para estas organizaciones, OpenShift Virtualization ha entrado en la conversación como una ruta de salida, y algunas de ellas ya están ejecutando cargas en producción sobre él.
Para un banco que trasladó sistemas internos a clústeres compartidos, la lectura es directa: la cantidad de equipos y proveedores con acceso de edición a algún namespace suele ser grande, y cada una de estas identidades pasó, de la noche a la mañana, a tener un camino teórico hasta el host. El riesgo no es el atacante externo anónimo; es el insider, el subcontratista o las credenciales filtradas de bajo privilegio que de repente valen mucho más de lo que aparentaban.
La respuesta sensata combina el parche con una revisión de quién realmente necesita permiso de edición en cada namespace. La migración lejos de un hipervisor costoso ha dado como resultado un ahorro en licencias; lo que esta falla recuerda es que la factura de seguridad de la nueva plataforma se presenta en otra moneda, la del rigor sobre quién puede tocar qué dentro del clúster.