Tres parches, una sola cadena de ataque
JFrog ha publicado parches para tres vulnerabilidades distintas de Artifactory desde el 27 de julio de 2026, y los atacantes pasaron semanas encadenando las dos primeras antes de que la tercera se hiciera pública.
| CVE | Divulgada | Vulnerable ahora |
|---|---|---|
| CVE-2026-42016 | 27 Jul 2026 | 59% (+6 wk) |
| CVE-2026-42018 | 12 Aug 2026 | 62% (+4 wk) |
| CVE-2026-82329 | 28 Aug 2026 | 49% (+2 wk) |
CVE-2026-42016 permite cambiar un token de bajo privilegio por uno con alcance de administrador. CVE-2026-42018 entrega un token interno de usuario anónimo a quien nunca ha iniciado sesión, incluso con el acceso anónimo desactivado. CVE-2026-82329, divulgada el 28 de agosto con una puntuación CVSS de 9,8, permite a un atacante no autenticado obtener privilegios de administrador directamente bajo una configuración por defecto.
Los pasos exactos que convierten a un invitado en administrador
La firma de seguridad Wiz documentó el mecanismo exacto: los atacantes envían una petición POST a /access/api/v1/aws/token/, con una barra final, que devuelve un JWT anónimo aunque el acceso anónimo esté desactivado. Después envían ese token a /access/api/v1/tokens para solicitar un token con alcance de administrador, que Artifactory emite sin comprobar correctamente el nivel real de privilegio de quien lo pide.
Para el fallo más reciente, CVE-2026-82329, Wiz encontró un atajo aún más directo: un único POST a /access/api/v1/registry/join devuelve directamente un token de administrador, sin necesidad de encadenar nada. Una vez dentro, los atacantes crearon cuentas de administrador persistentes, instalaron plugins de Groovy maliciosos a través del propio framework de plugins de Artifactory para ejecutar código en el servidor, y en algunos casos desplegaron puertas traseras escritas en Rust con capacidad de mando y control. Wiz observó los ataques encadenados entre el 15 de agosto y el 8 de septiembre de 2026, con una ola separada que explotaba CVE-2026-82329 entre el 1 y el 8 de septiembre.
Parcheado no significa arreglado
La brecha entre que exista un parche y que un servidor lo tenga realmente instalado es la verdadera historia aquí, y se mide en meses, no en días. JFrog corrigió CVE-2026-42016 en la versión 7.133.11 el 27 de julio; seis semanas después, según la telemetría de Wiz, el 59 por ciento de las organizaciones seguía siendo vulnerable.
A CVE-2026-42018 no le fue mejor: corregido en cinco ramas para el 12 de agosto, cuatro semanas después el 62 por ciento de las organizaciones seguía expuesto. CVE-2026-82329 se movió más rápido, bajando del 67 por ciento vulnerable en el momento de la divulgación al 49 por ciento tras dos semanas, pero eso sigue dejando a casi la mitad de todos los despliegues de Artifactory abiertos a un fallo con una gravedad de 9,8 sobre 10. La escala de los intentos automatizados de explotación contra servidores sin parchear no es teórica: Fastly registró unos 406.000 intentos de explotación contra CVE-2026-82329 en un solo día, el 2 de septiembre, el mismo día en que CISA lo añadió a su catálogo de vulnerabilidades explotadas conocidas.
La obligación europea que todavía nadie hace cumplir
CISA dio a las agencias federales de EEUU un plazo fijo, el 5 de septiembre, tres días después de añadir CVE-2026-82329 a su catálogo KEV el 2 de septiembre. La UE no tiene una orden pública equivalente con fecha para empresas privadas, aunque el artículo 21 de la NIS2 ya exige a muchas empresas medianas de software y servicios de TI mantener un proceso documentado de gestión de vulnerabilidades que cubre exactamente este tipo de herramienta de cadena de suministro sin parchear y expuesta a internet.
Eso deja una brecha real para cualquier empresa con sede en la UE que gestione Artifactory por su cuenta: existe la obligación legal de gestionar este riesgo según la NIS2, pero no hay un plazo nacional o de toda la UE publicado que fuerce el punto como lo hace la orden de CISA en Estados Unidos. Por ahora, el único impulso fiable para parchear una instancia de Artifactory alojada en la UE es que el propio equipo de seguridad de una empresa lea el aviso del proveedor y actúe, no el reloj de un regulador.
Leer a continuación: El fallo peor calificado de GitLab solo necesita un proyecto público | El Fallo Rompió Aquello De Lo Que Depende Parchear
