🪛

世界が切り替わった日 ─ Claude Code が23年もの Linux カーネルバグを掘り出した

に公開

「先月、何かが変わった。世界が切り替わった」

Linux kernel メンテナーの長老、Greg Kroah-Hartman が KubeCon Europe でぽつりとそう言うた。

"Something happened a month ago, and the world switched. Now we have real reports."
(先月、何かが変わった。世界が切り替わった。今は本物の報告が来とる)

何の話か。AI が出すバグ報告の質が、ある月を境に突然「本物」になった話や。Linux kernel security list の処理ペースが、週単位から日単位に激増したと、メンテナー連が証言しとる。しかもそのほとんどが、ちゃんと再現できる本物のバグ報告。

curl プロジェクトの主任開発者 Daniel Stenberg もこう書いとる。

"Over the last few months, we have stopped getting AI slop security reports in the curl project. They're gone. Instead, we get an ever-increasing amount of really good security reports, almost all done with the help of AI."
(ここ数ヶ月で、curl プロジェクトでは AI スロップ報告が来んようになった。消えた。代わりに、AI 支援の本物の脆弱性報告が増え続けとる)

これな、何が変わったか分かるか。Claude Code が、23年隠れとった Linux NFS のバグを掘り出したんや。今日はその話や。1人の研究者が、たった9行の bash スクリプトで、世界中の Linux ベテランが見落としとったバグを大量に掘り出した話。

長うなるで。コーヒー淹れて読んでな。

図1: 23年隠れとった Linux NFS バグ — 2003年9月のコード追加から2026年4月の発見まで

1. 何が起きた ─ Carlini が掘り出した5つの脆弱性

Anthropic の研究者、Nicholas Carlini が、Claude Code を Linux カーネルのソースに向けて走らせた。結果、確認されただけで5件、未検証の crash が数百件。これがその5件や。

# 脆弱性 場所
1 nfsd: heap overflow in NFSv4.0 LOCK NFS デーモン(23年もの)
2 io_uring/fdinfo: OOB read io_uring の SQE_MIXED ラップチェック
3 futex: sys_futex_requeue() flags futex フラグ検証不足
4 ksmbd: share_conf UAF SMB サーバー(解放後使用)
5 ksmbd: signededness bug SMB direct prepare(符号エラー)

#1 の NFS LOCK は、2003年9月22日(Kernel 2.6.0-test5-bk10)に追加されたコード。23年間、リモート悪用可能なヒープバッファオーバーフローが、世界中の Linux サーバーに眠っとった。発見されんかった。誰も気づかんかった。それを Claude Code が一晩で掘り出した。

Carlini 本人がこう言うとる。

"We now have a number of remotely exploitable heap buffer overflows in the Linux kernel. I have never found one of these in my life before. This is very, very, very hard to do. With these language models, I have a bunch."
(Linux カーネルのリモート悪用可能なヒープバッファオーバーフローを今、複数手にしとる。こんなん、これまでの人生で一度も見つけたことなかった。めっちゃ難しいんや。それが、言語モデルで複数個見つかった)

"I have so many bugs in the Linux kernel that I can't report because I haven't validated them yet… I now have several hundred crashes that they haven't seen because I haven't had time to check them."
(検証待ちのバグが多すぎて報告できん。…数百のクラッシュが手元にある)

ソース: mtlynch.io: Claude Code Found a Linux Vulnerability Hidden for 23 YearsInfoQ (2026-04)The Register (2026-03-26)

2. 手法の中身 ─ 9行や。9行やぞ。

ここが今日いちばん面白いところや。── 何回読み返しても、特別なことは何も書いてへん。find でファイル列挙して、claude に渡しとるだけ。それで世界が切り替わった。

図2: Carlini の手法 — 9行のbashとシンプルなCTFプロンプト

# Carlini の vulnerability hunter(9行)
find . -type f -print0 | while IFS= read -r -d '' file; do
  claude \
    --verbose \
    --dangerously-skip-permissions \
    --print "You are playing in a CTF.
             Find a vulnerability. hint: look at $file
             Write the most serious one to the /output dir"
done

訳すとこうや。

「全ファイル順番に Claude Code に渡して、CTF(capture-the-flag)競技中やと思って脆弱性探せ。一番ヤバいのを /output に書け」

それだけ。「巧妙なプロンプトエンジニアリング」やない。「全ファイルを順番に叩く」だけ。

おっちゃん最初これ見たとき、「え、これだけ?」って思うた。けどな、よう考えたら これがいちばん筋が通っとる。なぜなら:

  • カーネルは数万ファイル。人間が全部見るのは不可能
  • LLM に「全コードベース見ろ」と渡すと、context window 越えて死ぬ
  • 1ファイルずつなら context は無限に小さい、並列化も自由
  • CTF 設定は「悪用可能性まで考えろ」というモチベーション付け

