CVE-2026-93318

🚨High - BuildKit Cache Poisoning via Unvalidated Image DiffIDs (CVE-2026-93318) In http://github.com/moby/buildkit, a malicious image can spoof DiffIDs for layers while serving different contents; BuildKit may key cache/snapshot identity off DiffIDs without verifying layer data. If a shared/persistent cache ingests the malicious image first, later builds of the victim image can mount attacker-controlled layers (e.g., replace /bin/sh), enabling code execution, secret theft, or artifact tampering. Both regular and lazy-pulling snapshotters (stargz) are impacted. 👉Affected: http://github.com/moby/buildkit (versions TBD)

Tablero KEV de este martes 6 de octubre: NetScaler CVE-2026-88779 vence mañana 7; FortiMail CVE-2026-104286 ya tiene builds que corrigen (8.0.2, 7.6.7 y 7.4.9) aunque su plazo venció el 4; y el de Zammad (CVE-2026-102489/102490) venció ayer, lunes 5. NetScaler: si hay SAML, re-upgrade a 14.1-73.41 / 13.1-64.28 aunque ya estés en 73.37, más el triage forense que pide KEV. FortiMail: subir de build y revisar IoCs; la rama 7.2 debe migrar a 7.4 o superior. Zammad: 7.2.0, con prioridad en instancias 6.x. Fuera de KEV pero para esta semana: Dell System Update CVE-2026-86360 (9.6, root sin autenticación; fix 2.3.0.0), BuildKit CVE-2026-93318 si tu caché de build es compartida (v0.33.1) y @subql/common 5.8.3 si tu árbol de dependencias lo resuelve.

Si tu CI usa BuildKit con caché compartida o persistente, revisa CVE-2026-93318 (CVSS 4.0: 7.5): una imagen maliciosa puede anunciar los DiffIDs de otra y envenenar la caché, de modo que un build posterior monte capas del atacante como imagen base. Fix: BuildKit v0.33.1. Cómo funciona: BuildKit derivaba la identidad de caché y snapshot de los DiffIDs anunciados sin validar que coincidieran con el contenido real de las capas. Si el daemon procesa primero la imagen maliciosa, el build que use la imagen víctima puede correr código del atacante (por ejemplo, un /bin/sh reemplazado): leer secretos montados en el build, alterar artefactos o colgar el build. Aplica a snapshotters normales y a lazy-pulling como stargz. Lo que lo limita: necesita un daemon que comparta o persista caché y que la imagen del atacante pase primero. No hay explotación conocida. Acción: subir a v0.33.1 o superior. Workaround del proyecto: no compartir caché entre builds confiables y no confiables, usar builders aislados o efímeros para imágenes de origen dudoso, o hacer prune de la caché después de procesarlas. Apagar stargz no basta.