非特権ユーザーがrootに昇格できてしまう脆弱性「Copy Fail」の対策を急ごう

2026年4月29日、Linuxカーネルの暗号サブシステムに存在する深刻なローカル権限昇格(LPE)の脆弱性「Copy Fail (CVE-2026-31431)」が公開されました。

日本はゴールデンウィークのさなかに発見された脆弱性なだけあって、各所でいろいろバタついていそうですね・・・

本脆弱性は2017年以降にリリースされたほぼすべての主要Linuxディストリビューションが影響を受け、わずか732バイトのPythonスクリプトで一般ユーザーからroot権限を取得できてしまうという、極めて重大な脆弱性です。

本記事では、情シス目線で「自社環境はどれくらい危ないのか」「今すぐ何をすべきか」を整理します。検証用にWSL2とProxmox上のVMでPoC実行と緩和策の効果を確認していますので、その結果も含めてまとめています。

本記事の目的について

本記事は、IT管理者の皆様がCVE-2026-31431の影響評価とパッチ適用の判断を行うための情報提供を目的としており、攻撃手法の助長を意図するものではありません。

PoC（攻撃コード）そのものの掲載は避け、検出ツールの実行結果や緩和策の有効性検証にとどめています。検証は必ずご自身が管理する環境でのみ行ってください。

3行サマリ
脆弱性について
対策の優先順位
- 対策済みカーネルパッチの適用
- 緩和策の実行
WSL2環境での注意点
- WSL2での対応策
- WSL2環境のリスク評価
検出と監視
まとめ

3行サマリ

何が起きる？: 一般ユーザーが100%確実にroot権限を取得できる(ディストリ別チューニング不要)

影響範囲: 2017年以降のほぼすべての主要Linuxディストリ(Debian、Ubuntu、RHEL、Amazon Linux、SUSE Linux等)

やるべきこと: カーネルパッチを適用、難しければalgif_aeadモジュールを無効化(ただしWSL2では別対応が必要)

脆弱性について

Copy Failの概要

Copy Fail (CVE-2026-31431)は、Linuxカーネルの暗号テンプレートauthencesn(hmac(sha256),cbc(aes))に存在するロジックバグです。

発見したのは韓国のセキュリティベンダーTheoriのXint Codeチームで、AI支援型のセキュリティ監査ツールがcrypto/サブシステム全体を約1時間スキャンしただけで発見されたという経緯も話題になっています。
技術的には、以下の3つの仕組みの組み合わせで成立する脆弱性です。

AF_ALG: ユーザースペースからカーネルの暗号機能を使うためのソケットインターフェース(非特権ユーザーから利用可能)
splice(): ファイルディスクリプタ間でデータをコピーせずに転送するシステムコール(ページキャッシュへの参照が渡される)
authencesn: IPsecの拡張シーケンス番号(ESN)サポートのためのAEADアルゴリズム

これらを組み合わせることで、攻撃者は「任意の読み取り可能なファイルのページキャッシュに、4バイトの任意のデータを書き込む」という強力な攻撃の足掛かりを得ることができます。

なぜrootが取れるのか

カーネルはバイナリを実行する際、ディスクから直接読むのではなくページキャッシュから読み込みます。つまり、/usr/bin/suのようなsetuidバイナリのページキャッシュを書き換えてしまえば、ディスク上のファイルは無傷のまま、メモリ上だけで実行ファイルを改竄できてしまいます。
公開されているPoCは732バイトのPythonスクリプトで、/usr/bin/suをターゲットに4バイトずつ書き込みを繰り返してペイロードを埋め込み、最後にsuを実行することでroot shellを取得します。

なぜ深刻なのか

過去のLinux権限昇格バグの多くは、実戦投入には相応の手間がかかりました。

Copy Failはそれらと違い、Debianでも、Ubuntuでも、RHELでも、Amazon Linuxでも、SUSEでも、ディストリ毎やカーネルバージョン毎に特別なカスタマイズする必要がないことと、下記理由により検出が困難なんです。

