Bajada
Docker confirmó la mitigación de CVE-2026-28400, una inyección de flags en Model Runner que podía permitir sobrescritura de archivos desde contenedores y pérdida operativa severa. La corrección quedó incluida desde Docker Desktop 4.62.0 y versiones posteriores de Model Runner.
Introducción
La adopción de capacidades de IA dentro del flujo de desarrollo está moviendo nuevas superficies de ataque hacia herramientas que antes no se consideraban críticas para seguridad operativa. En ese contexto, Docker publicó una actualización de seguridad para Docker Desktop que corrige CVE-2026-28400, una vulnerabilidad en Docker Model Runner.
Aunque el CVE fue divulgado semanas atrás, su impacto sigue siendo relevante para equipos de plataforma y seguridad porque combina tres factores frecuentes en entornos modernos: servicios auxiliares habilitados por defecto, conectividad entre contenedores y APIs internas sin autenticación fuerte. Para organizaciones que usan Docker Desktop como entorno de desarrollo o preproducción, el riesgo no es teórico: puede derivar en pérdida de datos locales, interrupción del trabajo y exposición de rutas hacia escenarios más graves.
Qué ocurrió
Según el advisory de GitHub Security para docker/model-runner, versiones anteriores a 1.0.16 exponían el endpoint `POST /engines/_configure` sin autenticación. Ese endpoint aceptaba flags de runtime que se pasaban directamente a `llama.cpp`, el motor de inferencia subyacente.
El problema central es que un atacante con acceso de red al servicio podía inyectar parámetros como `–log-file` para forzar escritura o sobrescritura de archivos accesibles por el proceso de Model Runner. En despliegues de Docker Desktop, donde Model Runner estaba habilitado por defecto desde 4.46.0, el servicio era alcanzable desde contenedores por `model-runner.docker.internal`.
Docker indicó que la corrección quedó en Model Runner 1.0.16 y que Docker Desktop 4.61.0+ ya incorpora el fix. Además, la página de anuncios de seguridad de Docker documenta explícitamente CVE-2026-28400 como corregido en la rama 4.62.0.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para perfiles DevOps/SRE, el impacto más inmediato no es un «RCE remoto masivo» sino una combinación de degradación operacional y daño al estado local del entorno. El advisory menciona que la sobrescritura podía apuntar al disco de la VM de Docker Desktop (`Docker.raw`), afectando contenedores, imágenes, volúmenes e historial de builds.
Ese tipo de impacto es especialmente costoso en equipos con pipelines locales de validación, pruebas de integración, demos técnicas o ingeniería de plataforma que reutiliza entornos Desktop para reproducir incidentes. La pérdida del estado implica horas de recomposición, recacheo y reinstalación.
Además, en configuraciones específicas y con interacción del usuario, la vulnerabilidad podía escalar hacia escenarios de escape de contenedor. Aunque no sea el caso por defecto en todos los equipos, es una señal clara de que los servicios de soporte a IA deben entrar en el mismo modelo de hardening que ya aplicamos a registries, runners y motores de build.
Detalles técnicos
Desde la perspectiva técnica, CVE-2026-28400 encaja en un patrón de «control plane auxiliar sin frontera de confianza». El endpoint vulnerable recibía argumentos de ejecución sin validación suficiente y sin autenticación previa, habilitando abuso de funcionalidades legítimas.
Puntos técnicos relevantes para análisis interno:
– Vector de acceso: conectividad desde contenedores al hostname interno de Model Runner.
– Superficie vulnerable: endpoint de configuración runtime (`/engines/_configure`).
– Efecto primario: sobrescritura de archivos por inyección de flags.
– Consecuencia operativa documentada: corrupción o destrucción del estado de Docker Desktop.
– Mitigación adicional: Enhanced Container Isolation (ECI) bloquea acceso desde contenedores al servicio, aunque Docker advierte que exposiciones por TCP localhost en configuraciones particulares pueden seguir siendo explotables.
La lección práctica para platform teams es que no alcanza con «parchear cuando haya CVE»: también hay que revisar qué features quedaron habilitadas por defecto después de upgrades y qué servicios internos quedaron accesibles entre namespaces de ejecución.
Qué deberían hacer los administradores o equipos técnicos
1. **Actualizar baseline**: verificar que todos los equipos estén en Docker Desktop 4.62.0 o superior (mínimo 4.61.0 con Model Runner corregido).
2. **Inventariar exposición**: validar si `model-runner.docker.internal` está accesible desde contenedores en perfiles corporativos.
3. **Habilitar ECI donde aplique**: usar Enhanced Container Isolation como control de contención adicional.
4. **Revisar hardening de desktop engineering**: incluir servicios de IA local en checklists de seguridad junto con daemon socket, extensiones y secretos.
5. **Agregar detección**: monitorear actividad inusual sobre endpoints de configuración runtime y cambios inesperados en archivos críticos de la VM.
6. **Plan de recuperación**: documentar restore rápido de imágenes/volúmenes para minimizar MTTR si un entorno queda corrupto.
Conclusión
La corrección de CVE-2026-28400 refuerza una tendencia: las funciones «inteligentes» integradas al toolchain también son infraestructura operativa y deben tratarse como tal. Para equipos DevOps, la decisión no es solo actualizar por cumplimiento, sino ajustar controles de aislamiento y exposición de servicios auxiliares.
En términos prácticos, este caso muestra que una API interna aparentemente menor puede convertirse en vector de pérdida de disponibilidad y de continuidad de trabajo técnico. Mantener versiones al día, limitar conectividad lateral y formalizar hardening en estaciones de ingeniería ya no es opcional: es parte del posture base de plataforma.
## Fuentes
– https://docs.docker.com/security/security-announcements/
– https://github.com/docker/model-runner/security/advisories/GHSA-m456-c56c-hh5c
– https://nvd.nist.gov/vuln/detail/CVE-2026-28400