🐧

Linuxの脆弱性「Copy Fail（CVE-2026-31431）」をわかりやすく整理する

に公開
Linux
Security
kernel
脆弱性
CVE
tech

はじめに

Linuxカーネルの脆弱性 Copy Fail（CVE-2026-31431） が話題になっています。

ざっくり言うと、これは 一般ユーザーがroot権限を取得できる可能性があるローカル権限昇格（すでにLinux上で動けるユーザーが、より強い権限を得る攻撃）の脆弱性 です。

ポイントは次のとおりです。

  • リモート（インターネット越しなど外部）から直接攻撃する脆弱性ではない
  • すでにLinux上でコードを実行できるユーザーが悪用するタイプ
  • 成功するとroot権限（Linuxの管理者権限）を取られる可能性がある
  • PoC（Proof of Concept。脆弱性を実際に再現できる検証コード）が公開されている
  • コンテナ（Dockerなどの隔離された実行環境）、CI/CDランナー（テストやビルドを自動実行するサーバー）、共用Linuxサーバーでは特に注意が必要

CERT-EU（EU機関向けのセキュリティ対応組織。脆弱性やサイバー攻撃の注意喚起を出している組織）では、CVSS（脆弱性の深刻度を0.0〜10.0で表すスコア）7.8 Highとして扱われています。

NVD（米国NISTが運営する脆弱性データベース）では、記事執筆時点で enrichment 待ち（NVD側の詳細分析がまだ完了していない状態。影響製品やスコアなどの整理が未完了という意味）でした。ただし、kernel.org由来のCVSS v3.1ベクトル（Linuxカーネル側から提供された深刻度評価情報）は登録されています。

この記事では、Copy Failについて、できるだけわかりやすく整理します。

この記事は2026年5月1日時点で確認できる公開情報をもとにしています。各ディストリビューションの対応状況は変わる可能性があるため、実際の対応では公式のセキュリティ情報を確認してください。

まず「ローカル権限昇格」とは

ローカル権限昇格とは、すでにサーバー内に入った攻撃者が、より強い権限を得る攻撃です。

たとえば、最初は一般ユーザーとしてしか操作できなかったのに、脆弱性を悪用してroot権限（Linuxの管理者権限）を取得する、というイメージです。

一般ユーザー
  ↓
脆弱性を悪用
  ↓
root権限

つまりCopy Failは、インターネット越しにいきなりrootを取るタイプではありません。

ただし、Webアプリの脆弱性、SSH鍵（サーバーにログインするための認証鍵）の流出、CI/CD上の任意コード実行（攻撃者や外部由来のコードをCI/CD環境で動かせる状態）などで一度Linux上に入られると、その後のroot権限取得に使われる可能性があります。

「ローカル脆弱性だから大丈夫」とは言い切れません。

Copy Failとは何か

Copy Failは、Linuxカーネルの暗号処理機能に関係する脆弱性です。

もう少し具体的には、AF_ALG、algif_aead、authencesn、splice() が関係しています。

AF_ALG は、ユーザー側のプログラムからLinuxカーネル内の暗号機能を使うための窓口です。

algif_aead は、その暗号処理機能の一部です。AEAD（Authenticated Encryption with Associated Data。暗号化と改ざん検知をまとめて行う暗号方式）を扱う処理に関係します。

authencesn は、暗号処理で使われるテンプレートの一種です。

splice() は、ユーザー空間にデータをコピーせずに、ファイルやパイプ間でデータを効率よく受け渡すLinuxの仕組みです。

原因は、2017年ごろに入った in-place処理（別の場所にコピーせず、同じ場所のデータを直接処理する方法）の最適化 にあります。

本来であれば、安全にコピーして処理すべきデータを、効率化のために同じ場所で処理しようとした結果、ページキャッシュ（ファイル読み書きを速くするため、ディスク上の内容をメモリに一時保存する仕組み）に対して意図しない書き込みができてしまう、という問題です。

ざっくり言うと、次のようなイメージです。

本来:
読み取り専用のファイル
  → 読むだけ

Copy Fail:
読み取り専用のファイル
  → メモリ上のキャッシュだけ一部書き換えられる

ここで重要なのは、ディスク上のファイル自体は変わらない場合がある という点です。

ページキャッシュとは

Linuxは、ファイルを読むたびに毎回ディスクへアクセスすると遅いため、一度読んだファイル内容をメモリに保存します。