ディスクは改竄されない: ページキャッシュ上だけでバイナリが書き換えられるため、AIDEやTripwire等のディスクベースのファイル整合性監視では検出不可
ファイルシステムイベントが発火しない: inotify等の監視も回避
再起動またはページキャッシュのクリアで「証拠」が消える: フォレンジック的にも厄介

影響が限定的と考えられる環境

Copy Failは「同じLinuxカーネルを共有していること」が攻撃の前提です。

そのため、以下のようなカーネル自体が分離されている環境は、アーキテクチャ上Copy Failの直接的な影響を受けにくいと考えられます。ただし、各ベンダーからの公式アドバイザリは別途確認してください。

AWS Lambda / Fargate: 関数やコンテナごとに専用の軽量VM (Firecracker)が割り当てられ、テナント間でカーネルもページキャッシュも共有されないため。
Cloudflare Workers: Linuxカーネルではなく、ブラウザと同じJavaScriptエンジン (V8) のサンドボックス上で動作するため。
gVisor環境のコンテナ: ホストカーネルとアプリの間に「ユーザー空間で動く疑似カーネル」が挟まり、本物のホストカーネルへのシステムコールは大幅に制限されるため。
macOS / Windows: そもそもLinuxカーネルではありません(WSL2は除く)

自社環境のリスク評価

極めて重大

共有レンタルサーバ: 1テナントが全サーバを乗っ取り、全顧客データにアクセス可能
Kubernetes / コンテナ基盤(ホストカーネル共有): 1つのコンテナエスケープがノード全体の侵害につながる。ページキャッシュはPod間で共有されるため横展開リスクが高い
セルフホスト型CIランナー: GitHub Actions / GitLab Runnerで信頼できないPRコードを実行している場合、即座にrootを取られる
共有レンタルサーバ: 1テナントが全サーバを乗っ取り、全顧客データにアクセス可能

重大

Webサーバ + アプリ層の脆弱性: WordPressプラグインのRCEなどでwww-data等の非特権シェルを取られた瞬間、Copy Failでroot化される
複数ユーザーがSSHログインする踏み台サーバ: 内部不正のリスク

中程度

専用サーバで管理者のみがログインする環境

低

上記の「影響を受けない環境」に該当するもの
ローカルアクセスする経路が一切存在しないアプライアンス

対策の優先順位

対策済みカーネルパッチの適用

mainline commit a664bf3d603dが適用された対策済みカーネルパッチの適用が一番の対策です。

ただ、カーネルパッチの公開は各ディストリによって時期感が分かれるので、各ディストリのCVEトラッカーを確認してください。

Debian：https://security-tracker.debian.org/tracker/CVE-2026-31431
Ubuntu：https://ubuntu.com/security/CVE-2026-31431
Red Hat：https://access.redhat.com/security/cve/cve-2026-31431

緩和策の実行

対策済みカーネルパッチがリリースされるまでの間は、下記緩和策を実行することで攻撃コードが実行されないようになります。

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

lsmod | grep algif_aead   # 何も返らなければOK
cat /etc/modprobe.d/disable-algif.conf

緩和策実行への影響

一般的な業務システムへの影響はほぼゼロです。

AF_ALGはユーザースペースからカーネル暗号機能を使うためのインターフェースですが、現実にはほとんどのソフトウェアがユーザースペースの暗号ライブラリ(OpenSSL、GnuTLS等)を使っており、AF_ALG経由で暗号処理を呼び出すアプリケーションは稀です。

影響を受ける可能性があるケース

組み込み機器でハードウェア暗号オフロード(IMX6 CAAM等)をAF_ALG経由で使う構成
libkcapiを直接呼び出すカスタムアプリケーション
AF_ALG AEADを明示的に有効化したOpenSSLビルド

緩和策適用前に、現在AF_ALGを使っているプロセスがないかを確認しておくと安心です。

# AF_ALGソケットの利用状況
# 何も返ってこなければ、緩和策適用による影響はありません
sudo ss -xa | grep -i alg
sudo lsof 2>/dev/null | grep -i alg

