Linux権限昇格『Copy Fail』CVE-2026-31431とは

脆弱性・脅威情報

結論から。Linuxカーネルに、ローカルの一般ユーザーが管理者(root)権限を奪取できる権限昇格の脆弱性「Copy Fail」(CVE-2026-31431)が見つかりました。2017年以降の幅広いカーネルが対象で、Ubuntu・RHEL・Amazon Linux・SUSE などほぼ全ディストリビューションに影響します。CVSSは7.8(重要)。732バイトの実証コードが公開済みで、まだパッチを当てていない環境は最優先で対応すべき状況です。

この記事でわかること

  • Copy Fail(CVE-2026-31431)とは何か、何が危険なのか
  • 影響を受ける環境と、特に注意すべきクラウド・コンテナの事情
  • パッチ適用と、すぐ当てられない場合の暫定回避策
  • 情シスがいま確認・説明すべきこと

Copy Fail(CVE-2026-31431)とは

Copy Failとは、Linuxカーネルの暗号処理インターフェース(af_alg / algif_aead)に存在するローカル権限昇格(LPE)の脆弱性です。ネットワーク越しではなく、すでにそのマシンに一般ユーザーとしてログインできる攻撃者が、root権限へ昇格できる点が本質です。CVSS v3.1の評価は AV:L(ローカル)・PR:L(低い権限が必要)で、スコアは7.8(重要)とされています。

公表は2026年4月29日、IPAは5月1日に注意喚起を出し(5月7日更新)、上流カーネルへの修正は4月1日にコミットされています。すでに修正版が各ディストリビューションから提供されているため、本稿は「未対応なら今すぐ」という性質の記事です。

なぜ危険なのか — 「当たれば確実に効く」

この脆弱性が注目されるのは、悪用が極めて容易で信頼性が高い点にあります。セキュリティベンダー各社の解析によれば、Copy Failは競合状態(レース)に頼らない「直線的なロジックの欠陥」で、カーネルのメモリ配置(オフセット)を推測する必要もありません。

  • 732バイトのPythonスクリプト1つで動作し、コンパイルも外部依存も不要
  • 2017年以降の主要ディストリビューションで改変なしにそのまま通る
  • 初回の実行で成功する、ほぼ100%の再現性

実証コード(PoC)は公開済みで、ベンダーは「初期段階の試行的な活動」を観測したとも報告しています。攻撃のハードルが低く、踏み台にされやすい類の脆弱性だと捉えるべきでしょう。

影響を受ける環境

IPAは「4.14以降の一定のバージョンのLinuxカーネルが影響を受ける」としています。実質的にはサーバー・クラウド・組み込みを問わず広範です。主なディストリビューションの状況は次のとおりです(詳細・正確な対象バージョンは必ず各開発元の公式情報で確認してください)。

ディストリビューション 状況(概要)
Ubuntu 26.04(Resolute)を除く全リリースが影響。14.04〜25.10に修正版を提供
Red Hat Enterprise Linux 影響あり。2026年5月4日以降、順次修正を提供
Amazon Linux 2023 / SUSE / Debian / Fedora 等 いずれも影響あり。各公式の更新情報を参照

クラウド・コンテナでは「ローカル前提」が崩れる

「ローカルでログインできる攻撃者が前提」と聞くと、自社サーバーだけ気をつければよいと感じるかもしれません。しかしクラウド・コンテナ環境では事情が異なります。

カーネルとページキャッシュはノード上の全コンテナで共有されるため、影響を受けるカーネル上で動くコンテナは、それ自体が権限昇格の入口になり得ます。ベンダーの解説では、あるコンテナ内でキャッシュ上の特権バイナリ(例:/usr/bin/su)を書き換えると、ホストや同居する他コンテナにも影響が及ぶとされ、コンテナ脱出やマルチテナントホストの乗っ取りにつながる危険が指摘されています。とりわけ信頼できないワークロードを動かすKubernetes基盤では、リスクの見積もりを一段引き上げる必要があります。

情シスはどうすべきか

基本方針はシンプルです。カーネルを更新し、再起動する。これに尽きます。Ubuntu系であれば sudo apt update && sudo apt upgrade 後に再起動でカーネルの修正が有効化されます(各環境のパッケージ管理に読み替えてください)。再起動を伴うため、サーバーは計画的なメンテナンス枠の確保が現実的な課題になります。

すぐにパッチを当てられない場合の暫定回避策として、影響するモジュールの無効化が案内されています。具体的には起動パラメータでの初期化ブロック(例:initcall_blacklist=algif_aead_init など)です。ただしハードウェア暗号アクセラレーションを使うアプリでは性能低下が起こり得るため、適用前に処理への影響を必ずテストしてください。あわせて、ローカルアクセスの制限、ワークロードの非rootでの実行、SELinux等の有効化といった多層防御も有効です。

優先順位の付け方や脆弱性管理の進め方そのものに不安がある場合は、自前でチェックリストを作り込む前に、IPAの公的な指針を出発点にすると説明責任も果たしやすくなります。中小規模の組織であれば、まず中小企業の情報セキュリティ対策ガイドラインで運用の型を押さえるのがおすすめです。日々の更新適用を確実に回す地道な体制づくりこそが、この種の「枯れた前提を突く」脆弱性への最良の備えになります。

現場目線の所感

正直なところ、最も悩ましいのは「再起動を伴うサーバー更新」を、稼働中の業務サービスに対していつ・どう実施するかの調整です。脆弱性そのものより、止められないサーバーの存在と、夜間メンテの人員確保のほうが現場の壁になりがちです。さらに、開発チームが立てた検証用VMや、誰が管理しているのか曖昧になったコンテナ基盤など、「資産として把握しきれていないLinux」こそ穴になります。今回を機に、棚卸し済みのサーバーだけでなく、影の資産にも目を向けたいところです。

まとめ

  • Copy Fail(CVE-2026-31431)は、一般ユーザーがrootを奪える信頼性の高いLinux権限昇格。CVSS7.8、PoC公開済みで未対応環境は最優先で対応を。
  • 2017年以降の幅広いカーネルが対象。クラウド・コンテナではコンテナ脱出やマルチテナント乗っ取りに直結し得る。
  • 対応はカーネル更新+再起動が基本。即時対応が難しければモジュール無効化の暫定回避策(性能影響に注意)を検討し、把握漏れのLinux資産も点検する。

出典・参考

タイトルとURLをコピーしました