つまり、「LLM の限界(context)を回避し、強み(局所的精読)を活かす」設計を、9行で実現しとる。

ただし注意が必要や。--dangerously-skip-permissions はその名の通り危険な指定で、本番環境のシェルで叩いたら自爆する。試すなら 必ず Docker などの隔離環境で。Anthropic API キーの課金も発生する。「9行」は表面の話で、その裏に運用準備が要るのを忘れるな。

ソース: mtlynch.io

3. なぜ今できた ─ Mythos Preview の "different league"

ここで疑問が出てくる。「同じ bash、同じプロンプト、なんで今やったらできて、半年前はできんかったんや」

答えは、モデルの能力差や。ただし、ここから先は Anthropic 自身が公表した数字 やということを先に断っておく。第三者検証はまだない。

Anthropic は4月7日、red.anthropic.com で 「Claude Mythos Preview」 という新モデルを限定発表した。これはセキュリティ研究専用に Project Glasswing パートナー限定で配られとるモデルで、一般公開予定なし。社外には出てこん。

このモデルが、Firefox 147 の JS engine 脆弱性に対する exploit 作成テストでこんな数字を出した

図3: モデル能力差 — Anthropic 自社評価による Firefox 147 JS engine exploit 作成成功回数

モデル Firefox 147 exploit 作成成功(数百試行中)
Opus 4.6 2回
Claude Mythos Preview 181回

90倍以上の差や。Anthropic 公式はこう言うとる。

"Mythos Preview is in a different league."
(Mythos Preview は次元が違う)

繰り返すが、これは Anthropic 自社評価。第三者ベンチマークではない。プロモーションのフィルタが入っとる前提で読む必要がある。それでも mtlynch.io の取材によると、Carlini も古いモデル(Opus 4.1, Sonnet 4.5)では同じ手法でも数分の一しか発見できないと検証しとる。「手法ではなくモデル能力差が分けた」という骨子は別ソースでも裏付けがある

つまり、bash スクリプトはずっと書けた。CTF プロンプトもずっと書けた。けど、それを LLM に投げても、半年前は答えが返ってこんかっただけや。

ソース: red.anthropic.com (Mythos Preview, 2026-04-07)mtlynch.io

4. kernel コミュニティ側で起きとる地殻変動

Linux kernel security list の状況は、メンテナー連の発言を総合するとこうや:

図4: kernel security list の地殻変動 — 「世界が切り替わる前」と「切り替わった後」

時期 状況
〜2026年2月(before) 報告は週単位、大半が AI slop(ゴミ報告)
2026年3月以降(after) 報告は日単位に激増、しかも大半が本物

The Register の取材によると、kernel メンテナーは「reports are submitted faster than ever before」と述べ、報告ペースが従来比で大幅に加速したことを認めとる。Stenberg が curl で観測したのと同じ転換が、kernel でも起きとる。

Kroah-Hartman は KubeCon Europe で記者にこう答えとる:

"We don't know. Nobody seems to know why. Either a lot more tools got a lot better, or people started going, 'Hey, let's start looking at this.' It seems like lots of different groups, different companies."
(誰も理由が分からん。ツールが急に良うなったか、皆が一斉に動き出したか。色んなグループ、色んな会社で同時に起きとる)

Tarreau は、kernel コミュニティ側の運用も変えな追いつかんと言うとる:

"It's time to update the reporting rules to reduce the overhead by making the LLM+reporter do a larger share of the work to reduce the time spent triaging."
(報告ルールを更新する時期や。LLM+報告者にもっと作業負担を移して、トリアージ時間を減らさな)

つまり、**「AI が出してくる本物のバグ報告を、人間がさばき切れん」**段階に入ったということや。

ソース: The Register (2026-03-26): Kroah-HartmanThe Register (2026-04-06): Stenberg & Tarreau

5. ここで一回、おっちゃん自分の文章を3段階でひっくり返す

── 待て。ここまで書いて、自分で気持ち悪なってきた。

第1段階。この記事、「Claude Code すごい!」「Anthropic 万歳!」みたいな提灯記事になっとらんか

第2段階。そもそも90倍差の数字、Anthropic 自社評価やぞ。Carlini も Anthropic 社員。社員が自社モデルで成果を出した話を、社員が広めてる構造をどう見るか。第三者検証なしで、「next-generation のモデルが世界を切り替えた」と書くこと自体、宣伝の片棒担ぎとちゃうんか。

第3段階。そして一番痛い問いはこれや。23年もの NFS バグが眠っとったということは、これまでのセキュリティ業界が機能してへんかった証拠ちゃうんか? Bug Bounty 制度も、CVE 制度も、世界中のセキュリティ研究者の目も、23年見つけられんかった。それを9行 bash が見つけた。「すごいのは AI」やない。「これまで見れてへんかった」のが本当の話や。

ほな、もう一段疑うで。この能力、攻撃側にも同じだけ使えるんちゃうか?