WSL2環境での注意点

ここから先は、WSL2を開発・検証環境として使っている方向けの追加情報です。

筆者の手元のWSL2環境(Ubuntu)で本記事の緩和策を適用したところ、algif_aeadの無効化を実施してもPoCが引き続き動作することを確認しました。

syobon@saori:~$ id
uid=1000(syobon) gid=1000(syobon) groups=1000(syobon),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),1001(docker)
syobon@saori:~$ uname -r
6.6.87.2-microsoft-standard-WSL2
syobon@saori:~$ ＜PoC実行＞
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0   9210      0 --:--:-- --:--:-- --:--:--  9253
# id
uid=0(root) gid=1000(syobon) groups=1000(syobon),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),1001(docker)

#緩和策実行
root@saori:~# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
root@saori:~# rmmod algif_aead 2>/dev/null || true
root@saori:~# lsmod | grep algif_aead

root@saori:~# cat /etc/modprobe.d/disable-algif.conf
install algif_aead /bin/false
root@saori:~# exit
logout

#PoCの再実行
syobon@saori:~$ ＜PoC実行＞
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0  10975      0 --:--:-- --:--:-- --:--:-- 11075

#PoC再実行できちゃった・・・

# id
uid=0(root) gid=1000(syobon) groups=1000(syobon),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),1001(docker)

これは、WSL2のLinuxカーネルはMicrosoftが配布する独自ビルドで、暗号関連機能を含む多くのドライバがローダブルモジュールではなくカーネル本体に静的リンクされていることに起因しています。

通常のディストリではalgif_aeadは.koファイルとして存在 → modprobe blacklistで無効化という流れで緩和を実現できます。

しかし、WSL2ではalgif_aeadはカーネル本体に組み込み済み → modprobe設定は無視される、rmmodも「Module algif_aead is not currently loaded」で失敗してしまいます。そのため、本緩和策では緊急対策ができません。

WSL2での対応策

WSL2での緩和策についてはいくつか案があるので、各組織に応じた緩和策を検討してみてください。

Microsoftからの対策パッチリリースを待つ
- パッチがリリースされれば「wsl –update」でアップデート実施
- ただし、記事公開時点ではまだリリースされていない様子
パッチ済みカスタムカーネルをビルドして使う
- WSL2-Linux-Kernelからソースを取得
- mainline commit a664bf3d603d相当の修正をcherry-pick
- ビルドして.wslconfigのkernel=で指定
WSL2を一時停止する
- 業務的に影響なければ下記コマンドでWSL2を一時停止する
- wsl –shutdown

WSL2環境のリスク評価

開発者個人のWSL2環境であれば、外部からのリモート攻撃経路がない限りリスクは限定的です。

ただし、以下のようなシナリオでは要注意です。

チーム共有の開発サーバ上のWSL2環境: 内部不正のリスク
信頼できないコードをWSL2上で実行する場合: マルウェア解析、サードパーティ製ビルドスクリプト等
WSL2内に機密情報を保管している場合: APIキー、社内コード等がroot権限で抜かれる可能性

検出と監視

GitHubで公開されている検出ツールtest_cve_2026_31431.pyを使用すると、自環境が脆弱かどうかを安全に確認できます。

このスクリプトはrootへの権限昇格は実施せず、脆弱性の影響があるかどうかをチェックできます。

GitHub – rootsecdev/cve_2026_31431: Exploit POC for CVE_2026_31431 · GitHub

Exploit POC for CVE_2026_31431. Contribute to rootsecdev/cve_2026_31431 developm…

github.com

# 1. Detect
python3 test_cve_2026_31431.py
#   exit 0 = not vulnerable, 2 = vulnerable, 1 = test error

まとめ

取り急ぎまとめてみましたが、ゴールデンウィークの最中、とんでもない話が転がり込んできましたね・・・

まずはリスクが高い環境で取り急ぎ緩和策の実施やカーネルパッチの適用を検討してください。