これが ページキャッシュ（ディスク上のファイル内容をメモリに一時保存して、読み書きを速くする仕組み） です。

ディスク上のファイル
  ↓ 読み込み
メモリ上のページキャッシュ
  ↓
アプリやコマンドが利用

Copy Failでは、このページキャッシュに対して、一般ユーザーが制御された書き込みを行える可能性があります。

そのため、ディスク上のファイルをチェックしても改ざんが見えにくい場合があります。

なぜroot権限につながるのか

Linuxには setuid（一般ユーザーが実行しても、一時的に別ユーザーの権限で動ける仕組み）という仕組みがあります。

setuid が付いたプログラムは、一般ユーザーが実行しても、一時的に所有者の権限で動きます。

代表例は次のようなコマンドです。

/usr/bin/su
/usr/bin/passwd

これらはroot権限が必要な処理を行うため、特別な権限を持っています。

Copy Failでは、このようなsetuidバイナリ（setuidが付いた特別なプログラム）のページキャッシュを改ざんすることで、実行時の挙動を変え、root権限を取得できる可能性があります。

怖いポイントはここです。

ディスク上の /usr/bin/su は変わっていない
でも、メモリ上で読み込まれる内容が変わる
その結果、root権限につながる

通常のファイルハッシュ監視だけでは見逃す可能性がある、というのが厄介です。

この脆弱性で実際に何が起きるのか

Copy Failの怖さは、「Linuxにログインできる一般ユーザー」が、条件次第でroot権限を取得できる点です。

つまり、最初からインターネット越しにrootを取られる脆弱性ではありません。

しかし、次のような入口と組み合わさると危険です。

  • Webアプリの脆弱性で任意コード実行される
  • SSH鍵が漏れて一般ユーザーでログインされる
  • CI/CDランナーで外部由来のコードが実行される
  • コンテナ内で攻撃者のコードが動く

この時点では、攻撃者はまだ一般ユーザー権限かもしれません。

しかしCopy Failを悪用されると、ページキャッシュ上のsetuidバイナリが一時的に書き換えられ、root権限のシェルを取得される可能性があります。

流れとしては次のようなイメージです。

一般ユーザーとしてコード実行
  ↓
Copy Failを悪用
  ↓
メモリ上のsetuidバイナリの見え方を変える
  ↓
setuidバイナリを実行
  ↓
root権限を取得

ここで厄介なのは、ディスク上のファイルそのものが書き換わらない場合があることです。

たとえば /usr/bin/su のようなファイルが悪用されたとしても、ディスク上の /usr/bin/su 自体は変更されていないように見える可能性があります。

そのため、単純なファイルハッシュ監視だけでは検知しにくい場合があります。

起こり得るリスク

Copy Failが悪用されると、次のようなリスクにつながります。

リスク 何が起きるか
root権限の取得 一般ユーザーが管理者権限を得る
サーバー全体の掌握 設定変更、ログ削除、サービス停止などが可能になる
認証情報の窃取 SSH鍵、APIキー、トークン、DB接続情報などを読まれる
CI/CD環境の侵害 ビルドサーバー上の秘密情報やデプロイ権限を奪われる
コンテナホストへの影響 コンテナ内のコード実行からホスト側へ影響が広がる可能性がある
検知の遅れ ディスク上のファイル改ざんとして見えにくい

特に危険なのは、CI/CDランナーやコンテナ環境です。

これらの環境では、外部由来のコードや開発者が書いたコードを自動実行することがあります。

通常であれば「一般ユーザー権限で動いているから大丈夫」と考えがちですが、ローカル権限昇格の脆弱性があると、その前提が崩れます。

外部コードを実行
  ↓
一般ユーザー権限だから安全、のはず
  ↓
ローカル権限昇格
  ↓
root権限でホストを操作される

つまりCopy Failは、単体で見るとローカル脆弱性ですが、実務上は「侵入後にrootを取るための武器」として危険です。

だからこそ、インターネット公開サーバーだけでなく、CI/CDランナー、Dockerホスト、Kubernetesノード、共用Linuxサーバーも優先的に確認する必要があります。

過去の類似事例

Copy Failは、過去のLinuxカーネル脆弱性である Dirty COW や Dirty Pipe と比較すると理解しやすいです。

