結論から。コンテナ運用の定番コマンド docker cp に、コンテナ側からホストの任意のファイルを作成・上書きできる脆弱性「CopyEscape」（CVE-2026-17106）が見つかりました。悪意あるコンテナからファイルを取り出しただけで、ホスト側の設定ファイルや実行ファイルを書き換えられます。PoC（実証コード）はすでに公開済みです。Docker Desktop は 4.86.0 以降、Docker Engine / CLI は 29.7.2 以降へ更新してください。
この記事でわかること
- 脆弱性の正体（アーカイブ展開ライブラリ moby/go-archive の欠陥）
- 影響を受けるバージョンと、修正版として何を入れるべきか
- 「本番でDockerは使っていない」会社でも見落としやすいポイント
- すぐに更新できないときの現実的な回避策
go-archiveとは何者か
moby/go-archive とは、tar形式のアーカイブを作成・展開するためのGo言語ライブラリです。Dockerの開発母体である Moby Project が管理しており、イメージのレイヤ展開や docker cp でのファイル受け渡しなど、Dockerが「固めて運ぶ／ほどく」処理の土台になっています。
単体で導入した覚えがなくても、Docker Engine・Docker CLI・Docker Desktop の内部で動いています。さらに Go の公開パッケージ情報（pkg.go.dev）の被参照一覧を見ると、BuildKit・buildx・Docker Compose・Testcontainers・Dagger・kaniko・HashiCorp Vault など数百のプロジェクトがこのライブラリを取り込んでいます（2026年8月21日時点で474プロジェクト）。
ただし、取り込んでいること自体が即「同じ攻撃が成立する」ことを意味しません。危険なのは、信頼できないアーカイブを展開する経路を持っている場合です。自社の該当判定は、後述の手順で行ってください。
何が起きたのか
Imperva の Red Team（Ron Masas氏）が発見し、2026年8月11日に GitHub Security Advisory（GHSA-hfg8-hc9c-6c3h）として公開されました。CVSS v4.0 のベーススコアは 7.1（重要度「高」）です。分類は CWE-22（パストラバーサル）と CWE-59（リンク解決の不備）にあたります。
問題は、アーカイブを展開するときの「そのファイルは展開先ディレクトリの中に収まるか」という判定にあります。go-archive はこの判定を文字列としてのパスだけで行っていました。ところが実際にファイルを書き込む段階では、OSがシンボリックリンクをたどって別の場所を指すことがあります。文字列上は安全に見えるのに、書き込み先は展開先の外——という食い違いが起きるわけです。
影響を受けるのは Unpack / UnpackLayer / Untar / UntarUncompressed と ApplyLayer 系のヘルパー関数です。
どういう攻撃が成立するのか
攻撃の起点は、攻撃者が中身を制御できるコンテナから docker cp でファイルを取り出すという、ごくありふれた操作です。稼働中のコンテナ側でファイルの種類を書き換える競合（TOCTOU）を起こして不整合なtarを作らせ、展開側の欠陥と組み合わせることで、ホストの任意パスに書き込みが届きます。
発見者が公開した攻撃シナリオは、実務者にはかなり生々しいものです。
- macOSの開発端末：
~/.bash_profileやSSHの設定を上書きされ、次にターミナルを開いた瞬間に攻撃者のコードが動く。 - Linuxで
sudo docker cpを使った場合：root所有のシステム領域まで書き込みが届く。PoCでは/usr/bin/runcをシェルスクリプトに差し替え、以後のDocker操作でroot権限の実行に成功しています。
攻撃条件はローカル（AV:L）であり、リモートから無条件に踏まれる類の脆弱性ではありません。ただし「利用者の操作を待つ」という条件は、docker cp が日常業務そのものである以上、事実上のハードルにはなりません。
影響を受けるバージョンと修正版
| 製品・コンポーネント | 影響を受けるバージョン | 修正版 |
|---|---|---|
| moby/go-archive | 0.3.0 より前 | 0.3.0 |
| Docker Engine | 29.6.1 以前 | 29.7.0で修正（実運用は29.7.2以降を推奨） |
| Docker CLI | 29.6.1 以前 | 29.7.0（同上） |
| Docker Desktop | 4.81.0 以前 | 4.86.0 |
Docker Sandboxes（sbx cp） |
0.38.0 より前 | 0.38.0 |
開示のタイムラインは、2026年4月11日にDockerへ報告、7月24日にCVE採番、7月30日に初回修正（Engine / CLI 29.7.0）、8月10日にDocker Desktop 4.86.0の公開、という流れです。報告から公開まで約4か月かかっています。
なぜ「29.7.0」ではなく「29.7.2」なのか
修正版である29.7.0に、業務を止めうるリグレッション（不具合の再発）が2件入ってしまったためです。Docker公式のリリースノートによれば、内容は次の2点でした。
- 一部のイメージビルダーが生成した「絶対パスのハードリンク」を含むイメージのpullが拒否される
- 古いLinuxカーネル上で、ファイルパーミッションの適用時にイメージpullや
docker cpが失敗することがある
これらは 29.7.1（7月31日）と 29.7.2（8月5日）で解消されています。セキュリティ修正だけを見て29.7.0を急いで入れると、CI/CDのイメージpullが止まりかねない——という、現場がいちばん踏みたくない地雷です。適用するなら29.7.2以降を指定してください。
自社が該当するかをどう確かめるか
資産管理台帳に「go-archive」という名前が載ることはありません。次の順で当たるのが現実的です。
- Docker Engine / CLI：
docker versionでクライアントとサーバ双方のバージョンを確認する（片方だけ古いケースがあります）。 - Docker Desktop：メニューの「About Docker Desktop」でバージョンを確認する。開発者端末に個別インストールされていることが多く、サーバ側の棚卸しだけでは漏れます。
- その他のGo製ツール：バイナリに対して
go version -m <実行ファイル>を実行すると、埋め込まれたモジュール一覧が表示されます。ここにgithub.com/moby/go-archiveとそのバージョンが出てくるかを見ます。
3番目は、CI実行環境やビルドサーバに置きっぱなしになっているツール群を洗うときに効きます。
現場目線の課題
この脆弱性のいやらしさは、影響範囲が「サーバ」ではなく「人が触っている端末」に寄っている点にあります。Docker Desktopは開発部門が各自の判断で入れていることが多く、情シスが配布・管理していないケースも珍しくありません。バージョンを一斉に把握することすら難しい、というのが正直な実感ではないでしょうか。
加えて docker cp は、「調査のためにコンテナからログを1本抜く」といった、手が勝手に動く操作です。インシデント調査で不審なコンテナから証拠を取り出す場面はまさにこれに当たり、調べようとした瞬間に踏むという順序になりかねません。禁止で運用を縛るのは非現実的で、結局はバージョンを上げきるしかない類の問題です。
そしてもう一点。今回のように「セキュリティ修正版そのものに不具合が入り、数日後の版で直る」という流れは、パッチ適用を急ぐ現場ほど巻き込まれます。公表直後に飛びつかず、リリースノートの後続バージョンまで目を通す一手間が、結果的にいちばん速いことがあります。
情シスはどうすべきか
優先順位としては、(1) Docker Desktopを使っている端末の洗い出しと4.86.0以降への更新、(2) サーバ側 Docker Engine / CLI の29.7.2以降への更新、の順が妥当です。開発者端末のほうが先なのは、PoCが公開されている環境（macOS / Linux）と一致するためです。
すぐに更新できない場合の回避策は、GitHub Security Advisoryが挙げる「信頼できるアーカイブのみを展開する」に尽きます。運用に落とすなら次のとおりです。
- 素性の不明なイメージから起動したコンテナに対して
docker cpを実行しない - どうしても取り出すなら、コンテナを停止してからコピーする（競合の起点を断つ）
sudo docker cpのような特権付きのコピーを避ける（被害がroot領域に届くのを防ぐ）
組織としての進め方は、自前でチェックリストを作り込むより、公的な指針に沿ったほうが社内の説明もしやすくなります。中小規模であれば、IPAの中小企業の情報セキュリティ対策ガイドラインが、資産の把握と更新の運用をどう定着させるかの出発点になります。開発部門への周知という意味では、IPAの対策のしおりのような短い教材を配るほうが、長文の通達より読まれます。
「開発者の端末は開発部門の管轄」で線を引いてしまうと、今回のような端末側の脆弱性は永久に見えないままです。まず台帳に載せるところから始めるのが、遠回りに見えて確実です。
まとめ
docker cpの裏で動くアーカイブ展開ライブラリ moby/go-archive に、展開先の外へ書き込める脆弱性（CVE-2026-17106「CopyEscape」、CVSS v4.0 7.1）があり、PoCも公開済み。- 更新先は Docker Desktop 4.86.0以降、Docker Engine / CLI 29.7.2以降。29.7.0にはpullが失敗するリグレッションがあるため、29.7.2以降を指定する。
- 影響の中心は開発者端末。情シスの管理外に置かれがちなDocker Desktopの棚卸しが、実務上いちばんの山場になる。
関連記事
- WinRAR脆弱性CVE-2026-14191、修正版7.23が公開（同じく「アーカイブ展開時に想定外の場所へ書き込まれる」類型）
- Svelteに脆弱性4件、devalueはNuxtにも同梱（同梱ライブラリの該当判定）
- PostgreSQLに脆弱性28件、18.6などで修正
- サプライチェーン攻撃とは？仕組みと種類をわかりやすく解説
