JFrog Artifactory: CVE-2026-42018 y CVE-2026-42016 dan admin en minutos

CISA sumó el 11 de septiembre dos vulnerabilidades de JFrog Artifactory al catálogo de explotación activa, con plazo al 25 de septiembre, que es este viernes. Se explotan encadenadas y el resultado es una cuenta de administrador en el servidor que guarda los binarios de tu empresa.

Wiz documentó la campaña: entre el 15 de agosto y el 8 de septiembre observó a varios actores distintos encadenar las dos fallas contra instancias autoalojadas, y describe el ritmo con una frase que conviene leer dos veces: "In some instances, actors moved from the first request to a created admin account in under five minutes."

Las dos afectan a Artifactory autoalojado (Self Hosted). La versión que corrige CVE-2026-42016 es la 7.133.11 o posterior.

Cómo se encadenan CVE-2026-42018 y CVE-2026-42016 hasta administrador

Ninguna de las dos alcanza sola. La primera consigue un token que no debería existir; la segunda le da permisos que ese token no debería tener.

El primer paso es el más instructivo y el más fácil de explicar. Según Wiz, una petición POST /access/api/v1/aws/token/ sin autenticar, con una barra al final, devuelve HTTP 200 con un JWT del usuario anónimo interno. Sin la barra final, la misma ruta se rechaza.

Eso es un desajuste de normalización de rutas: el componente que decide si hace falta autenticarse y el componente que atiende la petición no leen la ruta igual. Uno ve /access/api/v1/aws/token/ como algo distinto de /access/api/v1/aws/token y no le aplica el filtro; el otro los trata como lo mismo y responde. Es una clase de error vieja y sigue funcionando porque vive en la costura entre dos piezas, no adentro de ninguna.

El segundo paso es el canje: ese JWT se manda a POST /access/api/v1/tokens y vuelve con alcance de administrador, porque la validación miraba la firma y el emisor del token, pero no su alcance. La descripción de JFrog lo dice así: "due to a validation check of the token signature/issuer and not the token's scope".

Y hay un detalle en ese token que es el regalo para quien tenga que investigar.

En Artifactory el administrador se llama anonymous, y eso es lo que hay que buscar

El token con permisos de administrador conserva el nombre de usuario anónimo. O sea que las acciones administrativas que siguieron quedan registradas a nombre de anonymous.

Los rastros concretos que publicó Wiz, para buscar hacia atrás:

• Peticiones POST /access/api/v1/aws/token/ con barra final que respondieron 200.
• PUT /api/security/users/<usuario> o /access/api/ui/users/<usuario> con respuesta 201, con el token a nombre de anonymous: ahí se creó la cuenta persistente.
• Complementos Groovy en $JFROG_HOME/var/etc/artifactory/plugins/, invocables después en /artifactory/api/plugins/execute/<nombre>.

Wiz recuperó seis complementos maliciosos distintos, y los nombres muestran para qué se usaron: rce.groovy y cmd.groovy para ejecutar comandos, JFrogImage.groovy para cosechar credenciales, metrics.groovy para implantes en memoria y httpSession.groovy para túneles de red. En varios casos desplegaron además puertas traseras propias escritas en Rust para el mando y control.

Conviene notar de qué está hecho el último paso: el marco de complementos de Artifactory es una función legítima del producto. Las dos fallas entregan el administrador; lo que ejecuta código después es la extensibilidad que el producto ofrece a propósito. Por eso el directorio de plugins es un lugar de revisión obligatoria aunque no haya ninguna falla involucrada.

Los parches de Artifactory salieron 3 días antes del primer ataque

Acá está el dato que ordena la urgencia, y es el opuesto exacto del caso que el sitio cubrió el sábado.

JFrog publicó la corrección de CVE-2026-42016 el 27 de julio y la de CVE-2026-42018 el 12 de agosto. Los ataques que documentó Wiz empezaron el 15 de agosto: tres días después del segundo parche.

Eso no es un fallo del fabricante, es el patrón conocido de comparar versiones. Cuando sale un parche, el cambio queda a la vista de cualquiera que sepa leer un diff, y en fallas de autenticación el arreglo suele señalar exactamente dónde estaba el agujero. La publicación del parche no es sólo la solución: también es el aviso.

Y el contraste con las tres fallas del kernel de Linux, donde pasaron 378 días entre la corrección y la confirmación de que se explotaba, dice lo que importa: la ventana entre el parche y el ataque no tiene un tamaño típico. Puede ser de un año o de tres días, y de qué lado caés no depende de la falla sino de cuánto tardás vos.

Cuatro entradas de Artifactory en el catálogo en 26 días

Esta no es la primera vez del producto este mes, ni la segunda.

Cuatro entradas en 26 días, y tres de las cuatro son fallas de autenticación o de autorización. No son errores de memoria ni desbordes exóticos: son tres formas distintas de que el producto se equivoque sobre quién sos.

El sitio ya había cruzado dos de ellas de pasada —CVE-2026-66384 apareció en la nota sobre los agentes de OpenAI y CVE-2026-82329 en la tanda del 2 de septiembre— sin que se viera el conjunto. Junto, el conjunto dice algo: si administrás un Artifactory propio, el problema no es esta cadena en particular, es que la capa de identidad de ese producto está teniendo un mes muy malo y conviene tratarla como tal.

