Bajada: Docker publicó correcciones de seguridad en Desktop 4.62.0 para dos vulnerabilidades (CVE-2026-28400 y CVE-2026-2664) con impacto directo en estaciones de desarrollo, pipelines locales y entornos con contenedores no confiables.
Introducción
Docker Desktop sigue siendo una pieza central en los flujos de trabajo de desarrollo y DevOps, sobre todo en equipos que combinan CI/CD en la nube con pruebas y build local. Por eso, cuando aparece una vulnerabilidad en componentes que viven dentro del runtime local, el riesgo no queda limitado al endpoint de un desarrollador: puede escalar hacia secretos, artefactos, imágenes internas y hasta afectar la confiabilidad de los builds que luego se promueven a producción.
En su ciclo de febrero, Docker confirmó y corrigió dos fallas en Docker Desktop 4.62.0: CVE-2026-28400 (inyección de flags en Docker Model Runner) y CVE-2026-2664 (lectura fuera de límites en grpcfuse). Aunque ambos bugs tienen vectores distintos, comparten una conclusión operativa: las estaciones de trabajo de ingeniería deben tratarse como infraestructura crítica y no solo como “entornos de desarrollo”.
Qué ocurrió
Docker publicó en su página de security announcements que la versión 4.62.0 corrige dos vulnerabilidades:
1) CVE-2026-28400
Afecta a Docker Model Runner (DMR) en versiones anteriores a 1.0.16. El problema está en un endpoint POST /engines/_configure que aceptaba flags de runtime sin autenticación y las pasaba al motor subyacente. Según el advisory, ese comportamiento permitía sobreescritura de archivos accesibles por el proceso de Model Runner y, en determinados escenarios, impactos severos sobre el disco de la VM de Docker Desktop.
2) CVE-2026-2664
Se trata de una lectura fuera de límites (CWE-125) en el módulo grpcfuse del kernel dentro de la VM Linux que usa Docker Desktop. NVD indica que la falla afecta versiones hasta 4.61.0 y que fue corregida en 4.62.0.
El punto importante es que ambas correcciones se concentran en Desktop, una capa frecuentemente subestimada en threat models corporativos, pese a que conecta repositorios, dependencias, credenciales y pipelines.
Impacto para SysAdmin / DevOps
- Riesgo de integridad del entorno local: una estación comprometida puede alterar imágenes o artefactos antes de que lleguen al registry interno.
- Riesgo de disponibilidad de entornos de trabajo: en el caso de CVE-2026-28400, la documentación técnica describe escenarios donde puede afectarse el disco Docker.raw, con pérdida de contenedores, volúmenes e historial de build en esa máquina.
- Riesgo de movimiento lateral hacia secretos: aunque no toda explotación implica exfiltración directa, cualquier descontrol sobre el runtime local aumenta la superficie para capturar tokens, variables de entorno o configuraciones sensibles usadas en desarrollo.
Detalles técnicos
CVE-2026-28400 (Model Runner)
- Componente: Docker Model Runner (<1.0.16).
- Mecanismo: endpoint
/engines/_configureaceptaba flags no autenticados. - Efecto reportado: manipulación de flags (por ejemplo, de logging) para escribir/sobrescribir archivos accesibles al proceso.
- Contexto Docker Desktop: al estar integrado y accesible desde contenedores por defecto en ciertas configuraciones, la exposición operacional aumenta.
- Mitigación declarada por el proveedor: actualizar a versiones con fix e incorporar controles de aislamiento.
CVE-2026-2664 (grpcfuse)
- Componente: módulo grpcfuse en la VM Linux de Desktop.
- Tipo: out-of-bounds read (CWE-125).
- Alcance: Docker Desktop en Windows, Linux y macOS hasta 4.61.0.
- Solución: actualización a 4.62.0.
Ambos casos muestran una tendencia clara: componentes “auxiliares” (model serving local, integración filesystem, etc.) ya forman parte del perímetro de seguridad de DevOps.
Qué deberían hacer los administradores
- Inventariar versiones de Docker Desktop y detectar clientes por debajo de 4.62.0.
- Definir ventana corta de actualización para equipos con repos críticos y runners locales.
- Revisar exposición de Model Runner, especialmente accesos TCP locales no estándar.
- Endurecer aislamiento en endpoints; donde aplique, habilitar Enhanced Container Isolation.
- Incluir versión de Docker Desktop en controles de cumplimiento previos a merge/release.
- Fortalecer trazabilidad de artefactos con SBOM/provenance, escaneo y promoción controlada.
Conclusión
Las correcciones de Docker Desktop 4.62.0 no son un detalle menor de “higiene de endpoint”. Son un recordatorio de que la seguridad del ciclo de software empieza en la máquina del desarrollador y se propaga al resto de la cadena DevOps.
En organizaciones que dependen de contenedores para entrega continua, dejar Desktop desactualizado introduce deuda de seguridad silenciosa: no siempre se traduce en un incidente inmediato, pero sí en una superficie de ataque evitable. La acción recomendada es simple y concreta: actualizar, endurecer y auditar.
Fuentes
- Docker security announcements
- Docker Desktop 4.62.0 release notes
- NVD: CVE-2026-28400
- NVD: CVE-2026-2664