CVE-2026-78122 — 概念実証（PoC）

Tecnativa docker-socket-proxy ≤ 0.5.0 — 不十分なアクセス制御の細粒度（CWE-1220） CVSS 4.0: 8.3（高） — CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

攻撃ベクトルは隣接（AV:A）です。攻撃者はプロキシに対してローカル/隣接ネットワークから到達できる必要があります。これこそが、ルーティング可能なインターフェースに公開しないことが緩和策の一部である理由です。

docker-socket-proxy は Docker ソケット用の HAProxy フロントエンドであり、その唯一の目的は Docker API へのスコープ付き・最小権限アクセスを提供することです。運用者が使用する定番の「安全で読み取り専用」レシピは次のとおりです:

CONTAINERS=1     # allow listing/inspecting containers
POST=0           # deny everything that mutates state
# every other flag left at its default (0)

運用者はこれで読み取り専用のコンテナメタデータが得られると合理的に信じていますが、実際はそうではありません。

根本原因

haproxy.cfg では、/containers 名前空間全体が単一の粗いプレフィックスルールで制御されています:

http-request allow if { path,url_dec -m reg -i ^(/v[\d\.]+)?/containers } { env(CONTAINERS) -m bool }

この正規表現は /containers 配下のすべての GET サブパスに一致し、「コンテナ一覧」の一部であることを意図されていなかった機密性の高い読み取りエンドポイントも含まれます。これらはすべて GET であるため、POST=0 ガードでは何も防げません:

正味の影響:「強化された」CONTAINERS=1, POST=0 の設定でも、プロキシに到達できる者は誰でも、ホスト上のすべてのコンテナの秘密をダンプし、完全なファイルシステムを外部に持ち出すことができます。

構成（レイアウト）

lab/        vulnerable docker-socket-proxy v0.5.0 + a victim container with planted secrets
exploit/    exploit.sh — end-to-end data-exfiltration PoC
mitigation/ patched haproxy.cfg + compose that denies the sensitive sub-paths
verify.sh   one command: stand up both, exploit, print a before/after table
teardown.sh stop everything
loot/        exploit output lands here

実行方法

Docker + Docker Compose と POSIX シェルが必要です（Windows では Git Bash が動作します）。

./verify.sh

またはステップバイステップで:

docker compose -f lab/docker-compose.yml up -d      # vulnerable proxy on 127.0.0.1:2375
bash exploit/exploit.sh http://127.0.0.1:2375        # loot lands in ./loot

プロキシは 127.0.0.1 にのみバインドされています。Docker ソケットプロキシをルーティング可能なインターフェースに公開しないでください。

観測された結果（v0.5.0）

[+] POST /containers/create -> 403 Forbidden   (operator believes they are safe)
    Leaked environment variables:
      STRIPE_API_KEY=sk_live_FAKE_0000000000000000
      DB_PASSWORD=hunter2-from-container-env
[+] Pulled /etc/passwd via /archive
[+] Stole /run/secrets/aws.env via /archive
[+] Exported entire filesystem (8,095,232 bytes) via /export
[+] Retrieved process table via /top and logs via /logs

上記のすべての項目は、POST=0 が依然として有効な状態で取得されました。

緩和策

真の修正: パッチ適用済みリリースへのアップグレード（issue #182 / PR #183 で追跡中）を行い、CONTAINERS=1 だけを「読み取り専用」と見なすのをやめてください。

このリポジトリには、粗い /containers 許可の前に危険なサブパスに対する明示的な deny ルールを追加する、ドロップインで使える強化設定（mitigation/haproxy.patched.cfg）も同梱されています。各ルールは専用フラグ（ALLOW_ARCHIVE、ALLOW_EXPORT、ALLOW_LOGS、ALLOW_TOP）で再度有効化できます:

http-request deny if { ... /containers/[..]/archive } ! { env(ALLOW_ARCHIVE) -m bool }
http-request deny if { ... /containers/[..]/export }  ! { env(ALLOW_EXPORT)  -m bool }
http-request deny if { ... /containers/[..]/logs }    ! { env(ALLOW_LOGS)    -m bool }
http-request deny if { ... /containers/[..]/top }     ! { env(ALLOW_TOP)     -m bool }

検証済みの before/after（verify.sh の出力）— 同じ CONTAINERS=1, POST=0 の設定:

正規の一覧・検査は引き続き動作し、データ窃取のプリミティブはブロックされます。

運用面でも同様に、プロキシをルーティング可能なネットワークから切り離し、Docker ソケットを読み取り専用でマウントし、最小権限を適用してください（利用者が正確に必要とするフラグのみを有効化します）。

参考情報

• CVE-2026-78122 (NVD) — https://nvd.nist.gov/vuln/detail/CVE-2026-78122
• CVE-2026-78122 (cvefeed) — https://cvefeed.io/vuln/detail/CVE-2026-78122
• VulnCheck アドバイザリ — https://www.vulncheck.com/advisories/docker-socket-proxy-through-insufficient-access-control-granularity-exposes-container-filesystems
• オリジナル記事（nedlir） — https://gist.github.com/nedlir/e4f52f88a757f02c67db1fd5dd70d732
• アップストリームリポジトリ — https://github.com/Tecnativa/docker-socket-proxy
• 脆弱な設定 — https://github.com/Tecnativa/docker-socket-proxy/blob/v0.5.0/haproxy.cfg#L49-L61
• Issue #182 / PR #183

認可されたセキュリティテストおよび教育目的にのみ使用してください。このラボは、あなた自身のホスト上で、あなたが作成したコンテナに対してのみ完全に実行されます。