El CVE «medio» de Artifactory entró en el catálogo antes que el crítico

El 27 de agosto, CISA metió en su catálogo de vulnerabilidades explotadas un fallo de JFrog Artifactory con nota 5,3 sobre 10. El 2 de septiembre metió otro del mismo producto con nota 9,8. El segundo se llevó los titulares; del primero apenas se habló. Están en la misma caja, y el orden en que se confirmó que alguien los estaba usando es el contrario al orden en que se leen las notas.

Las dos fechas

El catálogo KEV de CISA recoge fallos con evidencia de explotación, no fallos graves. Una entrada ahí significa que alguien lo está usando contra alguien, y trae plazo: para las agencias federales estadounidenses, el del 5,3 vence el 10 de septiembre. Cronología, entonces:

• 12 de agosto de 2026 — se publica CVE-2026-66384, un path traversal en Artifactory, nota 5,3 (media).
• 27 de agosto — CISA añade ese 5,3 al KEV, junto a un fallo de ownCloud y otro del kernel de Linux.
• 28 de agosto — JFrog publica y corrige CVE-2026-82329, nota 9,8: salto de autenticación con acceso administrativo.
• 1 de septiembre — watchTowr detecta explotación contra su red de señuelos. Cuatro días después del parche.
• 2 de septiembre — CISA añade el 9,8 al KEV, en un lote de siete que incluye SonicWall SMA1000, Kestra, LiteLLM y Sangoma Switchvox.

Seis días separan una confirmación de la otra. Si tu criterio para meter cosas en la cola de parcheo es la nota, el 5,3 sigue esperando en algún tablero mientras el 9,8 se parcheó el fin de semana. Y el 5,3 llevaba ya seis días con explotación confirmada cuando el otro entró.

El 9,8: la clave de firma se podía calcular

CVE-2026-82329 es un fallo de autenticación incorrecta (CWE-287) con CVSS 9,8, y no está en el catálogo de paquetes ni en la interfaz: está en JFrog Access, el componente que emite y valida credenciales. Según el análisis de watchTowr, las instalaciones que no tienen configurada una join key adicional reciben una join key «fantasma»; en las versiones vulnerables se acepta la cadena vacía como join key válida, y la clave de firma que el sistema deriva de una join key vacía es completamente predecible. A partir de ahí, forjar un token de administrador es aritmética.

Lo importante de esa frase es lo que no hace falta: ni usuario, ni contraseña, ni API key, ni una sesión robada antes. Basta con llegar por red. Afecta a instalaciones autoalojadas; según JFrog, su plataforma SaaS queda fuera.

El 5,3: escribir fuera de la caché de Docker

La descripción de CVE-2026-66384 cabe en una línea: «un usuario autenticado puede escribir datos fuera de la ruta prevista de caché de Docker bajo determinadas condiciones de repositorio remoto». Es CWE-22, path traversal clásico, y la corrección está en las versiones 7.146.35 y 7.161.16. Nos lo cruzamos de refilón escribiendo sobre el incidente de las 136 claves, en la lista de lo que entró en el catálogo aquel día; entonces era una línea, ahora es media historia.

Ese «repositorio remoto» del que habla la descripción es el proxy con caché: el modo en que Artifactory se pone delante de Docker Hub o de un registro externo, se descarga la imagen una vez y la sirve desde dentro. El aviso acota el fallo a «determinadas condiciones» y no dice cuántas instalaciones las cumplen; que ese modo sea el motivo habitual de montar la herramienta es lectura nuestra, no dato del fabricante.

5,3 no quiere decir «poco importante». Quiere decir «una sola dimensión»

El vector completo del 5,3 es este: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N. Leído por partes dice bastante más que el número del final.

Y aquí va lectura nuestra, no de los avisos, porque no hemos visto a nadie encadenar las dos cosas y conviene decirlo: en una caja vulnerable a las dos, el PR:L del 5,3 deja de ser un requisito. El 9,8 reparte credenciales de administrador sin pedir nada a cambio, y «hace falta estar autenticado» se cumple solo.

Dicho lo cual, no lo infles: si ya eres administrador por el 9,8, cambiar el contenido de un repositorio lo puedes hacer por la vía normal, sin ningún path traversal. Lo que añade el 5,3 es escribir fuera del directorio previsto, es decir, en el sistema de ficheros del servidor hasta donde alcance el proceso de Artifactory. Es la diferencia entre «cambio lo que hay en el repositorio» y «escribo en la máquina». No es el mismo salto, y a nosotros el segundo nos preocupa bastante más.

