トップ/記事一覧/Linux脆弱性『Copy Fail』の現状。更新済みサーバーは対処不要
linux-copy-fail-cve-2026-31431-cover-ja

Linux脆弱性『Copy Fail』の現状。更新済みサーバーは対処不要

Linuxカーネルの権限昇格脆弱性『Copy Fail』(CVE-2026-31431)。Ubuntuは24.04 LTS以前が対象で26.04は影響なし。732バイトのコードで管理者権限を奪える仕組み、Red Hat・Debian等のディストロ別早見表、JVNVU#96811810と多層防御を運用者目線で解説。

ニュース2026年5月12日公開 4日前更新
目次
この記事のポイント

Linuxカーネルの権限昇格脆弱性『Copy Fail』(CVE-2026-31431)。Ubuntuは24.04 LTS以前が対象で26.04は影響なし。732バイトのコードで管理者権限を奪える仕組み、Red Hat・Debian等のディストロ別早見表、JVNVU#96811810と多層防御を運用者目線で解説。

SERIESLinuxカーネル脆弱性連鎖シリーズ・第1報

Linuxカーネルには、一般ユーザーが管理者権限(root)を奪える「Copy Fail(コピーフェイル)」CVE-2026-31431)という穴が、2017年以降のバージョンに長く潜んでいました。修正版はカーネル 5.10.254 / 5.15.204 / 6.1.170 / 6.6.137 / 6.12.85 / 6.18.22 / 6.19.12 以降で、2026年7月23日時点で配布中の安定版・長期サポート版はすべて修正済みです。2026年5月以降にOS更新と再起動を済ませたサーバーなら追加の対応は不要。それより前から放置しているサーバーは、今も攻撃対象です。

Copy Failは、たった732バイトのPythonスクリプトで権限奪取が成立する脆弱性で、Ubuntu、Red Hat、Amazon Linux、SUSE、Debian、Fedora——2017年以降の主要ディストロをほぼ全部巻き込みました。米サイバーセキュリティ庁(CISA)は2026年5月1日にこれを「実際に攻撃されている脆弱性リスト(KEV)」へ追加しています。つまり、机上の危険ではなく実際の攻撃に使われたことが公的に確認された脆弱性です。

本記事の初出は2026年5月12日、CISAが連邦機関に課した修正期限(5月15日)の3日前の速報でした。騒動が一巡した現在は、「Copy Failとは何だったのか、自分のサーバーは大丈夫か」を確かめに来た読者向けの現状整理として書き直しています。公開後の3ヶ月で見えてきたのは、これは1本のバグではなくLinuxの『古い配管』が一斉に剥がれ始めた連鎖の最初の1本だったという構造です。5月にDirty FragFragnesiaが続き、6〜7月にはDirtyClone・GhostLock・RefluXFSなど、長年潜伏していた権限昇格バグの公開が相次ぎました(詳細は後述)。

日本国内では、JPCERT/CCがJVNVU#96811810として日本語の注意喚起を出しています(Copy FailとDirty Fragをまとめたもの)。Ubuntuを使っている方がまず気にするのは「自分のバージョンは対象なのか」という点だと思いますが、Ubuntu 26.04(kernel 7.0系)は影響を受けません。対象は24.04 LTS以前で、修正パッケージは全対象バージョン向けに配布済みです。詳しいディストロ別の対象範囲は後述の早見表にまとめました。

CISAの修正期限(2026年5月15日)はとうに過ぎましたが、脆弱性そのものが消えたわけではありません。未パッチのまま残ったサーバーは、Copy Fail以降に立て続けに見つかった同型バグでも踏まれます。むしろ「全部一度に対処する機会」として、本記事の判断フレームを参考にしてください。

Copy Failとはどんな脆弱性か

Copy Failは、Linuxカーネルの「暗号処理を担当する部品」にあるバグです。

少し噛み砕いて説明します。Linuxはディスク暗号化(dm-crypt)やIPsec通信など、内部で暗号処理を多用します。これを行うために、カーネルにはアプリケーションから暗号機能を呼び出すための窓口があり、その仕組みのひとつが「AF_ALG」(AFアルジー)と呼ばれるソケットです。ここで言うソケットは、プログラムからカーネルの機能にアクセスするための通信路と考えてください。