脆弱性 CVE ざっくり内容 共通点
Dirty COW CVE-2016-5195 copy-on-write処理（変更時にコピーする仕組み）の競合状態により、読み取り専用メモリへ書き込み可能になる ローカル権限昇格
Dirty Pipe CVE-2022-0847 pipe処理（プロセス間でデータを受け渡す仕組み）の不備により、読み取り専用ファイルのページキャッシュを書き換えられる ページキャッシュ悪用
Copy Fail CVE-2026-31431 AF_ALG、algif_aead、authencesn、splice() 周辺の処理不備により、ページキャッシュへ制御された書き込みが可能になる ページキャッシュ悪用、root権限昇格

Dirty COW（Linuxカーネルの有名な権限昇格脆弱性）は、読み取り専用のメモリマッピングに書き込み可能になる問題でした。

Dirty Pipe（ページキャッシュに関係するLinuxカーネルの有名な脆弱性）は、読み取り専用ファイルに紐づくページキャッシュへ書き込み可能になる問題でした。

Copy Failも、「本来書き換えられないはずのものを書き換えられる」という意味で、これらに近いタイプの脆弱性です。

特にDirty Pipeとは、ページキャッシュが関係する点で似ています。

ただし、Copy Failはページキャッシュ上の改ざんがディスク上のファイル変更として見えにくい点が特徴です。

海外の見解

海外のセキュリティ記事やアドバイザリ（注意喚起・技術情報）では、Copy Failは危険なローカル権限昇格として扱われています。

特に強調されているのは次の点です。

  • PoCが公開されている
  • exploit（脆弱性を悪用する攻撃コード）が短く、再現性が高いとされている
  • 2017年以降のカーネルを含む主要Linuxディストリビューションの多くに影響する可能性がある
  • コンテナやCI/CD環境でも問題になる可能性がある
  • ファイル改ざん検知（ファイルが変更されていないか確認する仕組み）だけでは見逃す可能性がある

Theori / Xint（Copy Failの詳細を公開した海外のセキュリティ研究チーム）は、Copy Failについて「主要なLinuxディストリビューションでroot取得につながる」と説明しています。

CERT-EUも、高リスクなローカル権限昇格として注意喚起しています。

また、Sysdig（クラウド・コンテナセキュリティ企業）は AF_ALG ソケット（プログラムがカーネル暗号機能と通信するための窓口）と splice()（データを効率よく別の場所へ渡すLinuxの仕組み）の組み合わせによって、ページキャッシュへの意図しない書き込みが起こる点を解説しています。

Belgium CCB（ベルギーのサイバーセキュリティ当局）は、ディスク上に痕跡を残さないため、標準的なファイル整合性チェックでは検知しにくいと注意喚起しています。

どんな環境が危ないか

特に注意したいのは、次のような環境です。

  • CI/CDランナー
  • Kubernetesノード（コンテナを動かすためのクラスタ内サーバー）
  • Dockerホスト（Dockerコンテナを動かしている親側のLinux）
  • VPS（仮想専用サーバー）
  • 複数人がSSHログインするLinuxサーバー
  • CTFや検証用に外部コードを動かす環境
  • 開発者が自由にコマンドを実行できる共用サーバー

ローカル権限昇格は、単体では外部から直接攻撃されるものではありません。

しかし、次のような流れで悪用される可能性があります。

Webアプリの脆弱性で侵入
  ↓
一般ユーザー権限でコード実行
  ↓
Copy Failを悪用
  ↓
root権限を取得
  ↓
サーバー全体を掌握

特にCI/CDランナーやコンテナホストは、信頼できないコードが動く可能性があります。

コンテナ環境でも、共有カーネル・共有ページキャッシュの性質上、脅威モデルに入る可能性があります。特に、信頼できないコードを実行するCI/CDランナーやKubernetesノードでは優先的に対策すべきです。

ただし、コンテナ環境での影響は構成や権限設定によって変わります。
「コンテナだから必ず安全」「コンテナなら必ずホストを取られる」と単純には言えません。
共有カーネルを使う環境では、ホスト側カーネルの更新や緩和策を優先的に確認するのが安全です。

影響範囲はどう考えるべきか

Copy Failは、2017年以降のカーネルを含む主要Linuxディストリビューションの多くに影響する可能性があります。

ただし、実際に影響を受けるかどうかは、ディストリビューション（Ubuntu、Debian、Red Hatなど）、カーネルバージョン、バックポート状況（新しい修正だけを古いバージョン向けに取り込んでいるか）によって変わります。

