Ubuntu含むLinuxに権限奪取『Copy Fail』CVE-2026-31431、26.04は影響なし

あなたのLinuxサーバーは、もう踏まれているかもしれません。そしてその起点になったバグの名前は「Copy Fail」と呼ばれています。

2026年4月29日に公開されたCVE-2026-31431、通称「Copy Fail（コピーフェイル）」は、たった732バイトのPythonスクリプトで、世界中のLinuxサーバーで一般ユーザーが管理者権限（root）を奪える脆弱性です。Ubuntu、Red Hat、Amazon Linux、SUSE、Debian、Fedora——2017年以降の主要ディストロをほぼ全部巻き込みました。米サイバーセキュリティ庁（CISA）は5月1日にこれを「実際に攻撃されている脆弱性リスト（KEV）」へ追加し、米連邦機関に5月15日までのパッチ適用を義務付けました。

本記事を最初に公開したのは2026年5月12日、CISA期限まで残り3日の段階でした。あれから2週間が経ち、いま見えてきたのは「これは1本のバグではなく、Linuxの『古い配管』が一斉に剥がれ始めた連鎖の最初の1本だった」という構造です。続く5月7日にDirty Frag、5月13日にFragnesia。3週間で3度、同じ型の権限昇格バグが立て続けに出ました。本記事はその連鎖の起点を、いま改めて運用者の判断材料として書き直したものです。

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

Copy Failとはどんな脆弱性か

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

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

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

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

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

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

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

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

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

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

「ubuntu copy fail」で検索して自分の環境を確認したい方向けに、先にUbuntuだけ切り出します。Ubuntu 26.04（コードネームResolute、kernel 7.0系）は影響を受けません。修正済みのカーネルを最初から積んでいるためです。一方、24.04 LTS・22.04 LTS・20.04 LTSなど、それ以前のリリースはすべて対象で、パッケージ更新と再起動が必要です。なお、GitHubで公開されたPoC（攻撃の実証コード）を26.04で実行しても権限昇格に失敗する、という報告が出ていますが、これは26.04がすでに修正済みであることの裏返しです。下表で他のディストリビューションも含めた全体像を確認してください。

商用サーバー、自宅サーバー、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の破裂は、近いうちに別の階で起きます。やるべきことは2つです。破裂した配管をいち早く塞ぐこと（パッチ適用）。そして、必要のないフロアでは元栓を閉めて配管系統そのものから切り離すこと（モジュール無効化）。これを並行して進めるのが、運用者の仕事になります。

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

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

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

PwnKitからLooney Tunablesまでは1〜2年に1度の頻度でした。それがCopy Failを起点に、3週間で3本のペースに加速しています。バグの所在は権限管理ツール、パイプ、ライブラリ、暗号窓口、IPsecと一見バラバラですが、運用者から見ると影響は同型です。「Linuxを使っている限り、ほぼ全部のサーバーで管理者権限を奪われ得る」という現実が、3週間で3度繰り返されました。

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

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

「明日までに何をすればいいのか」を整理します。単一のスイッチで止められる脆弱性ではないため、4層に分けて段階的に対処します。本フレームは、続編のDirty Frag・Fragniesiaにもそのまま流用できる設計にしてあります。

第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パッケージを通じて無効化を提供しています。手動でやる場合は、以下のファイルを作成します。

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関連の活動を検知対象に組み込んでいます。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月25日——日本のJPCERT/CCがJVNVU#96811810を発出。Copy FailとDirty Fragの日本語注意喚起が揃う

カーネル開発者の対応は24時間以内に開始され、9日でパッチがコミットされた、極めて迅速な対応でした。一方で、公開から1ヶ月近く経った今、PoCも各所で流通し、攻撃側にとっても準備は十二分に整っています。Wikipediaにも独立した項目が立つほど、業界における認知度は高まりました。

CISA期限を過ぎた今こそ、まだ手を打っていない人へ

5月15日のCISA KEV期限は過ぎました。「期限内に対処できなかった、もう手遅れだ」と思ってこの記事に辿り着いた方も多いかもしれません。そんなことはありません。むしろ、いまこそが最後のチャンスです。理由は3つあります。

第1に、未パッチのサーバーは、Copy Fail以降に立て続けに出た同型バグ（Dirty Frag・Fragnesia）でも踏まれます。攻撃者は1本の脆弱性が塞がれたら次のを使うだけです。今からまとめてパッチを当てれば、3本の連鎖を一度に塞げる機会でもあります。

第2に、本記事の判断フレームは「次の同型バグ」にもそのまま使えます。本シリーズの第3報（Fragnesia）でも書いたとおり、Linuxの「古い配管」は、まだ他の階で破裂を待っています。第4・第5の同型バグはほぼ確実に来ます。Copy Failの対応をテンプレ化しておけば、次の波が来たときに数時間で動けます。

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

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

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

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

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

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

参照元

• ▸Microsoft Security Blog - CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments（2026年5月1日）
• ▸Palo Alto Networks Unit 42 - Copy Fail: What You Need to Know
• ▸Xint - Copy Fail: 732 Bytes to Root on Every Major Linux Distribution（2026年4月29日）
• ▸Tenable - Copy Fail (CVE-2026-31431): FAQ
• ▸Ubuntu Blog - Fixes available for CVE-2026-31431 (Copy Fail)
• ▸Red Hat - CVE-2026-31431
• ▸CISA - Known Exploited Vulnerabilities Catalog
• ▸CERT-EU - High Vulnerability in the Linux Kernel ("Copy Fail")
• ▸JVN VU#96811810 - Linuxカーネルにおける複数の脆弱性（Copy Fail / Dirty Frag）
• ▸NVD - CVE-2026-31431
• ▸Wikipedia - Copy Fail