La trampa de las versiones

Los rangos afectados por el 9,8 que se han publicado son 7.161.0–7.161.19, 7.146.0–7.146.36 (algún listado dice .37), 7.133.0–7.133.28, 7.125.0–7.125.19, 7.117.0–7.117.27 y 7.111.4–7.111.21, y las compilaciones corregidas 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 y 7.161.20. Cruzados con el otro fallo salen dos cosas. La primera: 7.161.16 a 7.161.19, y 7.146.35 en adelante hasta el final del rango, son versiones parcheadas del «medio» y expuestas al crítico. Quien actualizó en agosto por el path traversal y se quedó ahí tiene la sensación de estar al día.

La segunda es peor, y es lectura nuestra sobre los rangos publicados: el 5,3 solo tiene corrección anunciada en 7.146.35 y 7.161.16. Quien esté en 7.111, 7.117, 7.125 o 7.133 puede aplicar el arreglo del 9,8 de su propia rama —la .21, la .28, la .20, la .29— y seguir sin parche del path traversal, porque en esas ramas no hay ninguno anunciado. Si tu política es «me quedo en la rama y aplico parches», ahí te quedas a medias. Puede que JFrog tenga retroportes que no salen en los resúmenes públicos; nosotros no los hemos encontrado, y esa es exactamente la pregunta que le haríamos al fabricante.

Un apunte más, por si acaso: los listados públicos discrepan entre sí. En la 7.111, la .21 aparece en unos sitios como última versión afectada y en otros como la compilación corregida; en la 7.146 hay quien cierra el rango en .36 y quien lo cierra en .37. Circula una lectura coherente («anterior a 7.111.21» y «7.146.0 a 7.146.37») que resuelve las dos anomalías, pero no la hemos podido contrastar con el aviso original. Comprueba el número de compilación exacto contra el fabricante. «Voy por la 7.146» no responde a esta pregunta.

El espejo que montaste para no depender de fuera

Nadie instala un repositorio de artefactos por gusto. Se instala por dos motivos razonables: para que una compilación no se caiga porque Docker Hub tenga un mal día, y para quedar a cubierto de que alguien publique un paquete envenenado ahí fuera —que es exactamente el escenario del que hablábamos con el incidente de los 444 paquetes de npm.

Y a partir de ahí endureces alrededor: las máquinas de compilación solo tiran del repositorio interno, la salida a internet se recorta, el registro externo sale de la lista blanca. Todas esas reglas, una por una, apuntan a la misma caja. Es una arquitectura buena, con una consecuencia incómoda: quien controle esa caja hereda cada una de esas reglas como privilegio. Le has enseñado tú a tu infraestructura a creerse lo que salga de ahí.

Y la sustitución no cruza tu perímetro de ninguna forma que un filtro de salida vaya a notar: mismo dominio, tu certificado, un host de tu propia VLAN. Si además despliegas por etiqueta móvil, que ya dijimos que latest no es una versión, el cambio no deja ni un número distinto a la vista.

Lo primero que miraron fue el llavero

Aquí toca precisar de dónde sale lo que sabemos, porque cambia el tamaño del susto: watchTowr describe lo que los atacantes hicieron contra su propia red de señuelos, no contra víctimas identificadas, y la actividad venía de un puñado de direcciones, sin escaneo masivo por ahora. Dicho eso, lo que hicieron ahí es el guion: acuñar tokens de administrador y, con ellos, enumerar usuarios, grupos, conjuntos de credenciales y relaciones de acceso federado, o sea mirar el entorno para decidir si valía la pena seguir; en un número limitado de casos crearon además usuarios puerta trasera. Con esos permisos se puede leer artefactos, cambiar la configuración de seguridad y envenenar paquetes ya existentes.

El orden dice mucho. Empezaron por el llavero, y los paquetes venían después. Un repositorio de artefactos guarda las credenciales con las que habla con los repositorios remotos, con tu registro de imágenes, con tu CI y con las otras instancias federadas; es un almacén de secretos que además sirve ficheros. Ya vimos el mismo patrón cuando el servidor de integración continua resultó ser el que tenía las llaves de producción: lo que hace valiosa a una herramienta interna es con quién está autorizada a hablar.