問題は、暗号処理の中で2017年に追加された「インプレース最適化」という処理にありました。本来「処理元のデータ」と「処理結果の保存先」は別のメモリ領域であるべきところを、効率化のためにわざと同じメモリを使い回す最適化です。これと、ファイルの一部を別の場所に動かすsplice()というシステムコールを組み合わせることで、攻撃者はメモリ上にキャッシュされたファイルの内容を、4バイト分だけ任意に書き換えられることが分かりました。カーネル本体の修正は、この2017年の最適化を差し戻す(元のコードに戻す)形で行われています(コミット a664bf3d603d)。

たった4バイトと侮ってはいけません。Linuxには「suコマンド」「sudoコマンド」のように、実行されると自動的にroot権限で動く特権バイナリがあります。これらのバイナリのメモリイメージを4バイトだけ書き換えるだけで、攻撃者は任意のコードをroot権限で実行できるようになります。

不気味なのは、ディスク上のファイル自体は一切変更されないという点です。書き換えはメモリ上のキャッシュ領域(page cache、ページキャッシュ)でしか起きません。通常のフォレンジック調査では「ファイルが改ざんされていない」と見えるため、攻撃の痕跡が残りにくい構造です。

技術的な詳細は、セキュリティ企業XintPalo Alto Networks Unit 42Tenableのレポートにまとまっています。

