JFrog Artifactory: una clave vacia por defecto permite forjar tokens de administrador
El fallo CVE-2026-82329, con CVSS 9.8, afecta a instalaciones autoalojadas y ya se explota en la naturaleza. El estado vulnerable es, literalmente, el de una instalación recién hecha.
JFrog ha parcheado una vulnerabilidad de salto de autenticación en Artifactory autoalojado con CVSS 9.8 que no necesita ninguna configuración errónea por parte del administrador. El fallo, CVE-2026-82329, se anunció el 28 de agosto de 2026 y el 1 de septiembre ya había tráfico de explotación en la red de honeypots de watchTowr.
El problema está en el componente JFrog Access, el subsistema que emite y valida identidades y permisos. La capa de acceso confía en los miembros del clúster a través de una join key. Una instalación por defecto arranca con una cadena vacía dentro del conjunto de join keys de confianza. Cuando el sistema resuelve la signing key con ese valor vacío devuelve un resultado predecible de 32 bytes. Quien lo conozca puede firmar un JWT de unión que parece legítimo y, con él, acuñar un token de administrador de la plataforma. No hay una cadena de explotación rebuscada: el estado vulnerable es el estado en el que arranca un Artifactory recién instalado.
Artifactory se sienta entre desarrolladores, sistemas de build y despliegue en producción. Almacena y sirve los paquetes, binarios y artefactos que las máquinas de abajo ya confían y consumen automáticamente. Collin Hogue-Spears, de Black Duck, lo enmarca como un problema de zero trust: el acceso administrativo a Artifactory alcanza artefactos publicados que los sistemas de destino consumen sin más revisión. Con privilegios de administrador, un atacante puede reemplazar paquetes en caché (y que un build compile dependencias manipuladas), abusar de credenciales de publicación, o modificar pipelines para empujar cambios hacia clientes finales. James Edwards, de Keeper Security, lo dice sin rodeos: cualquier instancia vulnerable y alcanzable por red debería tratarse como comprometida.
Dos CVEs encadenables más
JFrog también arregló dos fallos que se han usado encadenados con el bypass. CVE-2026-42018 permite a un llamante no autenticado obtener un token anónimo con acceso a artefactos y datos sensibles, incluso con el acceso anónimo desactivado. CVE-2026-42016 es validación insuficiente de tokens: se comprueban firma y emisor, pero no el scope, así que un token de bajo privilegio puede escalar. La secuencia observada es token de bajo privilegio, escalada, plugin instalado para ejecutar código arbitrario, cuentas persistentes y exfiltración de configuración y claves del clúster. CISA metió dos de estas vulnerabilidades en su catálogo de explotadas el 12 de septiembre, con plazo de remediación federal el 25.
Versiones arregladas y qué hacer
Ramas afectadas y salto a la versión corregida: 7.161.0–7.161.19 → 7.161.20; 7.146.0–7.146.36 → 7.146.38; 7.133.0–7.133.28 → 7.133.29; 7.125.0–7.125.19 → 7.125.20; 7.117.0–7.117.27 → 7.117.28; por debajo de 7.111.21 → 7.111.21. Los entornos cloud de JFrog ya están actualizados; los autoalojados, no.
Parchear cierra la puerta, pero no borra los tokens que un atacante ya haya creado. Artifactory admite tokens sin caducidad, así que un token de administrador forjado puede seguir siendo válido después del upgrade. Toca revisar los tokens emitidos, revocar lo desconocido, rotar credenciales y auditar cuentas de administrador que nadie recuerda haber creado.
Un orden práctico: comprobar la versión en marcha contra la lista; listar usuarios y buscar administradores recientes; inspeccionar el directorio de plugins, que es el mecanismo principal de ejecución de código en esta cadena; y revisar los logs de acceso buscando llamadas al endpoint de tokens y acciones administrativas en horas raras o desde direcciones desconocidas. Dos detalles que provocan errores durante esa revisión: en despliegues en contenedor hay que mirar desde dentro del contenedor, y las rutas de log cambian según el método de instalación. Si aparece una cuenta o un plugin sospechoso, deshabilitarlo y preservar la evidencia es más útil que borrarlo.
Hasta dónde llega lo que sabemos: watchTowr confirma que hubo explotación y describe el comportamiento. No establece cuántas organizaciones se han visto afectadas, ni si todas las instancias observadas llegaron a la toma de control total, ni quién está detrás. El propio watchTowr apunta que, en el momento de su informe, todavía no había aparecido escaneo masivo ni explotación en bloque.