そのため、「Ubuntuだから危ない」「Debianだから安全」と単純には判断できません。

たとえばDebianでも、リリース系列によって状態が異なります。Debian Security Tracker（Debianの脆弱性対応状況を確認できる公式情報）で自分のリリースを確認する必要があります。

最終的には、次のような公式情報を見るのが安全です。

  • Ubuntu Security
  • Debian Security Tracker
  • Red Hat CVE Database
  • Amazon Linux Security Center
  • SUSE Security
  • 利用しているVPS・クラウド事業者の注意喚起

対策1: カーネルをアップデートする

最優先は、各Linuxディストリビューションが提供する修正済みカーネル（脆弱性対応が入ったLinuxカーネル）へ更新することです。

現在のカーネルは次のコマンドで確認できます。

uname -r

OS情報は次のコマンドで確認できます。

cat /etc/os-release

Ubuntu、Debian、Red Hat、Amazon Linux、SUSEなど、自分が使っているディストリビューションの公式セキュリティ情報を確認します。

カーネル更新後は、基本的に再起動が必要です。

sudo reboot

なお、Ubuntuなど一部ディストリビューションでは、修正済みカーネルの配布前に kmod 更新による algif_aead 無効化の緩和策が提供されています。単に uname -r だけを見るのではなく、各ディストリビューションのセキュリティ情報で「カーネル修正」なのか「一時的な緩和策」なのかを確認する必要があります。

Ubuntuの場合は、通常の更新として次のように適用できます。

sudo apt update
sudo apt upgrade

対策2: すぐ更新できない場合は algif_aead を無効化する

すぐにカーネル更新できない場合、一時的な緩和策（根本修正ではないが、攻撃されにくくするための暫定対応）として algif_aead モジュール（Linuxカーネルに後から読み込まれる暗号処理部品）を無効化する方法があります。

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo rmmod algif_aead 2>/dev/null || true

ただし、これは暗号処理まわりに影響する可能性があります。

本番環境では、適用前に影響確認をした方がよいです。

また、環境によっては緩和策だけでは不十分な場合もあり得ます。最終的には、修正済みカーネルへの更新を優先すべきです。

対策3: setuidバイナリ（setuidが付いた特別なプログラム）を棚卸しする

Copy Failでは、setuidバイナリの悪用が重要な攻撃経路になります。

setuidバイナリは次のコマンドで確認できます。

find / -perm -4000 -type f 2>/dev/null

不要なsetuidバイナリがないか確認します。

特に、古いツール、検証用に入れたコマンド、使っていない管理用バイナリは見直した方がよいです。

対策4: CI/CDやコンテナ環境を優先的に見る

個人的に最優先で確認したいのは、CI/CDランナーやコンテナホストです。

理由は、信頼できないコードが動く可能性があるからです。

たとえば、次のような環境は注意が必要です。

  • GitHub Actionsのセルフホストランナー（自分で用意したサーバー上でGitHub Actionsを動かす仕組み）
  • GitLab Runner（GitLab CI/CDのジョブを実行するサーバー・プロセス）
  • Jenkinsエージェント（Jenkinsのビルドやテストを実行するサーバー・プロセス）
  • Kubernetesノード
  • Dockerホスト

攻撃の流れとしては、次のような形が考えられます。

外部・開発者のコードが動く
  ↓
Linux上で一般ユーザー権限を得る
  ↓
ローカル権限昇格
  ↓
ホスト側に影響

このような環境では、次の対策も検討した方がよさそうです。

  • ランナーを使い捨てにする
  • ジョブごとにVMを破棄する
  • 権限を最小化する（必要最低限の権限だけを与える）
  • ホスト上に重要な認証情報（SSH鍵、APIキー、トークン、パスワードなど）を置かない
  • コンテナホストのカーネル更新を優先する

対策5: ファイルハッシュ監視だけに頼らない

Copy Failは、ディスク上のファイルそのものではなく、ページキャッシュを悪用する点が厄介です。

そのため、単純にファイルのハッシュだけを見ていても、異常に気づけない可能性があります。

もちろんファイル改ざん検知は重要です。

ただし、それだけではなく、次のような観点も必要になります。

  • カーネル更新状況の管理
  • 不審な権限昇格（通常より強い権限を得ようとする怪しい動き）の監視
  • setuidバイナリの棚卸し
  • CI/CDランナーの隔離
  • コンテナホストの更新
  • 不要なローカルユーザーの削除