「攻撃は決定論的に成立し、レース条件(タイミング次第で失敗する不安定さ)に依存しない。732バイトの単一Pythonスクリプトで100%の成功率で動作する」(Unit 42レポートより

なぜ全ディストリビューションが同時に影響を受けるのか

普通、Linuxの種類(ディストリビューション)はUbuntu、Red Hat、Debian、SUSE と無数に枝分かれしています。それでもCopy Failが「全ディストロ同時陥落」と言われるのは、バグの場所がLinuxカーネル本体だからです。

Linuxカーネルとは、OSの心臓部にあたるソフトウェアです。UbuntuもRed Hat Enterprise LinuxもAmazon Linuxも、Linuxカーネルという「同じエンジン」を別々の車体に積み込んでいるだけ、というイメージに近いです。エンジンにヒビが入れば、車体の違いに関係なく走れません。

Ubuntuはどのバージョンが対象か(26.04は影響なし)

Ubuntu 26.04(コードネームResolute、kernel 7.0系)は影響を受けません。修正済みのカーネルを最初から積んでいるためです。一方、24.04 LTS・22.04 LTS・20.04 LTSなど、それ以前のリリースはすべて対象で、パッケージ更新と再起動が必要です。修正カーネルは全対象バージョン向けに配布済みで、たとえば24.04は6.8.0-117.117、22.04は5.15.0-179.189、20.04は5.4.0-230.250以降が修正済みです(Ubuntu公式アナウンス)。なお、GitHubで公開されたPoC(攻撃の実証コード)を26.04で実行しても権限昇格に失敗する、という報告が出ていますが、これは26.04がすでに修正済みであることの裏返しです。下表で他のディストリビューションも含めた全体像を確認してください。

ディストリビューション影響範囲
Ubuntu14.04 / 16.04 / 18.04 / 20.04 / 22.04 / 24.04 / 25.10
(26.04は対象外)
Red Hat Enterprise Linux10.1 ほか主要バージョン
Amazon Linux2023
SUSESUSE Linux Enterprise 16
Debian / Fedora / Arch / AlmaLinuxカーネル4.14以降で
修正版(下記)より前の全リリース

カーネル本体での修正版は 5.10.254 / 5.15.204 / 6.1.170 / 6.6.137 / 6.12.85 / 6.18.22 / 6.19.12 以降です(NVD記載の影響範囲の裏返し)。2026年7月時点で配布中の各系列——6.18.39 / 6.12.96 / 6.6.144 / 6.1.177 / 5.15.211 / 5.10.260 など——はいずれもこれを大きく上回っており、カーネルを更新してさえいれば修正済みです。ディストロのパッケージを使っている場合は、上のUbuntuの例のようにディストロ側の修正版番号で判定してください。

商用サーバー、自宅サーバー、Kubernetesクラスタ、AWSのEC2インスタンス、IoT機器、Android端末の一部——デスクトップLinuxのシェアがついに5%を超えたように、Linuxが動いている現場は年々増えています。Copy Failはそのほぼ全てを射程に入れます。

Unit 42 は「数百万システムが対象」と推定しました。Microsoftは「数百万のKubernetesクラスタが影響範囲」と表現しています。

築30年オフィスビルの空調ダクトと同じ話

技術的な説明が続いたので、ここで一度、別の物に置き換えてみます。

Linuxカーネルの内部は、築30年のオフィスビルの空調ダクトに似ています。ビルの外側(アプリケーション層)はリフォームが進み、内装は最新に見えます。しかし天井裏には、20年前に張り巡らされた古い配管が、いまも現役で動いています。図面を読める設備技師は減り、長く誰も検査していなかった——そんな状態です。

2026年に入って、ようやくサーモグラフィー(syzkallerのような新世代のファジングツール)と新人技師(AI支援の解析)が天井裏に入りました。すると4月29日、まず1本の配管に亀裂が見つかります——それが、この記事の主役Copy Failです。1週間後、別フロアで類似の配管が裂けます(Dirty Frag)。さらにその1週間後、別の階の隣接配管が破裂します(Fragnesia)。亀裂の場所は別々ですが、いずれも「20年前の同じ設計思想で施工された配管」です。

破裂した個別の配管を直しても、同じ設計の配管はビル全体に張り巡らされています。初出時に「第4・第5の破裂は、近いうちに別の階で起きる」と書きましたが、この予想は現実になりました。5月20日にptrace(プロセスを監視・操作する仕組み)経由の権限昇格CVE-2026-46333、7月6日にDirtyClone(CVE-2026-46331)、7月には2011年から15年間潜伏していたGhostLock(CVE-2026-43499)の公開エクスプロイト、7月22日にはXFSファイルシステムで2017年から潜伏していたRefluXFS(CVE-2026-64600)——別の階の配管が実際に次々と破裂しています。やるべきことは変わらず2つです。破裂した配管をいち早く塞ぐこと(パッチ適用)。そして、必要のないフロアでは元栓を閉めて配管系統そのものから切り離すこと(モジュール無効化)。これを並行して進めるのが、運用者の仕事になります。

あなたのサーバーで、今夜何が起きうるのか

Copy Failは、技術的には「サーバーにログインできる一般ユーザー権限」を出発点とします。WebアプリのRCE(任意コード実行)で奪った非rootシェル、開発者の踏み台アカウント、共用クラウド環境の隣のテナント——どれもが起点になりえます。業務シーンに翻訳すると、こうなります。

該当する場合想定される業務影響物理感覚で言うと
EC2やVMでECサイトを動かしている管理画面が乗っ取られ、
顧客DBが静かに吸い出される
真夜中に商店街の店主の知らぬ間に
レジの中身が抜かれ、朝の棚卸しで初めて気づく
self-hosted のGitHub Actionsランナーを
運用している
CIシークレットが流出し、
デプロイ済みコードが書き換えられる
印刷所に渡したはずの原稿が、
刷られる前にこっそり差し替えられて世に出る
社内Jenkinsや踏み台サーバーがある侵入の足場として横展開され、
社内ネットワーク全体が射程に入る
ビル裏口の合鍵が複製され、
全フロアの執務室を夜な夜な回遊される
自前ビルドのKubernetesクラスタを
運用している
ノードのリソースが暗号資産マイニングに
勝手に転用され、応答が鈍る
店の照明が突然暗くなり、
レジが反応せず、客が黙って帰っていく
個人情報を扱うサービスを
Linux上で運用している
侵害報告義務・損害賠償・
個人情報保護委員会対応の範囲
会社の金庫の暗証番号が、
もう闇市場の値札に貼られている

これら全部、Copy Failのような「全ディストロを巻き込む権限昇格バグ」が1本でも残っていれば、現実的なシナリオです。

「やられたら、どう気づくのか」

Copy Failの厄介な特徴は、ディスク上のファイルは改ざんされない点です。通常のファイル整合性監視(Tripwire、AIDE等)は無力です。

玄関ドアノブを回すと、一瞬だけ何かに引っかかる感覚——SSHログインが瞬間的に詰まる、ログイン直後のプロセス一覧に見慣れないものが混ざる。自分の手帳に、書いた覚えのない予定が勝手に増えている——crontab/etc/cron.d/に身に覚えのないジョブが追加されている。日記帳が一晩で異様に分厚くなっている——journaldのログサイズが急に膨らみ、algif_aead関連の関数呼び出しが異常頻度で記録される。電気代の請求書が、先月の3倍届く——AWS / GCP / Azureの請求額が突発的に跳ね上がり、CloudTrailに不自然なAssumeRoleバーストが残る。

技術的にはdmesgのAF_ALG関連の異常メッセージ、auditdで記録されたsetuid(0)呼び出しの親プロセス系統、SIEMでの不自然なrootシェル取得イベントが該当します。

全ディストロを巻き込むLinux脆弱性の系譜。Copy Failはその起点になった

Linuxカーネルが「主要ディストロを同時に巻き込む」深刻な権限昇格バグを出すのは、これが初めてではありません。過去にも近い構造のバグが定期的に発生しており、見比べると今回の位置付けが分かりやすくなります。

名称CVE公開日バグの場所
PwnKitCVE-2021-40342022年1月polkit(権限管理)
Dirty PipeCVE-2022-08472022年3月カーネル内のパイプ機構
Looney TunablesCVE-2023-49112023年10月glibc(動的リンカ)
Copy Fail(本記事)CVE-2026-314312026年4月29日カーネル暗号窓口(AF_ALG)
Dirty FragCVE-2026-43284 ほか2026年5月7日IPsec ESP / RxRPC
FragnesiaCVE-2026-463002026年5月13日IPsec ESP / socket buffer

PwnKitからLooney Tunablesまでは1〜2年に1度の頻度でした。それがCopy Failを起点に、5月だけで3本のペースに加速し、その後も止まっていません。5月20日にptrace経由の権限昇格CVE-2026-463337月6日にDirtyClone(CVE-2026-46331、CVSS 8.8)7月にはGhostLock(CVE-2026-43499、2011年から15年潜伏、5秒でroot取得の公開エクスプロイトあり)7月22日にはRefluXFS(CVE-2026-64600)。バグの所在は権限管理ツール、パイプ、ライブラリ、暗号窓口、IPsec、ファイルシステムと一見バラバラですが、運用者から見ると影響は同型です。「Linuxを使っている限り、ほぼ全部のサーバーで管理者権限を奪われ得る」という現実が、2026年に入って何度も繰り返されています。

本記事のCopy Failは、その連鎖の第1報に位置します。続編は第3報のFragnesia記事にまとめてあります(Dirty Fragはそちらの解説に含まれます)。

運用者がやるべきこと。4層の防御フレーム

単一のスイッチで止められる脆弱性ではないため、4層に分けて順に対処します。本フレームは、続編のDirty Frag・Fragnesiaや、6〜7月に出た同型バグにもそのまま流用できる設計にしてあります。

第1層:パッチを当てる(最優先)

Ubuntuの場合、以下のコマンドで対応するカーネルパッケージが取得できます(Ubuntu公式アナウンス)。

sudo apt update && sudo apt upgrade
sudo reboot

Red Hat、Amazon Linux、SUSEもそれぞれパッチを公開しています。Red HatのアドバイザリIBM Cloud Kubernetesを含む各クラウドベンダーの公式情報も合わせて確認してください。

第2層:すぐに再起動できない場合の暫定緩和策

問題の経路になっているalgif_aeadというカーネルモジュールを無効化すると、攻撃の経路を塞げます。Ubuntuは専用のkmodパッケージを通じて無効化を提供しています。手動でやる場合は、以下のファイルを作成します。

/etc/modprobe.d/disable-algif.conf

blacklist algif_aead
install algif_aead /bin/true

ただし、ディスク暗号化やIPsec VPNなどで暗号機能を多用している環境では、事前に依存関係を確認してから適用してください。本番環境でいきなり適用すると、関連サービスが起動しなくなる可能性があります。

第3層:一般ユーザーの権限をさらに削る

攻撃の前提となる「一般ユーザーがカーネルの暗号機能を呼べる」状態自体を絞ります。サーバーの用途に応じて以下を検討してください。

  • 一般ユーザーが新しい権限空間(user namespace)を作る機能を無効化:sysctl kernel.unprivileged_userns_clone=0
  • コンテナ実行時のseccompプロファイルでAF_ALGソケットの作成やkeyctlを制限
  • AppArmor / SELinuxでsocket(AF_ALG, ...)を呼べるバイナリを限定

第4層:監視で「未然」と「事後」を拾う

Unit 42は2つの検知パターンを推奨しています。

  • 非rootユーザーが、通常想定されない親プロセスからsuコマンドを実行した場合
  • curlで何かをダウンロードした直後にsuが実行される(公開済みPoCの典型的なパターン)

eBPF(カーネル内で動く監視機構)を使ったソリューションでは、socket(AF_ALG, ...)splice()の組み合わせ呼び出しを警報対象に設定するのが有効です。Microsoft Defenderは既にCopy Fail関連の活動を検知対象に組み込んでおり、SplunkやTrend Microも検知ガイドを公開しています。EDR(エンドポイント検知ソフト)を入れている組織はシグネチャの更新状況を確認してください。

クラウドとコンテナで影響が拡大する理由

Copy Failがもう一段恐ろしいのは、クラウドとコンテナの構造に効く点です。

DockerやKubernetesなどのコンテナ技術は、複数のコンテナがホストのLinuxカーネルを共有して動いています。コンテナの中の一般ユーザーがCopy Failを使った場合、こんな流れが成立します。

  1. コンテナ内でroot権限を取得(ここまではコンテナの中の話)
  2. ホストのカーネルは共有されているので、ホスト側のページキャッシュにも書き込み可能
  3. ホスト側の特権バイナリを汚染し、コンテナの外(ホストOS)に脱出

これが「コンテナを破る攻撃(コンテナブレイクアウト)」です。Microsoftは「数百万のKubernetesクラスタが影響範囲」と表現しました。

クラウド側でも、複数の顧客のワークロードが同じホストの上で動いているマルチテナント環境では、隣のテナントへの影響波及(lateral movement、横展開)が現実的な脅威になります。runCなどのコンテナランタイム単体の修正だけでは塞げないため、ホストのカーネル更新が必須です。

3月だけで日本の製造業7社がランサムウェア被害を公表したと先月レポートしたとおり、攻撃者は「足がかりを取った後の特権昇格の道具」を常に欲しがっています。Trivyのサプライチェーン連鎖侵害のような事案で初期アクセスを取った後、Copy Failは「次の一手」を与える脆弱性として機能します。

発見の経緯と公開タイムライン

発見者は韓国のセキュリティ企業Theoriに所属するTaeyang Lee氏。Linuxカーネルの暗号サブシステムを調査する過程で、最初の攻撃面を特定しました。Xint Code Research TeamがAIを使った解析でこの発見を拡張し、約1時間で最も深刻な「Copy Fail」を特定しました。

タイムラインは以下のとおりです。

  • 2026年3月23日——Linuxカーネルセキュリティチームへ初報
  • 2026年4月1日——mainlineへパッチがコミット
  • 2026年4月29日——Xintが脆弱性を公開(Copy Failの誕生)
  • 2026年5月1日——CISAがKEVへ追加、連邦機関に5月15日までのパッチ適用を義務化
  • 2026年5月7日——Dirty Fragが公開(同型バグの2本目)
  • 2026年5月13日——Fragnesiaが公開(3本目、3週間で3度)
  • 2026年5月15日——CISA KEV期限到達
  • 2026年5月20日——Qualysがptrace経由の権限昇格CVE-2026-46333を公開(同型バグの4本目)
  • 2026年5月25日——日本のJPCERT/CCがJVNVU#96811810を発出。Copy FailとDirty Fragの日本語注意喚起が揃う
  • 2026年7月6日——DirtyClone(CVE-2026-46331、CVSS 8.8)が公開
  • 2026年7月上旬——GhostLock(CVE-2026-43499、2011年から潜伏)の公開エクスプロイトが流通
  • 2026年7月22日——RefluXFS(CVE-2026-64600、2017年のカーネル4.11から潜伏)をQualysが公開
  • 2026年7月23日時点の現状——配布中の全安定版・長期サポート版カーネルはCopy Fail修正済み。KEVカタログ上のランサムウェアでの利用は「不明(Unknown)」のまま

カーネル開発者の対応は24時間以内に開始され、9日でパッチがコミットされた、極めて迅速な対応でした。一方で公開から3ヶ月近くが経ち、発見元Theoriによる公式PoC(攻撃の実証コード)がGitHubで公開され、攻撃側の道具立ては出そろっています。大規模なランサムウェアやボットネットでの悪用が公表された事例は2026年7月23日時点で確認されていませんが、VulnCheckは2026年上半期に日常的に狙われた脆弱性の1つとしてCopy Failを挙げています。Wikipediaにも独立した項目が立つほど、業界における認知度は高まりました。

いまから対処する人へ。遅すぎることはない

CISAが連邦機関に課した修正期限は2026年5月15日で、すでに2ヶ月以上前に過ぎています。「期限内に対処できなかった、もう手遅れだ」と思ってこの記事に辿り着いた方もいるかもしれません。そんなことはありません。理由は3つあります。

第1に、未パッチのサーバーは、Copy Fail以降に立て続けに出た同型バグ(Dirty Frag・Fragnesia・DirtyClone・GhostLock・RefluXFS)でも踏まれます。攻撃者は1本の脆弱性が塞がれたら次のを使うだけです。今からカーネルを最新の修正版へ上げれば、この連鎖をまとめて塞げます。

第2に、本記事の判断フレームは「次の同型バグ」にもそのまま使えます。初出時に「第4・第5の同型バグはほぼ確実に来る」と書きましたが、実際に6〜7月のDirtyClone・GhostLock・RefluXFSで現実になりました。Copy Failの対応をテンプレ化しておけば、次の波が来たときに数時間で動けます。

第3に、日本のJPCERT/CCが日本語の注意喚起を出しているため、社内の決裁を通しやすい状況が続いています。「米CISAがKEVに入れた」だけでは社内が動かなかった組織でも、「JPCERT/CCがJVNVU#96811810を出した」と添えれば話が通る現場は多いはずです。社内で説明するときの材料に、本記事とJVNVU#96811810を一緒に共有してください。

優先順位はこうです。まず、手元のUbuntu / Red Hat / Amazon Linux / SUSE / Debian / Fedoraの対象バージョンを洗い出すこと。次に、すぐパッチを当てられるサーバーと、依存サービスがあって慎重に当てる必要があるサーバーを分け、後者はalgif_aead無効化で時間を稼ぐ判断もあり得ます。Kubernetesクラスタのノードはホストカーネル更新が必須なので、ローリングアップデート計画を先送りしないでください。

Copy Failのような脆弱性は、修正版が出て3ヶ月経っても消えてなくなるわけではありません。修正されないまま残ったサーバ、特にIoT機器や古いオンプレ機器、メンテナンスの主が代替わりして「触れない」状態になっている社内サーバー群は、これから何年も攻撃の的になります。ハローワークの基幹システムが『触れない』状態になっている構造を以前報告しましたが、同じ構造が民間にも数多く眠っています。

系譜の続きと、編集部の追跡

本記事はCopy Failに始まる「Linuxカーネル脆弱性連鎖シリーズ」の第1報です。系譜の続きは本サイトで継続追跡中です。

シリーズ記事

読者の方が担うべきは「自社の責任範囲を自覚すること」までで、系譜全体の継続観測は本サイトの編集部が引き受けます。次の破裂が起きたとき、本記事と続編の判断フレームがそのまま使えるように構成してありますので、ブックマークしておいてください。

参照元

Linuxカーネル脆弱性連鎖シリーズ・次報

Linuxの『古い配管』、3週間で3度目の同時破裂。サーバー乗っ取り連鎖(Fragnesia / CVE-2026-46300)→
avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go