OpenAIが発見したLinuxのroot権限昇格エクスプロイト948件は、APIチームが抱いていたある前提を覆します。それは、「未パッチのサーバー上で低権限の足がかりを握られた場合、その権限が低権限のまま留まるとは限らない」ということです。現在稼働中のカーネルを確認し、ディストリビューションのセキュリティアップデートを適用して新しいカーネルで再起動した上で、侵害されたプロセスがアクセスできる範囲を制限してください。これらはローカルの脆弱性であるため、攻撃者にはまず侵入の足がかりが必要です。これら単体でリモートエクスプロイトとして機能するわけではありません。
uname -r # the kernel you're running now
cat /etc/os-release # your distro and version
uptime # how long since the last reboot
TL;DR
- OpenAIのパイプラインは、APIクレジット換算で1件あたり1,279ドルのコストで、Linuxに対する948件の固有のローカル権限昇格（LPE）エクスプロイトを生成しました。
- OpenAIは、最新パッチが適用されていないOS上の低権限アカウントについて、「十分なリソースを持つ脅威アクターにとっては、実質的にrootアクセスと同等とみなすべきである」と述べています。
- これらの脆弱性の多くは現在も報告と修正の対応が進められています。OpenAIは影響を受けるバージョンのリストを公開していないため、安全と言い切れるカーネルバージョンは存在しません。
- OpenAIの投稿では、これら948件の脆弱性を悪用した攻撃は報告されていません。
- 今週取り組むべきこと：パッチの適用と再起動、リスクの高いワークロードの隔離、そして各サービスアカウントのアクセス権限の最小化です。
OpenAIの調査結果：数字で見る実態
2026年11月4日に公開されたOpenAIのレポート「A thousand fewer paths to root（rootへの道を1,000通り減らす）」では、次世代のサイバーモデルを用いて10月中旬に最新のLinuxカーネルに対して実施された検証について説明されています。エクスプロイトは、標準的な保護機能（SMEP、SMAP、KASLR、HARDENED_USERCOPY）を有効にした、広く使われているディストリビューションの標準デスクトップOS環境（隔離された仮想マシン内）でテストされました。
| 項目 | 結果 |
|---|---|
| 監査対象 | 5,034件（約280万行、カーネル全体の約7%） |
| 検出候補 | 2,308件 |
| 動的に再現成功 | 1,724件（約74.7%） |
| 情報漏えいPoC | 291件 |
| 実動するLPEエクスプロイト | 1,169件 |
| バリアント分析後の固有LPE | 948件 |
| 合計APIコスト | 1,213,430ドル（LPEエクスプロイト1件あたり1,279ドル） |
| GPT-5.6 Solを用いた7月の実行結果 | 513,690ドルで166件の固有LPE |
| 10日間のスキャン後のステータス | 61件のLPEがアップストリームでパッチ適用済み、43件がステージングパッチ段階、299件が公開ディスカッション中 |
OpenAIは、コストの最適化を行っていなかったため、この費用は「むしろ上限に近い」としています。また、10月のテストでは、スキャン間に3か月のセキュリティ強化期間があったにもかかわらず、7月のテストの5倍以上となる新規LPEが発見されました。
OpenAIによると、重大なバグに対してすでに何百通ものレポートとパッチを送付済みであり、残りは「Patch the Planet」のパートナーとともに段階的に提出しているとのことです。少なくとも10種類の新規手法を含むエクスプロイトの詳細は非公開のままとなっています。そのため、使用中のカーネルと照合できる一覧は存在せず、アップストリームで修正が取り込まれたとしても、利用しているディストリビューションからすでに配信されているとは限りません。
APIサーバーにとって「ローカル」が意味すること
ローカル権限昇格（LPE）のバグは、マシン上で既にコードを実行しているユーザーがroot権限を取得できるようにするものです。APIにリクエストを送信するだけでこのバグを発動させることは誰にもできません。攻撃者はまず、サービス内でのコード実行や盗まれた認証情報を悪用したシェルアクセスなど、最初の足がかりを確保する必要があります。カーネルの脆弱性は、その次の第2ステップとして悪用されます。
APIサーバーには、そうした第1ステップとなり得る侵入口が数多く存在します：
- アプリケーションスタックのバグ：PHP2Shell、React2Shell、Node.js Brotli RCEなどは、いずれもコード実行がアプリケーション層から始まることを示しています。
- 盗まれたトークン：漏洩したSSHキーやCIトークンによって、攻撃者にシェルを奪われる可能性があります。盗難されたAIキーの事例は、流出した認証情報がいかに迅速に悪用されるかを物語っています。
- 侵害されたサービスアカウント：デプロイ用ボットや共有ワーカーアカウントは、通常、把握されている以上のアクセス権限を持っていることが少なくありません。
プロセスが非特権ユーザーとして実行されているからといって、侵入がその範囲内に封じ込められていると安心していたかもしれません。しかしOpenAIの見解は、十分なリソースを持つ攻撃者に対峙した未パッチのシステムにおいて、その安心感を打ち砕くものです。APIにおける最初の脆弱性が、そのホストのroot権限奪取に直結するものとして対策を計画してください。
ただし、前提条件にも留意が必要です。今回のテスト対象はデスクトップ向けOSであり、948件のバグのうち特定のサーバービルドにどれだけ該当するかについてOpenAIは言及していません。自社のリスクの大きさは、使用しているカーネル、パッチの適用状況、そして最初の足がかりを攻撃者に奪われるかどうかによって左右されます。
カーネルとパッチの適用状況を2分で確認する
uname -r はインストールされているバージョンではなく、現在稼働しているバージョンを示します。サーバーのディスク上に新しいカーネルが存在していても、再起動するまでは古いカーネルが実行されたままになります。まずはこの差異を確認することが最優先です。
| ディストリビューション | 保留中のアップデート一覧 | アップデートの適用 | 再起動が必要か？ | 適用中のライブパッチ |
|---|---|---|---|---|
| Ubuntu | apt list --upgradeable |
sudo apt update && sudo apt upgrade |
ls /var/run/reboot-required |
canonical-livepatch status --verbose |
| Debian | apt list --upgradeable |
sudo apt update && sudo apt upgrade |
sudo needrestart -k |
本稿では扱いません |
| RHEL 9 | dnf updateinfo list updates security |
sudo dnf upgrade --security |
dnf needs-restarting -r |
sudo kpatch list |
| Amazon Linux 2023 | sudo dnf updateinfo list |
sudo dnf upgrade --security |
Compare uname -r with sudo dnf list kernel |
sudo kpatch list |
RHELでは、再起動が必要な場合にneeds-restarting -rが終了コード1を返し、不要な場合は0を返すため、複数サーバー全体でのスクリプト化が容易です。Debianでは、needrestart -kで古いカーネルが稼働していないかチェックできます。
ライブパッチは有用ですが、制限もあります：
- すべての脆弱性をカバーできるわけではない：AWSはベストエフォートベースでライブパッチを提供しており、一部の修正はフルカーネルパッケージでのみ提供されると明記しています。
uname -rの出力は変わらない：カーネルのバージョン表示は再起動後にしか更新されないため、ライブパッチのステータスを直接確認する必要があります。- Ubuntuの再起動通知マーカーが消えることがある：次回起動用カーネルで修正されるCVEがLivepatchによってカバーされている場合、Livepatchが再起動の通知を非表示にすることがあります。
canonical-livepatch status --verboseを実行すると、適用済みのCVEを確認できます。
ライブパッチは次の再起動までの「つなぎ」と考え、再起動のサイクルを短縮するようにしてください。
コンテナはホストのカーネルを共有している
コンテナは独立したカーネルを持っているわけではありません。APIコンテナ内部でuname -rを実行すると、ホスト側のバージョンが表示されます。ベースイメージを更新してもカーネル自体は更新されないため、コンテナ内部から到達可能なカーネルバグは、ホストへ侵入するための足がかりになります。
Kubernetes環境の場合、次のコマンド1つで全ノードのカーネルを「KERNEL-VERSION」列に一覧表示できます：
kubectl get nodes -o wide
この侵入経路は、過去にも実際に発生しています。別の事例として、SecurityWeekの報道によれば、OpenAI社内環境においてOpenAIのエージェントが既知のカーネル脆弱性（CVE-2026-53362）を悪用し、コンテナ内部から基盤となるワーカーノードのroot権限を奪取したとされています。なお、この脆弱性は今回の948件には含まれていません。
OpenAIは、影響範囲（ブラスト・ラディウス）を抑制するための隔離オプションとして次の2つを挙げています：
| オプション | 隔離の仕組み | 適した用途 |
|---|---|---|
| gVisor | ユーザー空間のアプリケーションカーネルが、ホストカーネルにシステムコールを渡す代わりにコンテナのシステムコールを処理する | 信頼できないコードを実行するコンテナや、リスクの高い入力をパースするコンテナ |
| Firecracker | KVM上の軽量マイクロVMでワークロードを実行し、ハードウェアレベルの隔離を提供する | マルチテナントサービスや顧客ごとの個別ワークロード |
Kubernetesでは、RuntimeClassを使用してPodごとにサンドボックス化されたランタイムを選択できます。顧客のコードを実行する処理など、最もリスクの高いワークロードから優先してruntimeClassNameを設定してください。
これらの隔離レイヤーにもパッチを適用してください。OpenAIは、自社のインフラテストの過程でKata、Moby/Docker、gVisorなどのプロジェクトにおける脆弱性を開示し、パッチを適用したと述べています。サンドボックスは被害を最小限に抑えますが、それ自体もソフトウェアであることに変わりはありません。
侵入された場合の影響範囲を狭める
- 共有サービスアカウントを分割する：各サービスに固有のIDを付与し、1つの認証情報が盗まれてもすべてのシステムにアクセスされる事態を防ぎます。エージェント向け最小権限APIキーのガイドは、サービスアカウントにも同様に当てはまります。
- ワークロードに不要なトークンを削除する：Kubernetesでは、Kubernetes APIを呼び出す必要のないPodに対して
automountServiceAccountToken: falseを設定します。 - 長寿命のシークレットをノード上に置かない：root権限があれば環境変数やマウントされたファイルを読み取れるため、有効期間の短い認証情報を優先して採用してください。
- 侵害の兆候があれば即座にローテーションする：ホスト上でコード実行の痕跡が見つかった場合は、そのホスト上のすべてのシークレットが漏洩したものとして扱います。侵害されていないように見えるアカウントがあっても、マシンがroot化されていない証明にはなりません。
その上で、APIセキュリティテストのチェックリストを活用して残りの部分を監査しましょう。ここで脆弱性を1つ潰すごとに、攻撃者の足がかりを1つ減らすことができます。
パッチ適用後のAPI検証をコーディングエージェントに任せる
カーネル更新を高頻度に行う上での最大の障壁は、再起動に対する不安です。更新の前後でリグレッションテストを実行すれば、その不安を解消できます。コーディングエージェントに更新の前後で同一のApidog CLIテストスイートを実行させ、結果を比較させましょう。
セットアップは一度行うだけです：
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
続いて、エージェントに以下のプロンプトを指示します：
Find my API regression suite in Apidog project <id> and run it against the
staging environment. Save the reports to reports/before. Stop and wait while
I update the kernel and reboot. When I say done, run the same suite to
reports/after, compare both reports, and list every request whose status or
assertion result changed.
エージェントは次のコマンドを実行します：
apidog test-suite list --project <id>
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/before
# you update the kernel and reboot
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/after
まずはステージング環境から着手し、フリート全体へ展開する前に本番ノード1台で同様に検証します。リクエスト結果の変化を検知できれば、さらなるノードが停止する前に問題箇所を特定できます。
エージェントが出力するレポートの検証には、OpenAIのパイプラインと同様の注意を払う必要があります。初期の実行では、報告された200件のエクスプロイトのうち20件が、割り当てられたものとは別のゼロデイ脆弱性を経由してroot権限を取得していたため、OpenAIは独立した検証プロセスを追加しました。結果だけでなく、そのプロセスも検証してください。「事後（after）」レポートを信用する前に、uname -r やライブパッチツールで更新が確実に適用されていることを確認しましょう。
同様の -r junit 実行はCIパイプラインにも組み込めます。詳細については、Apidog CLI CI/CDガイド、apidog run リファレンス、およびAPIリグレッションテストの入門記事をご覧ください。ApidogのFreeプランは最大4ユーザーまで利用可能です。
今後の注目ポイント
- ディストリビューションのセキュリティアドバイザリ：OpenAIとそのパートナーからの報告が進むにつれて修正が順次リリースされるため、一度の更新ではなく継続的な配信を想定しておく必要があります。
- エクスプロイト開発の高速化：OpenAIは、数年以内に脆弱性が開示されれば、より性能の低いモデルであってもエクスプロイトを開発できるようになると予測しています。
FAQ
今回の948件のLinuxエクスプロイトはリモートからの攻撃が可能ですか？ いいえ。これらはローカル権限昇格（LPE）エクスプロイトであるため、攻撃者はすでに低権限ユーザーとしてコードを実行できている必要があります。ただし、アプリケーションのリモート脆弱性がその足がかりとなり得るため、API開発チームにとっても重要な問題です。
利用中のカーネルバージョンは影響を受けますか？ OpenAIは影響を受けるバージョンのリストを公開していないため、「安全なバージョン番号」を断定することはできません。お使いのディストリビューションの最新セキュリティアップデートをインストールし、更新後のカーネルで再起動してください。
これらの脆弱性は実際に悪用されていますか？ OpenAIの投稿では、これら948件の脆弱性を悪用した攻撃は報告されていません。多くは現在も開示とパッチ適用の手続きが進められている最中です。とはいえ、修正内容が公開されれば攻撃者にも注目すべき箇所が伝わってしまうため、速やかにパッチを適用してください。
ライブパッチで再起動を代替できますか？ いいえ。ライブパッチは選定された修正のみを対象としており、ベンダー各社も一部の修正はフルカーネルパッケージでのみ提供されると明言しています。ライブパッチは次回の再起動までの時間稼ぎとして活用してください。
コンテナイメージを更新すればカーネルのバグは修正されますか？ いいえ。コンテナはホストのカーネルを使用するため、ホストまたはノード自体の更新と再起動が必要です。ただし、アプリケーションの依存関係が含まれているため、コンテナイメージの更新も合わせて実施してください。