PoCを自分の端末で試してよいのか

Copy Failのような脆弱性を見ると、「自分のKali Linux（セキュリティ学習・診断向けのLinuxディストリビューション）でも本当にrootが取れるのか試してみたい」と思う人もいるはずです。

ただし、普段使いの端末でPoCを実行するのはおすすめしません。

理由は、検証そのものが root権限を取る攻撃 だからです。

Copy Failでは、ページキャッシュ上のsetuidバイナリを一時的に改ざんし、root権限取得につなげる手法が説明されています。つまり、単なる「バージョン確認」ではなく、OSの重要な仕組みに実際に干渉する検証になります。

普段使いの環境で避けた方がよい理由は次のとおりです。

  • システムが不安定になる可能性がある
  • su、sudo、ログイン、パッケージ管理などに影響する可能性がある
  • PoCの副作用（検証コードを動かした結果として起きる予期しない影響）が読みづらい
  • ページキャッシュ改ざんのため、何が変わって何が戻ったのか判断しにくい
  • PoC入手元によっては、別の悪意あるコードが混ざっている可能性がある
  • SSH鍵、GitHubトークン（GitHub APIやGit操作に使う認証情報）、ブラウザ情報、共有フォルダなどをPoCに読まれるリスクがある

私が勉強用で使用しているKali Linuxでは、CTFや検証用途で使っていても、普段使いしているとSSH鍵、Git認証情報、メモ、ブラウザログイン情報などが入っていることがあります。

PoCが悪意あるコードだった場合、root権限でそれらを読まれる可能性があります。

そのため、記事や学習目的で確認するなら、まずは 非破壊の確認 に留めるのが安全です。

# カーネル確認
uname -r

# OS確認
cat /etc/os-release

# 更新候補の確認
sudo apt update
apt list --upgradable | grep -E 'linux-image|linux-headers|linux-libc-dev|kmod'

# algif_aead モジュールの存在確認
modinfo algif_aead 2>/dev/null | head

ここまでなら、脆弱性を悪用するわけではありません。

どうしてもPoCを試す場合は、次の条件を満たした使い捨て環境に限定した方がよいです。

  • VM（仮想マシン）で実行する
  • 実行前にスナップショット（VMの状態を保存して、後から戻せる機能）を取る
  • ホストOSの共有フォルダを切る
  • SSH鍵やトークンを置かない
  • 会社ネットワークや本番環境から分離する
  • 検証後はVMを破棄する

自分の端末で「本当に脆弱か」を確認したい場合でも、PoCでroot取得を試すより、まずは次の判断で十分です。

  • 使っているカーネルバージョン
  • ディストリビューションの修正状況
  • 修正済みlinux-imageへ更新済みか
  • 再起動して新しいカーネルで起動しているか
  • algif_aead の一時無効化が必要か

脆弱性検証では、「動いたら面白い」よりも、「壊してよい環境か」を先に考えるのが大事です。

自分の環境でまず確認すること

最低限、次の順番で確認するとよさそうです。

# カーネル確認
uname -r

# OS確認
cat /etc/os-release

# setuidバイナリ確認
find / -perm -4000 -type f 2>/dev/null

# algif_aead が読み込まれているか確認
lsmod | grep algif_aead

# algif_aead モジュール情報の確認
modinfo algif_aead 2>/dev/null | head

そのうえで、使っているディストリビューションの公式セキュリティ情報を確認します。

まとめ

Copy Fail（CVE-2026-31431）は、Linuxカーネルの AF_ALG、algif_aead、authencesn、splice() まわりにあるローカル権限昇格脆弱性です。

リモートから直接攻撃されるタイプではありませんが、一般ユーザー権限を取られた後にroot権限へ昇格される可能性があります。

特に注意したいポイントは次のとおりです。

  • PoCが公開されている
  • root権限取得につながる
  • ページキャッシュを悪用する
  • ディスク上のファイルが変わらない場合がある
  • CI/CDやコンテナ環境で影響が大きい
  • Dirty PipeやDirty COWと同じく、Linuxカーネル系の重要な権限昇格脆弱性として扱うべき
  • PoC検証は普段使い環境ではなく、使い捨てVMで行うべき

まずはカーネル更新を確認し、すぐに更新できない場合は一時的な緩和策を検討するのがよさそうです。

参考

Discussion