Tres vulnerabilidades críticas en runC afectan a Docker y Kubernetes

CyberSecureFox 🦊

Tres vulnerabilidades críticas en runC —el runtime de referencia de la Open Container Initiative (OCI) utilizado por Docker, containerd y Kubernetes— podrían permitir a un atacante escribir en el sistema anfitrión con privilegios root, provocando un escape de contenedor. Las fallas, identificadas como CVE-2025-31133, CVE-2025-52565 y CVE-2025-52881, fueron informadas por Aleksa Sarai (SUSE, consejo de la OCI) y ya cuentan con parches disponibles.

runC bajo la lupa: qué se descubrió y por qué importa

RunC es el componente que realiza las operaciones de bajo nivel al iniciar contenedores: crea namespaces de Linux, monta sistemas de archivos, configura cgroups y aplica aislamientos. Un error en este nivel compromete la separación entre el contenedor y el host, con un efecto sistémico en plataformas cloud-native. Según la notificación del mantenedor, dos de las vulnerabilidades afectan a todas las versiones de runC, mientras que la restante impacta a compilaciones desde 1.0.0-rc3.

Versiones afectadas y parches disponibles

Los fallos quedan mitigados en runC 1.2.8, 1.3.3 y 1.4.0-rc.3 (y posteriores). Se recomienda actualizar con urgencia a través del gestor del sistema o del orquestador (Docker Engine, containerd o la distribución de Kubernetes), ya que runC suele llegar como dependencia.

Impacto real: del contenedor al host con privilegios root

La explotación viable permitiría escritura en el host con permisos elevados, rompiendo el modelo de seguridad de contenedores. De acuerdo con análisis de telemetría de runtime publicados por la industria, el atacante suele requerir la capacidad de lanzar contenedores con montajes personalizados y combinaciones peligrosas de opciones en el Dockerfile o en definiciones de Pods. Esto encaja con técnicas conocidas: abuso de symlinks, condiciones de carrera en operaciones de montaje y copia de archivos entre el contenedor y el host.

Indicadores de compromiso y señales de explotación

Hasta la fecha no hay reportes públicos de explotación activa. No obstante, es prudente vigilar actividad anómala con enlaces simbólicos, montajes no estándar, intentos de escritura fuera de las rutas esperadas y cualquier acceso inesperado a hostPath. La monitorización a nivel de sistema de archivos y llamadas al kernel ayuda a detectar intentos de bypass del aislamiento.

Mitigación inmediata para Docker, containerd y Kubernetes

1) Actualizar ya runC a 1.2.8/1.3.3/1.4.0-rc.3 o superior. Verificar que el motor de contenedores y las imágenes base aplican la versión corregida.

2) Activar user namespaces para impedir que el root del contenedor se mapee al root del host. Este aislamiento, apoyado en el control de acceso discrecional (DAC) de Unix, bloquea rutas críticas de escalada.

3) Preferir ejecución rootless. Los contenedores rootless reducen drásticamente el impacto, al no otorgar privilegios administrativos en el host a los procesos del contenedor.

4) Restringir políticas riesgosas: minimizar contenedores privilegiados, limitar hostPath, evitar CAP_SYS_ADMIN y opciones de montaje peligrosas. En Kubernetes, aplicar Pod Security Admission, perfiles seccomp y AppArmor, y usar root filesystem read-only cuando sea viable.

5) Fortalecer la observabilidad: habilitar detecciones de symlink traversal y montajes sospechosos en EDR/Runtime Security. Endurecer la cadena de suministro con firmas de imágenes, SBOM y verificación de artefactos.

Contexto y antecedentes: riesgos en entornos cloud-native

Las vulnerabilidades en runC tienen un impacto transversal porque este runtime es ubicuo en stacks de contenedores. El precedente más citado es CVE-2019-5736, que demostró que un fallo en el runtime puede derivar en sobrescritura de binarios y comprometer al host. Desde entonces, las mejores prácticas recomiendan mínimos privilegios, control de montajes y validación continua de imágenes. Informes de la CNCF y proveedores de seguridad coinciden en que la amplia adopción de Kubernetes multiplica la superficie de ataque si no se aplican defensas por capas.

El riesgo es gestionable si se actúa con rapidez: aplicar los parches de runC, habilitar user namespaces, adoptar ejecución rootless donde sea posible y reforzar políticas y monitoreo en Kubernetes y CI/CD. Actualiza hoy, elimina configuraciones permisivas y establece controles de integridad; reducirás de forma significativa la probabilidad de un escape de contenedor y sus consecuencias operativas.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.