2026年4月29日に公開されたLinuxカーネルのローカル権限昇格脆弱性「Copy Fail」（CVE-2026-31431）について、公開後数日で米国政府の緊急対応とMicrosoftによる独自の注意喚起が相次ぎました。米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は5月1日、本脆弱性をKnown Exploited Vulnerabilities（KEV）カタログへ追加し、米国連邦民間行政機関（FCEB agencies）に対して2026年5月15日までのremediationを求めました。同日、MicrosoftもDefender Security Researchによる独自の注意喚起を公開し、「数百万のKubernetesクラスターが影響を受け得る」と警告しています。本記事では、Copy Fail公開後の動向に焦点を絞り、米政府対応の意味、Microsoftが指摘するKubernetesリスク、そしてRHEL系ディストリビューションで広く流通している暫定対策が実は機能しないという重要な技術的注意点を整理します。
Copy Fail脆弱性の技術詳細（algif_aeadサブシステムの論理バグ、ページキャッシュ書き換えによるroot取得の仕組み、影響範囲、各ディストリビューションの追跡状況等）については、先行記事「Linuxカーネル脆弱性『Copy Fail』CVE-2026-31431公開——2017年以降の主要ディストリで732バイトでrootへ」を参照してください。
米政府による警告——KEV登録と5/15パッチ期限
CISAは2026年5月1日、本脆弱性をKnown Exploited Vulnerabilities（KEV）カタログへ追加しました。KEV追加の判断基準は「実際に悪用が観測されていること（active exploitation in the wild）」であり、CISAアドバイザリでは「Linux Kernel contains an incorrect resource transfer between spheres vulnerability that could allow for privilege escalation」と記載されています。
KEV登録に伴い、Binding Operational Directive（BOD）22-01が発動されました。BOD 22-01は、米国連邦民間行政機関（FCEB agencies：Federal Civilian Executive Branch agencies）に対して、KEV登録された脆弱性について指定期限内のremediation（修正対応）を義務付ける拘束的指令です。Copy Failについては、2026年5月15日が期限として設定されました。脆弱性公開（4月29日）から実質2週間という短期間です。
BOD 22-01は連邦機関を直接の対象とする規則ですが、米国連邦と取引のある企業や、規制業界（金融・医療・重要インフラ等）の組織にとっては事実上の業界標準として機能してきました。日本国内の組織であっても、米国子会社・グループ会社や米国顧客を持つ事業者は、5月15日を念頭に置いた対応計画を立てることが推奨されます。なお、現時点で確認できる一次ソースでは、本件は単独でリモート悪用される性質のものではありません。Microsoftは、Copy Failが深刻化するシナリオとして、SSHアクセス、悪性CIジョブの実行、コンテナ内のfootholdといった初期侵入経路と組み合わさるケースを重視しています。
Microsoftによる独自の注意喚起
Microsoftは2026年5月1日付で、Defender Security Researchによる公式ブログを公開し、Copy Failについて独自の注意喚起を行っています。Microsoftブログによれば、影響対象として「Red Hat、SUSE、Ubuntu、AWS Linuxを含む主要Linuxディストリビューション」を挙げており、「クラウドLinuxワークロードの相当部分、および数百万のKubernetesクラスター」が影響を受け得るとしています。
悪用の現状について、Microsoft Defenderは「現時点での実際の悪用は限定的であり、主にPoCテスト段階の活動として観測されている」と述べる一方、「完全に動作するExploit PoCが入手可能であり、パッチ適用が間に合うかどうかの競争状況にあるため、今後数日で脅威アクターによる悪用が増加する可能性が高い」とも評価しています。Microsoft Defender XDRでは、関連の検知シグネチャ「Exploit:Linux/CopyFailExpDl.A」等を提供しているとのことです。Microsoft Defender Vulnerability Management（MDVM）も、顧客環境で本脆弱性の影響を受け得るデバイスを可視化する機能を提供しています。
Microsoftブログが特に強調しているのは、「コンテナ内で起きたRCEを潜在的なホスト侵害として扱い、侵害指標が出た場合には迅速なノード再生成（rapid node recycling）を実行すべき」という運用方針です。これはCopy Failがコンテナ脱出経路として機能し得ることを念頭に置いた推奨で、従来のコンテナセキュリティ運用に対する見直し要請とも読めます。
PoC公開状況とKubernetesリスクの顕在化
Copy Fail公開後、GitHub上では汎用版のPoCに加えて、Kubernetes・コンテナ脱出を意識したPoCも公開されています。これにより、本件が単なるローカル権限昇格の問題ではなく、クラスタ運用上の現実的なリスクとして扱うべき段階に入っていることが明確になっています。Bugcrowdの解説によれば、Theoriが「one operator prompt, no harnessing」で約1時間のスキャンによってこの脆弱性を発見したという経緯と、公開後にPoCがコミュニティ全体に広がっている状況のいずれもが、本件の特異性を示しています。
Microsoftが「数百万のKubernetesクラスターに影響」と表現した背景には、こうしたKubernetes向けPoCの存在があります。マネージドKubernetesサービスを利用している組織にとって、本脆弱性は単なる「カーネルのローカル権限昇格」ではなく、「マルチテナント前提のクラスター運用そのものを揺るがす事象」として捉える必要があります。1つのPodで動作するアプリケーションに侵入された場合、Copy Failを使ってノードへの脱出が成立すれば、同じノード上で動作する他テナントのワークロード全体が侵害圏に入る可能性があるためです。
暫定対策の重要な補足——CloudLinuxが警告するRHEL系での技術注意点
先行記事では、Theori公開資料を引用してalgif_aeadカーネルモジュールの無効化を暫定対策として紹介しました。しかし、CloudLinuxが公式ブログで重要な警告を発しています。oss-securityリスト等で広く流通している「/etc/modprobe.d/配下のファイルにinstall algif_aead /bin/falseを追加し、rmmod algif_aeadを実行する」という手順は、CloudLinux、AlmaLinux、その他RHEL系ディストリビューションでは動作しません。
動作しない理由は、これらのディストリビューションではalgif_aeadがカーネル本体に組み込まれている（CONFIG_CRYPTO_USER_API_AEAD=y）ためです。modprobe.dルールでは読み込みをブロックできず、rmmodでも削除できません。コマンド自体はエラーなく実行されるため、誤って「対策を適用できた」と判断してしまうリスクがあります。これは「false sense of protection」（誤った安心感）と呼ぶべき状態で、運用上は深刻な落差を生じさせる恐れがあります。
CloudLinuxが推奨する代替手順は、grubbyを用いてalgif_aead initcallをブートパラメータでブラックリスト化する方法です。具体的にはinitcall_blacklist=algif_aead_initをカーネルコマンドラインに追加し、再起動することで、AEAD AF_ALGインターフェースの起動時登録を抑止します。再起動後は/proc/cmdlineでパラメータが反映されているかを確認することが推奨されます。
互換性についても、CloudLinuxは具体的な情報を提供しています。dm-crypt/LUKS（ディスク暗号化）、kTLS、IPsec、SSH、デフォルトのOpenSSL/GnuTLSビルドはAF_ALGに依存しないため影響を受けません。AF_ALGに明示的に依存するアプリケーション（OpenSSLのafalg engineを有効化している場合や、AF_ALG経由のハードウェア暗号オフロード等）が存在する場合のみ、運用影響が出る可能性があります。多くの一般的なWebホスティング環境では影響限定的、というのがCloudLinuxの整理です。
クラウドプロバイダの対応動向
クラウドプロバイダ各社も、本脆弱性に対する個別の対応を進めています。Microsoft Azure Kubernetes Service（AKS）はGitHub issue形式でCVE-2026-31431のmitigation guideを公開し、既存ノードへのhotfix適用やself-service mitigationを案内しています。Defenderによる検知シグネチャ「Exploit:Linux/CopyFailExpDl.A」等についてもMicrosoft公式ブログで言及されています。OVHcloudのManaged Kubernetes Serviceは、顧客の自己管理ノードに対してプロバイダ側からパッチ適用ができないため、DaemonSet経由の暫定対策スクリプトを提供しています。Amazon Linux Security Centerでも本CVEは追跡されているものの、本稿執筆時点ではAL2およびAL2023の複数kernel系列がPending Fixと表示されています。
コミュニティベースの取り組みとして、DeckhouseコミュニティはDeckhouse Kubernetes Platform向けにd8-copy-fail-mitigationプロジェクトを公開しています。これはDeckhouse管理クラスタのノードでalgif_aeadのブロックとruntime detectionを行うためのリソース集です。Deckhouse以外の環境にそのまま適用できるとは限りませんが、暫定対策をマニフェスト化する際の参考実装として参照する価値があります。
実務観点——30日パッチサイクルが追従できなくなる時代
Copy Failで突きつけられた最大の論点は、多くの企業が運用している「重要パッチは30日以内に適用」というポリシーが、現代の脆弱性タイムラインに追従できなくなりつつあるという事実です。
本件のタイムラインを整理すると、4月29日に脆弱性公開、公開後早期に公開PoCがGitHubに登場、5月1日にCISA KEV追加と5/15期限設定、同日Microsoft独自警告——という展開で、公開から実質的な対応期限まで約2週間しかありません。これに対し、多くの組織のパッチ適用ポリシーは「Critical/Highは30日以内、それ以外は90日以内」といった水準で運用されています。CVSS 7.8（High）に分類されるCopy Failは、このポリシーでは「30日以内」のクラスに入りますが、実際にはCISA期限を踏まえれば16日以内の対応が求められる、という状況です。
米国連邦と取引のある日本企業や、規制業界の組織は、CISA KEV期限を実質的な業界標準として念頭に置いた運用設計が求められる段階に来ています。具体的には、KEV登録通知を運用フローのトリガーに組み込む、緊急パッチ適用runbookを脆弱性公開時点で準備しておく、暫定対策（特にRHEL系での前述の注意点を踏まえたもの）を即座に展開できる体制を整えておく、といった対応が現実的な選択肢となります。
もう1点重要なのは、暫定対策の有効性検証を怠らないことです。CloudLinuxが指摘した「modprobeベースの手順がRHEL系で効かない」という事例は、コマンドが成功すれば対策できたと思い込みがちな運用に対する警鐘です。暫定対策を適用した後は、必ず/proc/cmdline確認、lsmod | grep algif_aead確認、または検知シグネチャによる動作テストなど、何らかの形で「実際に効いているか」の検証ステップを組み込むべきでしょう。
ソース
一次情報
- CISA Known Exploited Vulnerabilities Catalog（CVE-2026-31431エントリ）
- Microsoft Security Blog（Defender Security Research）：「CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments」（2026年5月1日付）
- Theori / Xint Code:
https://xint.io/blog/copy-fail-linux-distributions - 各ディストリビューション公式CVE追跡ページ
参考情報
- TechCrunch: 「US government warns of severe CopyFail bug affecting major versions of Linux」
- The Hacker News: 「CISA Adds Actively Exploited Linux Root Access Bug CVE-2026-31431 to KEV」
- CloudLinux Blog: 「CVE-2026-31431 (Copy Fail): Mitigation and Upcoming Patches for CloudLinux」
- Qualys ThreatPROTECT: 「Linux Kernel Vulnerability Exploited in the Wild (Copy Fail) (CVE-2026-31431)」
- Bugcrowd: 「What we know about Copy Fail (CVE-2026-31431)」
※本稿の対応動向は公開時点で確認できた情報に基づきます。CISA KEVカタログ、Microsoft Defender関連シグネチャ、各ベンダーアドバイザリは更新されるため、最新情報は各公式ページでご確認ください。
slug: linux-copy-fail-us-gov-warning-may15
コメント