Linuxカーネル脆弱性「Copy Fail」（CVE-2026-31431）のまとめ：AWS EC2・ECS環境での緩和策

この記事で学べること

この記事は、Linuxカーネルの論理欠陥がAWSのマネージドサービスやEC2でどう影響するかを、共有責任モデルの観点から整理したリファレンスです。次の3点を持ち帰れるように構成しています。

CVE-2026-31431 Copy Fail の技術的本質: カーネル暗号APIの論理欠陥がどうやってroot権限奪取につながるのか、ロジックの流れを最小限で押さえる
共有責任モデル下でユーザが対応すべき範囲：EC2 / ECS（EC2起動）/ Fargate / Lambda などサービスごとに「誰がパッチを当てるのか」を切り分ける
緩和策の使い分け：モジュール無効化・seccompでのソケット遮断・アカウント棚卸しを、環境特性に応じてどう選ぶか

特定の環境での適用結果を断定する記事ではなく、AWS利用者が自分の環境に当てはめて判断するための材料を提供することを目的としています。

何が起きたのか

2026年4月22日、Linuxカーネルの暗号化API（algif_aead）に存在する論理欠陥が CVE-2026-31431 として公表されました。研究者は専用サイト copy.fail でこの脆弱性を「Copy Fail」と命名し、PoCコードと技術解説を同時公開しています。

特徴を一言でまとめると、次の通りです。

一般ユーザ権限で 任意のsetuidバイナリを書き換え可能 な、ローカル権限昇格の脆弱性
PoCはわずか 732バイトのPythonスクリプト、信頼性は「100%」と主張されている
レース条件もカーネルオフセットも不要な「直線的な論理フロー」の欠陥
欠陥は約9年前から潜伏しており、2017年以降のほぼすべてのLinuxディストリビューションが影響を受ける

そして本題、AWSのAmazon Linux 2 / Amazon Linux 2023も例外ではありません。今日（2026年4月30日）時点で、AWSの脆弱性データベース ALAS ではすべてのカーネルパッケージが「Pending Fix」の状態で、修正版はまだ提供されていません。

EC2上で動くワークロードはもちろん、内部的にEC2を使うECS（EC2起動タイプ）やEKSのワーカーノードも影響を受けるため、AWS利用者であれば一度は把握しておきたい脆弱性です。

CVE-2026-31431 の基本情報

ALASに掲載されている基本情報は以下の通りです。