Nosotros desplegamos con CI/CD en GitLab y contenedores sobre Docker Swarm y Kubernetes, así que el asunto nos pilla dentro. La regla que aplicamos es aburrida: un repositorio de artefactos es un sistema de producción, no una herramienta de desarrollo. Va al inventario, tiene dueño, tiene ventana de actualización y recibe la misma conversación sobre exposición y credenciales que un servidor de base de datos. Es la discusión de arquitectura de datos y aplicaciones de siempre, aplicada a la pieza que suele quedarse fuera del inventario.

Qué miraríamos un lunes por la mañana

• ¿Se llega desde internet? Autoalojado y publicado hacia fuera es la peor de las combinaciones para un fallo que solo pide alcance de red. Si la respuesta es «creo que no», eso es un no verificado.
• El número de compilación exacto, no la rama. Y cotejado con las dos listas, no con una.
• Dos ventanas, no una. Los indicadores del 9,8 —altas de usuario que nadie pidió, tokens de administrador emitidos— solo tienen sentido desde el 28 de agosto. Los del 5,3 empiezan antes, el 12, y son otros: ficheros aparecidos fuera del directorio de caché, en rutas donde escribe el proceso de Artifactory. Buscar unos en la ventana de los otros es una manera cómoda de no encontrar nada.
• Rotar lo que guarda, no solo lo que da acceso a él. Las credenciales de los repositorios remotos, las del registry, las de federación. Si te quedas en cambiar la contraseña de administrador, has rotado la cerradura y no las llaves de dentro.
• El listado de lo desplegado desde esas fechas, con la imagen concreta y su digest. Si tu respuesta empieza por «bueno, lo que hubiera en el registro», esa es la respuesta.
• Si tuvieras que dudar de un artefacto, ¿puedes reconstruirlo desde fuente y compararlo? Aquí es donde la conversación deja de ser de seguridad y pasa a ser de recuperación: restaurar la copia del repositorio te devuelve el estado que tenía, incluido lo que te hubieran metido dentro. Restaurar y reconstruir no son lo mismo.

Parchear no es limpiar

Es la misma distinción que ya hicimos con los enlaces simbólicos de FortiOS, y aquí aplica entera. Un salto de autenticación deja un rastro discreto: ningún proceso raro, ningún binario nuevo, solo peticiones bien formadas con un token que el sistema considera válido. Después del parche la instalación se ve exactamente igual que antes, con un usuario más o con una credencial de menos. Aplica también al lote entero del 2 de septiembre, del que ya escribimos por el lado de Kestra: cuatro de los siete fallos eran software interno que nadie llama producción.

Cuando entramos a mirar una de estas máquinas, lo primero que preguntamos no es la versión. Es qué otras máquinas se creen lo que sale de ahí y con qué credenciales habla ella con el resto. La versión se arregla esta tarde; esas dos listas, en muchas empresas, llevan años sin escribirse en ninguna parte, y son las que deciden cuánto duele el día que el fallo aparece.

Fuentes (verificadas): alerta de CISA de 27 de agosto de 2026 añadiendo tres vulnerabilidades explotadas al catálogo KEV, entre ellas CVE-2026-66384 (JFrog Artifactory, CWE-22): cisa.gov. Alerta de CISA de 2 de septiembre de 2026 con las siete adiciones que incluyen CVE-2026-82329: cisa.gov. Descripción, CWE-22, vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N, nota 5,3, publicación del 12 de agosto, plazo federal del 10 de septiembre y versiones corregidas 7.146.35 / 7.161.16 del CVE-2026-66384: ficha pública del CVE. Análisis de watchTowr sobre la join key «fantasma», la cadena vacía aceptada como join key válida, la explotación observada el 1 de septiembre contra su red de señuelos (cuatro días después del parche) y la enumeración de usuarios, grupos, credenciales y accesos federados, recogido en The Hacker News y BleepingComputer (fecha del parche, 28 de agosto de 2026, compilaciones corregidas y capacidad de envenenar paquetes existentes). El encadenamiento de los dos fallos, la lectura del vector, la deducción de que las ramas 7.111 a 7.133 se quedan sin parche del 5,3 y la distinción entre restaurar y reconstruir son lectura nuestra, no de los avisos. Los rangos por rama del 9,8 y el límite inferior 7.111.4 los hemos tomado de agregadores públicos, no del aviso original, y no coinciden entre sí en dos ramas.