Un fallo crítico en JFrog Artifactory permite falsificar tokens de administrador sin iniciar sesión

Un fallo crítico de autenticación en JFrog Artifactory, el repositorio de artefactos de software que usan las empresas para almacenar y distribuir paquetes de compilación, está siendo explotado activamente apenas días después de haber sido parcheado. Identificada como CVE-2026-82329 y con una puntuación de 9.8 sobre 10 en la escala CVSS, la vulnerabilidad permite a un atacante no autenticado con acceso de red falsificar tokens de administrador en instancias de Artifactory autogestionadas que se ejecutan en su configuración predeterminada, sin necesidad de credenciales, interacción del usuario ni acceso previo.

JFrog reveló y parcheó la vulnerabilidad el 28 de agosto de 2026, publicando versiones corregidas en seis líneas de lanzamiento: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 y 7.161.20. Según la firma de seguridad ofensiva watchTowr, que fue la primera en detectar la explotación activa, los ataques comenzaron antes de que el parche fuera público y se aceleraron una vez que la divulgación dio a los atacantes una hoja de ruta más clara del fallo. Para el 1 de septiembre, los honeypots de watchTowr ya registraban intentos de explotación desde múltiples ubicaciones geográficas.

La causa raíz es un vacío de configuración, no un error de código: las instancias de JFrog Access que no tienen configurada explícitamente una clave de unión (join key) recurren por defecto a una clave «fantasma» predecible, que los atacantes pueden aprovechar para falsificar las credenciales que Artifactory utiliza para confiar en las solicitudes administrativas. Como el fallo reside en un estado predeterminado y no en una mala configuración introducida por los propios usuarios, cualquier despliegue autogestionado que nunca haya configurado una clave de unión personalizada queda expuesto de fábrica.

Esto importa mucho más allá de la base de clientes de JFrog. Artifactory se sitúa en el centro de las cadenas de suministro de software: es donde las organizaciones almacenan los artefactos de compilación, imágenes de contenedores y paquetes que se incorporan automáticamente a los pipelines de CI/CD y a los sistemas de producción. «El acceso administrativo a Artifactory alcanza artefactos publicados en los que los sistemas posteriores ya confían y que descargan automáticamente», explicó Collin Hogue-Spears, de Black Duck, señalando por qué este fallo es peligroso aunque no sea una ejecución remota de código en el sentido tradicional.

Una vez que los atacantes generan un token de administrador falsificado, los investigadores afirman haber observado que enumeran usuarios, grupos y tokens de acceso existentes, mapean las relaciones de acceso federado entre sistemas conectados y, en un número menor de casos, plantan cuentas de puerta trasera para conservar el acceso incluso después de que se parchee el agujero original. El riesgo más grave —manipular o envenenar artefactos que otros sistemas obtienen automáticamente— está al alcance de cualquiera que posea un token de administrador falsificado, convirtiendo un único repositorio expuesto en un posible punto de entrada para un compromiso mucho más amplio de la cadena de suministro.

El servicio SaaS alojado de JFrog no se vio afectado; la exposición se limita a los despliegues autogestionados de Artifactory que ejecutan la configuración predeterminada vulnerable. «Esto pasó de la divulgación a la explotación real con una eficiencia incómoda», afirmó Yordan Ganchev, de watchTowr. «Cualquiera que siga el caso sabe lo que viene después: las cosas van a empeorar.»

Las organizaciones que ejecutan Artifactory de forma autogestionada deben parchear a una de las versiones corregidas de inmediato y no deben asumir que la ausencia de una clave de unión configurada explícitamente es un valor predeterminado inofensivo: es exactamente la condición de la que depende el exploit. Dados los informes sobre cuentas de puerta trasera, los equipos que ejecutaban una versión afectada antes del 28 de agosto también deberían auditar los usuarios y tokens de administrador existentes en busca de cualquier elemento que no hayan creado ellos mismos, y no limitarse a aplicar el parche.

Según lo informado por The Hacker News y BleepingComputer.