Linuxカーネルのeventpollにroot権限奪取の脆弱性、Pixel 10 ProでのPoCエクスプロイトが公開(CVE-2026-43074) AnthropicのMythosが発見した脆弱性|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年08月14日更新日時: 2026年08月14日

2026年8月10日、Linuxカーネルのeventpollサブシステムに存在する解放済みメモリ使用（Use-After-Free）の脆弱性CVE-2026-43074について、Pixel 10 Proでの動作実証を含む詳細な技術情報とPoC（概念実証）エクスプロイトコードが公開されたと報じました。この脆弱性は、AnthropicのAIモデル「Mythos」によるコード監査を通じて発見されたことでも知られており、AIによる脆弱性発見の実用性と限界の両方を示す事例として、当サイトでも継続して取り上げてきたテーマです。

この記事のサマリー

CVE-2026-43074は、Linuxカーネルのeventpollサブシステム（epoll）に存在する解放済みメモリ使用の脆弱性で、CVSSスコアは7.8（高）です。
脆弱性は、eventpollのループ深度チェック処理における競合状態が原因で、ep_free()がeventpoll構造体を早期に解放してしまう一方、別のスレッドがそのオブジェクトを参照し続けてしまう点にあります。
研究者は、この脆弱性を悪用した実証コードで、Pixel 10 Pro上において80%を超える成功率でroot権限のシェルを取得できることを確認しています。
修正はアップストリームで既に完了しており、eventpoll構造体の解放処理をRCU（Read-Copy-Update）猶予期間まで遅延させる形で対応されています。
本記事執筆時点で実際の悪用は確認されていませんが、詳細な技術情報とPoCエクスプロイトコードが公開リポジトリで公開されており、パッチ未適用の環境にとってはリスクが高まっています。
この脆弱性は、AnthropicのAIモデル「Mythos」がeventpollのコードを監査した際に発見したとされています。ただし、同じコード領域には、Mythosが見落とした、より深刻な別の脆弱性「Bad Epoll」（CVE-2026-46242）も存在していたことが、後に人間の研究者によって明らかになっています。

整理表

項目	内容
CVE番号	CVE-2026-43074
CVSSスコア	7.8（高、CVSSv3）
脆弱性の種別	eventpollにおける解放済みメモリ使用（Use-After-Free）
原因	ep_free()によるeventpoll構造体の早期解放と、別スレッドによる継続参照の競合
修正内容	eventpoll構造体の解放をRCU猶予期間まで遅延
実証環境	Pixel 10 Pro（Android 17、カーネル6.6.118、7月5日ビルド）
実証された成功率	80%超でroot権限シェルを取得
悪用状況	本記事執筆時点で実際の悪用は未確認、PoCエクスプロイトコードは公開済み
EPSS（30日）	0.1%
発見の経緯	AnthropicのAIモデル「Mythos」によるeventpollコードの監査
関連する見落とし	同じコード領域に存在した、より深刻な脆弱性「Bad Epoll」（CVE-2026-46242）はMythosが発見できなかった

何が起きたか

CVE-2026-43074は、Linuxカーネルの中核をなすeventpollサブシステムに存在する脆弱性です。eventpollは、多数のファイルディスクリプタを効率的に監視するための仕組みで、サーバーからAndroid端末に至るまで、広範囲のLinuxベースのシステムで利用されています。

脆弱性の原因は、eventpollのループ深度チェック処理における競合状態です。特定の条件下で、ep_free()関数がeventpoll構造体を早期に解放してしまう一方、別のスレッドがそのオブジェクトを参照し続けてしまうことがあります。親オブジェクトの参照カウントがゼロになった後も、epitemが読み取り可能な状態のまま残ることがあり、この状態で読み取りが行われると、解放済みのメモリ領域に触れてしまいます。この競合状態が、権限昇格につながる形で悪用可能であることが実証されています。

研究者らは、あるバイナリを2回実行するという手順で、root権限のシェルを取得できることを実証しており、80%を超える成功率を報告しています。技術的な詳細とPoCエクスプロイトコードは、GitHub上の公開リポジトリ（NebuSec/CyberMeowfia）で公開されています。実証はPixel 10 Pro（Android 17、カーネル6.6.118、7月5日リリースのビルド）で行われており、この時点でこの端末には修正が適用されていなかったことを示しています。

