2026年4月29日、Linuxカーネルのローカル権限昇格脆弱性「Copy Fail」（CVE-2026-31431）が公開されました。発見者であるTheori社のXint Codeチームによれば、Ubuntu・Amazon Linux・RHEL・SUSEといった主要ディストリビューションで、わずか732バイトのPythonスクリプトを一般ユーザーが実行するだけでroot権限を取得できるとのことです。本記事では、各ディストリビューションのアドバイザリで判断材料が揃い始めた段階の情報を整理し、実務者が「自社の環境で何を確認すべきか」を判断できるところまでを解説します。
同じ脆弱性に対して各ベンダーの深刻度評価とパッチ提供状況に差が出ている点も、運用判断において見過ごせない論点です。CNAであるkernel.orgが付与したCVSS 3.1スコアは7.8（High）です。Ubuntu公式CVE追跡ページではHigh priority、CVSS 7.8、StatusはVulnerableとして追跡されています。SUSE公式CVEページでは、本稿執筆時点でstateがPending、severityはimportant、CVSS Base Scoreは7.8と表示されています。Red Hat公式CVEページは閲覧にJavaScript実行を要するため、本稿では直接確認できていません。最新の評価および修正状態は、利用環境のディストリビューション公式ページで確認してください。本稿執筆時点で各ディストリビューションの最終的なパッチ提供状況は更新中のため、この記事では脆弱性の成立条件と、共通して取り得る暫定対策に重きを置きます。
脆弱性の概要
Copy Failは、Linuxカーネルのcrypto/algif_aeadサブシステムにおける論理バグです。Theori公開資料によれば、AF_ALGソケット、splice()システムコール、authencesn暗号テンプレートという3つの仕組みが交差する経路で、非特権ローカルユーザーが「任意の可読ファイルのページキャッシュ」に対して制御された4バイトの書き込みを行えるとされています。
ページキャッシュとは、ファイルの内容をメモリに一時保存する仕組みです。Linuxカーネルはバイナリを実行する際、ディスクから読み直すのではなくページキャッシュ上のコピーを参照します。したがって、ページキャッシュに書き込めるということは、実行時のバイナリの中身を改変できることに等しい、というのが今回の本質です。setuidバイナリ（root権限で実行されるバイナリ）のページキャッシュコピーを書き換えれば、一般ユーザーがroot権限を獲得する経路が成立します。
原因となっているコードは2017年に追加されたin-place最適化のロジックに由来するとされ、約9年間にわたってカーネル内に残存していました。修正コミット（a664bf3d603d）はin-place AEAD処理をout-of-place方式に戻すもので、Theori解説によれば2026年4月1日にメインラインカーネルへマージ済みとされています。
影響範囲
Theoriが公開資料で動作確認したと述べているのは、Ubuntu・Amazon Linux・RHEL・SUSEです。発見者側の検証結果ではRHEL 10.1（kernel 6.12.0-124.45.1.el10_1）等が示されています。技術的には、2017年のin-place最適化導入以降のLinuxカーネルが広範に対象となるため、Debian、Fedora、Arch等もコードベース上は影響を受け得ます。
各ディストリビューションの公式CVE追跡ページにおける本稿執筆時点の状況は次の通りです。Ubuntuは、Priority「High」、CVSS 7.8、StatusはVulnerableとして追跡しています。SUSEは、Stateが「Pending」、SeverityはImportant、CVSS Base Scoreは7.8と表示しています。Debian Security Trackerは、bullseye、bookworm、trixie（およびそれぞれのsecurity）を「vulnerable」、forkyとsidを「fixed」と表示しています。Amazon Linuxは、AL2のCore kernelおよびAL2023 kernelをいずれも「Pending Fix」として追跡しています。Red Hat公式CVEページは閲覧にJavaScript実行を要するため本稿では直接確認できていません。これらの追跡状態は時間で変動するため、最終判断は各ベンダー公式の最新更新で確認してください。
つまり、「主要ディストリビューションだから修正済み」と一括りで判断できる段階ではなく、利用しているディストリビューションのリリース系列ごとに公式CVEページでパッケージ更新の有無を確認する必要があります。カーネルのバグであるため、修正パッケージを適用しても再起動するまで反映されない点も運用上の注意点です。
過去の権限昇格脆弱性との違い
Copy Failが過去の有名な権限昇格脆弱性、たとえばDirty COW（CVE-2016-5195）やDirty Pipe（CVE-2022-0847）と比較される理由は、攻撃の確実性と検知の難しさという2点にあります。
第一に、Theoriおよび各種報道（The Register、ソフトアンテナ、ccsi.jp等）の説明によれば、Copy Failはレースコンディションに依存しないストレートライン論理バグです。Dirty COW系の脆弱性が「タイミングが合わなければ失敗」「環境によってはクラッシュ」というリスクを抱えていたのに対し、Copy Failはディストリビューション固有のオフセット調整やコンパイル済みペイロードを必要とせず、テストされた主要ディストリビューションで同一PoCによる安定したroot取得が確認されたとされています。
第二に、攻撃の痕跡がディスク上に残らない点が挙げられます。書き換えはメモリ上のページキャッシュに対してのみ行われるため、inotifyのようなファイルシステムイベント監視や、ハッシュ値を比較するファイル整合性チェックでは検出が困難です。一方、プログラム実行時にはメモリ上の改ざんされたデータが参照されるため、攻撃者から見れば「実行時には効果があり、フォレンジック上は跡が残りにくい」という性質を持つことになります。
誰がリスクに直面するか——実務摩擦の所在
Copy Failはローカル権限昇格脆弱性であり、攻撃の前提として「Linuxマシンで一般ユーザー権限のコードを実行できること」が必要です。リモートからの単独悪用が成立する性質ではないため、純粋に「外部からの攻撃面」として考えると優先度を下げたくなる脆弱性に分類されます。
しかし、ワルブリックス株式会社の解説が指摘しているように、実務で多くの組織が直面するのは「一般ユーザー権限を取得できる経路は、想定よりも広い」という現実です。ログイン権限を持つ関係者・元関係者の端末がマルウェアに感染した場合、別ソフトウェアの脆弱性で一般ユーザーとしてのコード実行を奪われた場合、不特定多数が同居するマルチテナント環境を提供している場合などでは、ローカル権限昇格は単独で攻撃チェーンの最終段になりえます。
とくに留意すべきは、ページキャッシュがホストOS全体で共有される性質上、コンテナ環境からホストへの脱出（コンテナエスケープ）が成立し得るという点です。Theori公開資料は、Kubernetesノードへの侵入経路として機能し得ることを指摘しています。1つのPodで実行された攻撃がノード全体の侵害につながる可能性があるため、共有開発サーバー、CI/CDランナー、マルチテナントクラウド環境、Kubernetesクラスターなど「不特定コードが一般ユーザー権限で実行される環境」を運用している組織は、優先度を引き上げて対応する必要があります。
パッチ適用と暫定対策
基本方針は、利用ディストリビューションの公式CVE追跡ページでパッケージ更新を確認し、提供されたら速やかに適用して再起動することです。確認URLは次の通りです（各記事および各ディストリ公式サイトを参照）。
- Ubuntu:
https://ubuntu.com/security/CVE-2026-31431 - Red Hat:
https://access.redhat.com/security/cve/CVE-2026-31431
※ Rocky Linux、AlmaLinux、Oracle Linux、Fedoraなどの派生・関連ディストリビューションは、各プロジェクトの公式追跡ページを別途確認してください。 - SUSE/openSUSE:
https://www.suse.com/security/cve/CVE-2026-31431.html - Debian:
https://security-tracker.debian.org/tracker/CVE-2026-31431 - Amazon Linux:
https://explore.alas.aws.amazon.com/CVE-2026-31431.html
パッチ適用までの暫定対策として、Theori公開資料が提示しているのは、algif_aeadカーネルモジュールの無効化です。多くの一般的なワークロードはalgif_aeadを使用していないため、無効化による業務影響は限定的とされていますが、暗号化処理を行う一部アプリケーションが影響を受ける可能性はあるため、無効化前に依存プロセスの確認（lsof、ssによるAF_ALGソケット使用状況の確認）が推奨されます。
また、untrusted workloadsを実行するコンテナやCI環境では、Theoriはseccompを用いてAF_ALGソケットの作成自体を拒否する追加対策にも言及しています。コンテナ脱出としての側面はパッチで閉じられますが、未パッチノードが残る移行期間中の補助的な防御策として有効と考えられます。
AIによる脆弱性発見という別の論点
Copy Fail公開後、SNS等で技術コミュニティが反応している論点の1つが「発見方法」です。Theoriの公開資料は、本脆弱性が同社のAI駆動セキュリティ監査ツール「Xint Code」によって、Linux crypto/サブシステムに対する約1時間程度のスキャンで発見されたと述べています。研究者Taeyang Lee氏が「暗号化サブシステムとページキャッシュの相互作用」という観点をAIに与えたところ、9年間潜在していた論理バグが特定されたとのことです。Bugcrowdブログが言及しているように、Theoriは複数回のDEF CON CTF優勝経験を持つ著名な攻撃的セキュリティチームであり、ツール側の能力もチーム側の経験値も含めての成果と読むのが妥当でしょう。
とはいえ、「AIで脆弱性スキャンを回せば、長年見逃されていた論理バグが浮上する」という方向性が示された意味は小さくありません。同種のスキャンが攻撃者側でも進めば、未公開の脆弱性が短期間に大量に発見される展開が現実味を帯びてきます。防御側がパッチ適用サイクルや脆弱性管理プロセスをどこまで圧縮できるかが、より問われる時代に入りつつあります。
実務観点での要点
Copy FailをTKC Tech Lab的な実務視点で整理すると、次の3点に集約されます。
1つ目は、リスク評価における「攻撃前提」の見直しです。本脆弱性はローカル権限昇格であり、kernel.orgおよび主要ディストリビューションの公式CVEページではいずれもCVSS 7.8（High／Important相当）として追跡されています。スコアの数値そのものより重要なのは、共有環境・コンテナ環境・マルチテナント環境を運用しているか否かでリスクの実態が大きく変わるという点です。自組織のサーバーで「誰が、どの権限で、どんな経路でコードを実行できるか」を改めて棚卸しする契機にすべきです。
2つ目は、ディストリビューション間の対応速度差を踏まえた運用判断です。Ubuntu公式は本稿執筆時点でVulnerableとして追跡、Amazon LinuxはAL2/AL2023ともにPending Fix、Debianはbullseye/bookworm/trixie がvulnerable・forky/sid がfixedといった状態にあり、ディストリ間で進捗にバラつきがあります。マルチディストリ環境を運用している組織は、ディストリごとにパッチ提供時期と暫定対策の組み合わせを別個に設計する必要があります。
3つ目は、検知能力の見直しです。ディスク基準のファイル整合性監視ではこの種のメモリ書き換え攻撃は捕捉できません。多人数共有環境を2017年以降運用している組織は、メモリフォレンジックや実行ファイルランタイム検査、特権昇格イベントの相関分析の有無を確認するきっかけとすべきです。「跡形が残らない」攻撃が今後も増える前提で、検知レイヤーを再設計する余地があります。
ソース
一次情報
- Theori / Xint Code:
https://xint.io/blog/copy-fail-linux-distributions - 各ディストリビューション公式CVE追跡ページ（前掲URL）
参考情報
- The Register: 「Linux cryptographic code flaw offers fast route to root」
- Bugcrowd: 「What we know about Copy Fail (CVE-2026-31431)」
- ソフトアンテナ: 「Linuxを揺るがす脆弱性『Copy Fail』が発見」
- innovatopia.jp（解説記事）
- ccsi.jp: 「Linuxカーネル『Copy Fail』脆弱性、主要ディストリビューションに広範な影響」
- ワルブリックス株式会社: 「Linux脆弱性 CVE-2026-31431『Copy Fail』は何が危ないのか・対策」
- エーアイセキュリティラボ（Zenn）: 「LinuxカーネルのCopy Fail (CVE-2026-31431) をEC2のUbuntu 22.04で実証してみた」
※本稿のベンダー対応状況は公開時点で確認できた情報に基づきます。カーネル脆弱性は各ディストリビューションのバックポート・追跡ポリシーに差があるため、最終判断は各ベンダー公式のCVE/アドバイザリページをご確認ください。
slug: linux-copy-fail-cve-2026-31431-root-escalation
コメント