¿A quién afecta la cadena de CVE-2026-42018 y CVE-2026-42016?

A instancias autoalojadas de JFrog Artifactory anteriores a la 7.133.11. Las dos descripciones dicen explícitamente Self Hosted.

En la región el perfil es el mismo que el de GitLab la semana pasada: el equipo de desarrollo que levantó su repositorio de binarios en un servidor propio, el proveedor de software que guarda ahí las dependencias de sus clientes, el área de sistemas que lo instaló para una migración y quedó.

Y hay una razón por la que en Artifactory duele más que en otros lados. Un repositorio de binarios no guarda código fuente: guarda lo que se despliega. Quien es administrador ahí puede reemplazar un artefacto por otro y esperar a que la próxima compilación se lo lleve. El daño no se queda en el servidor comprometido: viaja hacia adelante, hacia todo lo que se construya después.

¿Quién puede ignorar el aviso de JFrog?

Quien use JFrog Cloud en lugar de una instancia propia, y quien no use Artifactory. Las dos fallas están descritas para la versión autoalojada.

Si tu empresa no desarrolla software pero tu proveedor sí, la pregunta pasa a ser de él: dónde guarda los binarios que te instala, y si ese repositorio estuvo expuesto entre el 15 de agosto y hoy.

¿Qué hago si tengo un Artifactory propio?

1. Actualizá a 7.133.11 o posterior. El plazo del catálogo de CISA vence el viernes 25, y las dos correcciones llevan semanas disponibles.
2. Revisá la lista de usuarios administradores, uno por uno. El ataque deja una cuenta creada a propósito para quedarse. Cualquier administrador que nadie recuerde haber dado de alta es el hallazgo.
3. Buscá en los registros peticiones a /access/api/v1/aws/token/ con barra final que hayan respondido 200, y creaciones de usuario atribuidas a anonymous. Esa segunda línea es la más concluyente de todas.
4. Listá el directorio de complementos, $JFROG_HOME/var/etc/artifactory/plugins/, y verificá que cada archivo Groovy que esté ahí lo haya puesto alguien de tu equipo. Es el paso que la gente saltea porque los plugins son una función normal del producto.
5. Si aparece cualquiera de esas cosas, rotá todo lo que el servidor guardaba: tokens de acceso, claves de despliegue, credenciales de los repositorios remotos y de las integraciones. Un administrador ajeno durante semanas tuvo tiempo de llevarse las llaves; el orden para guardar lo nuevo está en gestión de contraseñas.
6. Y revisá los artefactos, no sólo el servidor. Si hubo administrador ajeno, la pregunta que queda abierta no es qué pasó en la máquina sino qué se descargó de ahí desde entonces.

Si el Artifactory lo administra un tercero, las mismas preguntas sirven en la dirección inversa, y el formato para dejarlas por escrito está en cómo responder un cuestionario de seguridad. Los términos están en el glosario, el orden general de prioridades en la guía de ciberseguridad para PyMEs de LATAM, y el resto de la categoría en hostings y cloud.

Preguntas frecuentes sobre las fallas de JFrog Artifactory

Tengo anonymous access desactivado. ¿Estoy cubierto?

No, y ese es justamente el punto de CVE-2026-42018. La descripción de JFrog dice que Artifactory "could return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled". La falla no consiste en abusar del acceso anónimo que vos habilitaste: consiste en que el producto entrega un token del usuario anónimo interno aunque hayas apagado esa función. Tenerla desactivada no cambia nada.

Actualicé a 7.133.11. ¿Necesito hacer algo más?

Sí, si la instancia estuvo accesible desde internet entre mediados de agosto y ahora. Actualizar cierra la cadena hacia adelante, pero no borra una cuenta de administrador creada antes ni quita un complemento Groovy ya instalado. Esos dos quedan y siguen funcionando después del parche. Por eso la revisión de usuarios y del directorio de plugins no es opcional.

¿Qué busco exactamente en los registros?

Tres cosas, en orden de qué tan concluyentes son. La más clara: una creación de usuario administrador atribuida a anonymous, porque ese token conserva el nombre anónimo aunque lleve permisos de administrador. La segunda: peticiones POST a /access/api/v1/aws/token/ con barra final que hayan devuelto 200. La tercera: peticiones a /artifactory/api/plugins/execute/ con nombres de complemento que no reconozcas.

¿Por qué CISA les dio catorce días de plazo y no tres?

El catálogo usa plazos más cortos cuando la explotación es masiva o el impacto es inmediato y total. Acá se trata de instancias autoalojadas, que son menos y están menos expuestas que un servicio público, y la explotación observada fue dirigida contra servidores accesibles, no indiscriminada. Eso no baja la gravedad: baja la escala. Para el que tiene uno de esos servidores, el plazo propio venció el día que se enteró.

¿Qué tiene de especial que sea un repositorio de binarios?

Que lo que guarda es lo que se instala. En un repositorio de código fuente un atacante ve y modifica código que después alguien revisa y compila; en un repositorio de binarios modifica directamente el paquete que se va a desplegar, sin revisión de por medio. Por eso un administrador ajeno en Artifactory es un problema de cadena de suministro y no sólo de un servidor: el efecto sale de esa máquina hacia todo lo que se construya con lo que ahí se guarda.