修正自体は、アップストリームのLinuxカーネルで既に完了しており、eventpoll構造体の解放処理をRCU（Read-Copy-Update）の猶予期間まで遅延させることで、競合状態そのものを解消しています。本記事執筆時点で実際の悪用は確認されていませんが、詳細な技術情報とPoCコードが公開された以上、パッチが未適用の環境ではリスクが高まっている状況です。

AnthropicのMythosによる発見と、見落とされた「Bad Epoll」

この脆弱性が特に注目される理由の一つは、その発見の経緯にあります。海外メディアの報道によると、CVE-2026-43074は、AnthropicのAIモデル「Mythos」がeventpollのコードを監査した際に発見したとされています。2023年4月の単一のコミットが、eventpollの約2,500行のコードに2つの異なる競合状態のバグを持ち込んでいたことが、後の調査で判明しており、CVE-2026-43074はそのうちの1つでした。

しかし、Mythosは同じコード領域に存在していたもう1つの脆弱性、通称「Bad Epoll」（CVE-2026-46242）を発見できませんでした。Bad Epollは、ep_remove()関数内の競合状態に起因するUse-After-Free脆弱性で、わずか6命令分という極めて狭いタイミングの中でしか成立しない競合状態であるにもかかわらず、公開されたPoCでは99%という高い成功率が報告されています。さらに、Chromeのレンダラーサンドボックスやアンドロイドのアプリサンドボックスの内部からも到達可能とされており、CVE-2026-43074よりも深刻度が高い脆弱性として扱われています。

研究者による分析では、Mythosがこの隣接する脆弱性を見落とした理由として、2つの構造的な要因が指摘されています。1つは、競合状態が成立するタイミングの幅が極めて狭く、静的なコード分析だけでどの実行順序が問題を引き起こすかを推論することが、事実上困難だった点です。もう1つは、CVE-2026-43074が修正された後は、Bad Epollのメモリ破壊がKASAN（カーネルのメモリエラー検出機構）による検知をほとんどトリガーしなくなり、実行時の手がかりがほとんど残らなかった点です。

当サイトでは、Bad Epollの発見時にもこの経緯を取り上げており、Linuxカーネルに15年前からの脆弱性発見者へGoogleから9万ドル超の報奨金(CVE-2026-43499)で、AIモデルによる脆弱性発見が防御側の研究においてすでに実用段階に入りつつある一方、隣接する脆弱性の見落としという限界も併せ持つ実例として紹介しています。Mythosが実際に脆弱性を発見した別の事例としては、PHPのテンプレートエンジンTwigの脆弱性13件を発見した事例も過去に取り上げています。

対象範囲

この脆弱性は、2023年4月のコミット以降のコードを含む、Linux 6.4以降のカーネルに影響します。Android端末では、6.6系以降のカーネルを搭載する機種が対象となり、現行のPixel端末はこれに該当します。一方、Pixel 8など、2023年のコミットより前のベースとなる6.1系カーネルを使用している端末は、そもそもこの脆弱性の影響を受けません。RHEL・AlmaLinux・Rockyなど、同系統のカーネルコードを共有するディストリビューションも、同様の対象範囲に含まれる可能性があります。

情報システム部門が確認すべき対策ポイント

Linuxサーバー・Androidデバイスを問わず、稼働しているカーネルのバージョンとパッチ適用状況を確認し、CVE-2026-43074の修正が反映されているかを確認してください。
Android端末については、最新のセキュリティアップデートが適用されているかを確認してください。今回実証に使われたPixel 10 Proは、7月5日時点のビルドでは未修正の状態でした。
本脆弱性はローカルからの権限昇格に悪用されるため、単体では侵入経路にはなりませんが、他の脆弱性（アプリのサンドボックス脱出等）と組み合わせて悪用される可能性を踏まえ、優先度の高いパッチ適用対象として扱ってください。
同じeventpollのコード領域に存在するBad Epoll（CVE-2026-46242）についても、あわせて修正状況を確認してください。片方の脆弱性のみが修正され、もう片方が見落とされている可能性があります。
AIモデルによる脆弱性監査を自社の開発プロセスに導入している場合、今回の事例が示すように、AIが発見した脆弱性の修正だけで安心せず、同じコード領域に対する人間によるレビューもあわせて行う運用を検討してください。