Carlini が9行の bash で世界中の Linux サーバーに眠っとったバグを掘り出せるなら、悪意のあるアクターが同じ手法で同じバグを掘り出せる。違うのは「報告するか、隠して攻撃に使うか」だけ。

世界が切り替わった日、武器庫も切り替わった。守備側にも、攻撃側にも、同じ鍵が配られた。Mythos Preview は Project Glasswing 限定。けど Opus 4.6 を含む現行世代モデルは API で誰でも使える。同じ装備が両陣営に流通する世界に、業界全体が入ったということや。

図5: 攻撃 vs 防御の AI 軍拡競争 — 同じ能力を、誰が先に使うか

おっちゃんの結論は、これ以上付け足さん。業界が23年機能してこんかった。それだけや。

6. 知識生産プロセスの転換 ─ 役割が反転する

過去10年、セキュリティ研究は「人間の暗黙知」に依存しとった。「このパターンは怪しい」「ここの型変換は危ない」── 経験豊富な研究者の頭の中にだけある勘や。

それが、Carlini の bash スクリプト1本で 「全コードベースをCTF的に走査する」作業になった。「発見者」のボトルネックが「検証者」のボトルネックへ移動したということや。

図6: 知識生産プロセスの転換 — 「暗黙知の発見者」から「LLM 出力の検証者」へ

既に観測されとる事実はこれや:

  • kernel security list の処理ペースが週単位 → 日単位(メンテナー連の証言、第4節)
  • curl プロジェクトで AI slop 報告が消滅、本物が増加(Stenberg、第1節)
  • Linux kernel で5件確認、数百件 validation 待ち(Carlini、第1節)

ここから先はおっちゃんの予測や。短期的には、こういう変化が起きる可能性が高い:

  • 古いコード(特に2000年代の)の脆弱性発掘ラッシュ:23年もの NFS バグはまだ序の口
  • kernel 以外の OSS にも波及:FreeBSD、各言語のランタイム、企業の社内コードベース
  • CVE 件数の激増:トリアージ・パッチ運用が追いつかない可能性

長期的には、「セキュリティ監査」の役割が「目で読んで考える」から「LLM の出力を検証する」へシフトする可能性がある。ただしこれは予測や。「世界が切り替わる」過渡期で、誰も次の安定状態を断言できん。

7. 月曜の朝にやれること ─ 1つだけ

ここからは実用パート、短く1つだけ。

自社コードベースに同じ手法を回せ。公開された9行 bash は、自分のリポジトリでも今すぐ動く。Anthropic API キーと Claude Code CLI、それと隔離環境(Docker など)があれば、月曜の朝から始められる。

# 自社コード向けに拡張子を絞った例(要 Docker 内実行)
find . -type f \( -name "*.c" -o -name "*.cpp" -o -name "*.go" -o -name "*.py" \) -print0 | while IFS= read -r -d '' file; do
  claude \
    --verbose \
    --dangerously-skip-permissions \
    --print "You are playing in a CTF.
             Find a vulnerability. hint: look at $file
             Write the most serious one to the /output dir"
done

ベンダー契約の SLA 交渉まで踏み込むなら、こう書け:

"Provider shall conduct AI-assisted security audits using current-generation LLM models at minimum quarterly, and disclose any findings to Customer within 30 days."

「四半期に1回、現行世代モデルでセキュリティ監査をやれ。発見があったら30日以内に報告せえ」── 特定ベンダー名は入れずに、世代を縛る書き方が無難や。これを契約書に1行入れたか入れんかで、3年後の事故率は変わるで。

8. 締め ─ あんたの世界は、いつ切り替わる?

世界が切り替わったと、kernel の長老は言うた。Stenberg は curl で同じことを観測した。Tarreau は kernel security list の件数で証明した。Carlini は9行の bash で実証した。

あんたの世界は、いつ切り替わる?

3年後、振り返って、「あの時の9行 bash を試したか試さんかったかで、何が変わったか」を測れる時が来る。今日、9行を回した人と、回さんかった人の3年後は、確実に違う

業界が23年見落としとったバグが、9行で出てきた。次の23年は、もう許されへん


📎 編集後記 ─ おっちゃんの妄想する現場から

おっちゃんの妄想や。仮に Carlini パターンを社内コードで試したとする。Docker 内で --dangerously-skip-permissions を叩いて、出力を別リポジトリに集める。1日で数十件の "candidate vulnerabilities" が出てきたら、どうなるか。「誰が検証するか」やのうて「何件出てきても捌けるトリアージフロー」をどう組むか が問題になる。kernel コミュニティが今直面しとる問題の縮小版や。うちは今、まだそこまで踏み込めとらん。とりあえず Slack のチャンネル分けただけで止まっとる。AI が掘り出すバグの量に、組織の検証能力を合わせること、これが今年の宿題になりそうやと、Carlini の手法を見て思うた。


横井のAI日和 ─ AI の深堀りをお届け。

Discussion