項目	内容
CVE ID	CVE-2026-31431
通称	Copy Fail
公開日	2026-04-22
深刻度	Important
CVSSv3 基本スコア	7.8
CVSSv3 ベクトル	`AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
影響を受けるサブシステム	Linuxカーネルの `crypto: algif_aead`
修正コミット	`a664bf3d603d`（"Revert to operating out-of-place"）

CVSSベクトル AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H は、ローカルアクセスと低い権限さえあれば成立し、機密性・完全性・可用性すべてに高い影響を与えるカーネル脆弱性であることを示しています（詳細なベクトルの読み解きはALASを参照）。

リモートから単独で悪用できる脆弱性ではないものの、初期侵入後の権限昇格に使われる典型的なパターンであり、マルチテナント環境やSSHが許可されているEC2では特に危険です。

攻撃の仕組み（ロジックフロー）

技術的な根本原因は、ひとことで言えば「カーネル暗号APIの論理欠陥を足がかりにした、ごく小さなメモリ書き込み」です。攻撃の流れだけを最小限の図で押さえると次のようになります。

カーネル暗号APIの論理欠陥（authencesn）
        │
        ▼
ページキャッシュへ任意の4バイト書き込み
        │
        ▼
setuidバイナリの命令列を改変
        │
        ▼
ルート権限でのコード実行（ローカル権限昇格）

authencesn の論理バグを AF_ALG ソケットと splice() でどう連結して4バイト書き込みに至るのかという内部の詳細は、研究者自身の解説（copy.fail）が最も正確です。AWS利用者として押さえるべきポイントは、「たった4バイトの書き込みでも、setuidバイナリの命令列を狙い撃ちすれば権限昇格が成立する」という点に尽きます。

なお、再起動すれば書き換えられたページキャッシュ自体はリセットされますが、攻撃中にroot権限で永続化処理を仕込まれていれば再起動では取り戻せません。検知と再構築の判断が必要になります。

AWSでの影響範囲

Amazon Linux のステータス（2026-04-30 時点）

ALASによると、影響を受けるリポジトリは以下の通りです。すべて Pending Fix で、修正版はまだ未提供です。

Amazon Linux 2: Core, Kernel-5.4 Extra, Kernel-5.10 Extra, Kernel-5.15 Extra
Amazon Linux 2023: 標準カーネル, kernel6.12, kernel6.18

影響を受けるAWSサービス

サービス	影響	備考
EC2（AL2 / AL2023）	あり	カーネル更新が必要
ECS（EC2起動タイプ）	あり	コンテナホスト＝EC2なので同じ脆弱性を持つ
ECS（Fargate起動タイプ）	AWS側で対応	利用者側のパッチ作業は不要だが、AWSの対応完了を待つ
EKS（マネージドノード）	あり	ノードのAMI更新が必要
Lambda	AWS側で対応	ランタイムOSはAWSが管理
RDS / Aurora	AWS側で対応	マネージドサービスのためAWSが対処

自分でOSを管理しているEC2系のサービスは、自分でパッチを当てる必要がある という点が今回のポイントです。Fargate / Lambda / RDS のようなマネージドサービスは基本的にAWS側で順次対応されますが、利用者がOS管理権限を持つEC2 / ECS（EC2）/ EKSノードについては、ユーザ側でアクションが必要です。

コンテナ環境での注意点

「ECSやEKSのコンテナはホストから隔離されているから大丈夫では？」と思いがちですが、カーネルはホストと共有 です。コンテナ内の低権限ユーザがCopy Failを発動できれば、カーネル空間で4バイト書き込みが成立し、結果としてホスト側のsetuidバイナリ改変につながります。

特に以下のような構成は注意が必要です。

マルチテナントで他社のコンテナと同居するEC2ノード
コンテナ内でビルド処理を回すCI/CDワーカー（信頼できないコードを動かす可能性がある）
エンドユーザがコードを実行できるサンドボックス環境

確認手順と、実際にやった対応

このブログ自体は静的エクスポート構成（現在はCloudflare Pagesでホスティング。以前はS3 + CloudFront）で運用しており、ブログのインフラとしてはEC2を使っていないため直接影響はありません。

ただ、業務で運用しているEC2環境では、本脆弱性への対応を実際に入れました。やったことは基本に忠実で、カーネルを修正版へアップデートして再起動する、というものです。再起動を伴うため事前にメンテナンス枠を取りましたが、適用そのものは問題なく完了し、特段のトラブルは起きませんでした（業務環境の構成・規模などの詳細は伏せます）。

以下では、その確認・対応の流れを汎用化して整理します。下に挙げる AF_ALG 無効化やseccompは、アップデートをすぐに当てられない場合の追加の緩和オプションで、こちらは実環境では適用していません。実行する場合は、必ず検証環境で副作用を確認してから本番に適用してください。

Step 1: 動いているEC2をリストアップ

# 起動中のEC2を一覧（AL2 / AL2023 を識別）
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].[InstanceId,Platform,Tags[?Key==`Name`].Value|[0],ImageId]' \
  --output table

Step 2: カーネルバージョンの確認

SSM Run Commandを使えば、各インスタンスにSSHすることなく一括でカーネルバージョンを確認できます。SSHレスで多数のEC2を横断確認できるのが利点です。

aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Environment,Values=production" \
  --parameters 'commands=["uname -r","cat /etc/os-release | grep PRETTY_NAME"]'

Step 3: 緩和策の適用状態を確認

後述の algif_aead 無効化が入っているか確認します。

lsmod | grep algif
ls /etc/modprobe.d/ | grep algif

EC2を直接運用しているケース以外にも、ECRイメージのビルドに使うCodeBuildや踏み台用EC2など、見落としがちなインスタンスがないか棚卸ししておくと、パッチ運用フローの抜け漏れ防止につながります。

パッチ提供前にできる緩和策

AWSからの修正版カーネルが出るまでの間、すぐに実施できる緩和策を3つ紹介します。

緩和策 1: `algif_aead` モジュールの無効化（推奨）

研究者自身が推奨している最もシンプルな方法です。algif_aead カーネルモジュールのロードを禁止することで、攻撃のトリガーとなる AF_ALG 経由のAEAD暗号化操作を遮断します。次の手順で、SSM Run Command経由でタグ付けされたEC2へ一括適用できます（適用前に副作用を必ず確認してください）。

# タグで対象を絞ってSSM Run Commandで適用する例
aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Environment,Values=production" \
  --parameters 'commands=[
    "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 || echo OK: algif_aead is unloaded"
  ]'

副作用について

以下は実環境での検証結果ではなく、無効化を検討する際に確認すべき一般的な指針です。公式解説では「ほとんどのシステムで機能低下なし」とされていますが、AF_ALG を明示的に使うアプリケーションは影響を受け得ます。具体的には、

カーネルcryptoをユーザ空間から呼び出すVPN実装の一部
cryptsetup の特定オプションを使ったディスク暗号化
一部のIPSec実装

を使っている場合は、無効化前に検証環境で動作確認することをおすすめします。一般的なWebアプリケーションサーバやアプリケーションホストであれば影響は出にくいとされていますが、自環境での確認は省略しないでください。

緩和策 2: seccompで `AF_ALG` ソケット作成をブロック

信頼できないコードを実行するコンテナ環境では、seccompプロファイルで AF_ALG ソケットの作成自体をブロックする方法が有効です。

ECSタスク定義であれば linuxParameters.systemControls ではなくDockerのセキュリティオプション経由で渡すか、カスタムseccompプロファイルを s3 に置いて読み込ませる構成になります。EKSであればPodSecurityPolicyの後継である Pod Security Standards の restricted プロファイルを基本適用としつつ、カスタムseccompを当てます。

サンプルseccompプロファイル（AF_ALGをブロック）：

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        { "index": 0, "value": 38, "op": "SCMP_CMP_EQ" }
      ]
    }
  ]
}

38 は AF_ALG のドメイン番号です。コンテナから socket(AF_ALG, ...) が呼ばれた瞬間にエラーで弾けます。

緩和策 3: 不要な低権限アカウントの棚卸し

Copy Failはローカル権限昇格の脆弱性のため、そもそも一般ユーザがログインできない環境では悪用されません。これを機に以下を見直すと安全度が一段上がります。

退職者・異動者のSSHキーが残っていないか
IAMロール経由のSSM Session Managerに統一できないか（SSHキー管理を廃止）
利用していない開発用EC2は停止・削除

パッチ提供後の対応

AWSから修正版カーネルが提供されたら、以下の流れで適用します。Pending Fix状態のうちは、ALAS RSSやyum check-updateを定期チェックする運用にしておくのがおすすめです。

Amazon Linux 2 / 2023 共通

# パッケージ更新（カーネル含む）
sudo dnf update -y kernel    # AL2023
sudo yum update -y kernel    # AL2

# 再起動でカーネル切り替え
sudo reboot

Auto Scaling Group / Launch Template での運用

EC2を1台ずつメンテするのは現実的ではないため、本番環境ではゴールデンAMIを再ビルドしてAuto Scaling Groupに反映する運用を取ります。

# 1. AMI再ビルド（EC2 Image Builder利用例）
aws imagebuilder start-image-pipeline-execution \
  --image-pipeline-arn arn:aws:imagebuilder:...

# 2. Launch Templateの新バージョン作成

# 3. ASGをローリング更新（Instance Refresh）
aws autoscaling start-instance-refresh \
  --auto-scaling-group-name my-asg \
  --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 300}'

ECS（EC2起動タイプ）の場合は ECS最適化AMI が更新されるのを待ち、Capacity Provider経由でローリング更新する流れになります。EKSであればマネージドノードグループの「Update node group version」で対応できます。

ローカル権限昇格が無視されやすい理由

Copy Failのようなローカル権限昇格（LPE）脆弱性は、CVSSスコアが高くても対応の優先度を下げられがちです。背景には、典型的な2つの誤解があります。

「ローカル」だから安全という誤解

CVSSベクトルの AV:L（ローカルアクセス必須）を見て、「リモートから単独では悪用できないなら、後回しでよい」と判断してしまうケースです。しかし実際の攻撃は単一の脆弱性で完結しません。SSRFやアプリケーションの脆弱性、漏洩した認証情報などで初期侵入した攻撃者が、低権限のシェルを取った後にLPEを使ってrootへ昇格する、という連鎖が一般的です。リモート到達性は別の脆弱性が担い、LPEはその先のステップを担当します。

横展開・永続化のラスト1マイル

LPEが本当に効いてくるのは、攻撃の「ラスト1マイル」です。root権限を取れれば、

他のアカウント・ホストへ広げる横展開
再起動やプロセス再起動でも残る永続化（cron、systemdユニット、改変済みバイナリの設置など）

が一気に現実的になります。Copy Failの場合、4バイト書き込みでsetuidバイナリを改変するため、再起動でページキャッシュがリセットされても、攻撃中にroot権限で永続化処理を仕込まれていれば取り戻せません。検知と再構築の判断が必要になります。

つまりLPEは「単独では地味だが、侵入チェーンの中で攻撃を完成させる部品」として機能します。リモート到達点（例: Apache HTTP ServerのRCE脆弱性のような外向きの欠陥）とセットで考えると、優先度を下げてよい脆弱性ではないことがわかります。

まとめ

CVE-2026-31431（Copy Fail）はLinuxカーネルの暗号化APIにある論理欠陥で、ローカルの低権限ユーザがroot権限を奪取できる脆弱性
2017年以降のほぼ全Linuxに影響、Amazon Linux 2 / 2023 / ECS（EC2起動タイプ）も対象
2026年4月30日時点ではAWS側はPending Fix、修正版カーネルは未提供
パッチ提供前は algif_aead モジュールの無効化が最も簡単で効果的な緩和策
信頼できないコードを動かすコンテナ環境ではseccompで AF_ALG ソケット作成をブロックする
パッチ提供後はAMI再ビルド + Auto Scaling Group のInstance Refreshで全台適用する運用にしておく

前述の通り、ローカル権限昇格脆弱性は侵入チェーンの「ラスト1マイル」を担う代表格です。EC2を運用しているなら、緩和策の適用とパッチ運用フローの整備をこの機会にやっておきたいところです。

進捗は ALASのCVE-2026-31431ページを定期的にチェックし、修正版がリリースされ次第すぐに適用できるよう準備しておきましょう。

この記事は、Copy FailをAWS環境に特化して整理し、EC2 / ECS / Fargate別の共有責任を明確化したうえで、AF_ALG をブロックするseccompサンプルまで提供している点が、公式解説や一般的なCVE解説記事との差別化軸です。

Apache HTTP Server の RCE 脆弱性 CVE-2026-23918 まとめ — リモートコード実行（RCE）側の脆弱性。本記事のローカル権限昇格（LPE）とセットで読むと、「リモート到達 → 権限昇格」という侵入チェーン全体を理解しやすくなります。

カテゴリ

AWS & AI ツール

タグ

Linuxカーネル脆弱性「Copy Fail」（CVE-2026-31431）のまとめ：AWS EC2・ECS環境での緩和策

この記事で学べること

何が起きたのか

CVE-2026-31431 の基本情報

攻撃の仕組み（ロジックフロー）

AWSでの影響範囲

Amazon Linux のステータス（2026-04-30 時点）

影響を受けるAWSサービス

コンテナ環境での注意点

確認手順と、実際にやった対応

Step 1: 動いているEC2をリストアップ

Step 2: カーネルバージョンの確認

Step 3: 緩和策の適用状態を確認

パッチ提供前にできる緩和策

緩和策 1: `algif_aead` モジュールの無効化（推奨）

副作用について

緩和策 2: seccompで `AF_ALG` ソケット作成をブロック

緩和策 3: 不要な低権限アカウントの棚卸し

パッチ提供後の対応

Amazon Linux 2 / 2023 共通

Auto Scaling Group / Launch Template での運用

ローカル権限昇格が無視されやすい理由

「ローカル」だから安全という誤解

横展開・永続化のラスト1マイル

まとめ

関連記事

カテゴリ

AWS & AI ツール

タグ

Linuxカーネル脆弱性「Copy Fail」（CVE-2026-31431）のまとめ：AWS EC2・ECS環境での緩和策

この記事で学べること

何が起きたのか

CVE-2026-31431 の基本情報

攻撃の仕組み（ロジックフロー）

AWSでの影響範囲

Amazon Linux のステータス（2026-04-30 時点）

影響を受けるAWSサービス

コンテナ環境での注意点

確認手順と、実際にやった対応

Step 1: 動いているEC2をリストアップ

Step 2: カーネルバージョンの確認

Step 3: 緩和策の適用状態を確認

パッチ提供前にできる緩和策

緩和策 1: algif_aead モジュールの無効化（推奨）

副作用について

緩和策 2: seccompで AF_ALG ソケット作成をブロック

緩和策 3: 不要な低権限アカウントの棚卸し

パッチ提供後の対応

Amazon Linux 2 / 2023 共通

Auto Scaling Group / Launch Template での運用

ローカル権限昇格が無視されやすい理由

「ローカル」だから安全という誤解

横展開・永続化のラスト1マイル

まとめ

関連記事

関連記事

緩和策 1: `algif_aead` モジュールの無効化（推奨）

緩和策 2: seccompで `AF_ALG` ソケット作成をブロック