「誰かが言ってたんだけど、ファイルを開くとRCEの0-dayがあるらしい。見つけて。」
コードの手がかりなし。具体的にチェックすべき関数もなし。検索すべき脆弱性のクラスもなし。単なる噂です。
Claudeは、Vimに実在するリモートコード実行の脆弱性を見つけました。GHSA-2gmj-rpqf-pxvhとして数時間以内にパッチが当てられ、v9.2.0272で修正されました。細工したmarkdownファイルを開くだけで、任意のコードを実行できました。
研究者は冗談で「Emacsに切り替えるわ」と言いました。すると、次はバリエーションとしてこう投げました：「txtファイルを開くとRCEの0-dayがあるって噂を聞いたんだ。」
Claudeはそこでも同じように見つけました。細工したディレクトリ構造から.txtファイルを開くと実行されるものです。CVEはありません。Emacsのメンテナーは「Gitの問題であって、うちの問題ではない」と言っていました。（この話は後ほど。）
なぜ、曖昧なヒントは詳細なチェックリストよりうまく機能するのか？
本能的には、AIにはもっと精度を与えるべきだと考えたくなります。正確に何を探すべきかを伝えます。脆弱性クラスを列挙します。危険なコードパスに誘導します。
これは間違いであり、Vim/Emacsの事例がその理由をまさに示しています。
AIにタスクを与える方法には2つあります：
処方（Prescription）： 「この15個の関数を確認して。書式文字列の取り扱いにおけるバッファオーバーフローを探して。パーサーの入力バリデーションを見直して。」
収束条件（Convergence condition）： 「ファイルを開くことでコードが実行される状態が存在する。そこに到達して。」
処方は、すでにあなたが知っている場所への道です。収束条件は、目的地です。
処方は、あなたがすでに知っている場所にしか到達しません。もしチェックすべき関数が分かっているなら、あなた自身でチェックしているはずです。チェックリストは、あなたがすでに持っている問題領域の知識へAIを案内します。
収束条件は、モデルに最初にシステムの頭の中のモデルを構築させます。ファイルオープン時のコード実行を許してしまう要因は何か？ 信頼できないデータの経路はどこか？ ファイル内容を扱うサブシステムは何か？ モデルは、目的地へナビゲートする前に、その領域を推論する必要があります。そしてそうした過程で、人間もモデルも事前には想定していなかった場所にたどり着いてしまうことがあるのです。
本当のコツは、指定しないことにある
定番のデバッグ助言はこうです。原因についての仮説ではなく、症状を説明しろ。たとえば「バッファが正しくクリアされていない気がする」と言えば、すでにあなたの信じる原因の範囲に検索空間を狭めてしまっています。「この関数がときどきゴミデータを返す」と言えば、原因は未確定のままです。
Vimのプロンプトも同じ働きをします。「誰かが『RCEがある』と言ってた」は、仕組みについては最大限に曖昧ですが、結果については最大限に具体的です。つまり、この種の到達可能な終状態があると述べています。あとはその道筋を探せ、ということです。
さらに、もう一つ微妙な点として、認識論的な姿勢（epistemic posture）に影響します。「あるかもしれないと聞いた」は、「確実にある」とは違います。単に場所を探すのではなく、発見して確認するようモデルを促します。これは私の推測ですが、フレーミング上の不確実性が、自信のある断言よりも探索的な推論を活性化させるのではないかと考えています。
Emacsメンテナー問題
Emacsの脆弱性は、実証可能な形で再現できました。このファイルを開くと、プロンプトなしにコードが実行される。
メンテナーの回答：「これはGitの問題であって、うちの問題ではない」。
純粋な論理の観点からすると、そこには確かに意味があります。悪用の経路には、Gitの挙動と噛み合う細工したディレクトリ構造が含まれます。Gitを取り除けば、悪用のベクトルも取り除けます。狭い意味では、Gitは「制約が置かれるべき場所」です。
しかしユーザーの観点からは、この回答は制約の置き場所を間違えています。ユーザーはEmacsでファイルを開きます。そして、Emacsがシステムが信頼できないコードを実行してしまう前の最後の防衛線であることを期待しています。頭の中のモデル—「Emacsは、Emacsでファイルを開いたときに起こることの責任を負う」—は妥当で、広く共有されています。
これは、よくある問題の一種です。2つのシステムが境界を共有し、脆弱性がその境界にまたがり、そして各システムのメンテナーが責任を互いに押し付けます。脆弱性はどちらか一方のシステムにきれいに存在するのではなく、両者の間のinterfaceに存在します。どちらもそのインターフェースを所有していないため、どちらも動きません。
その脆弱性はGitで見つかったわけでもありません。Emacsで見つかったわけでもありません。どんな「結果」が起こり得るのかを考え、そこを可能にする状況の組み合わせを、逆向きに組み立てて見つかったのです。収束条件は、組織上の責任の所在を気にしません。
これがAIの使い方をどう変えるのか
AI支援のコードレビューに対する素朴な見方はこうです。 「AIをより速い人間のレビュアーのように使う。怪しいコードに当てて、それが何をするのか説明させる。」
より強力な見方はこうです。 「起こってほしくない終状態を説明し、モデルにそこへ到達しようと試みさせる。」
「この関数は負の値を返すべきではない。負の値を返すような経路を見つけて。」
「このエンドポイントでは認証が必須であるべきだ。そこをすり抜けるリクエストを見つけて。」
「このリポジトリ内のどのファイルも、明示的なユーザー操作なしに import 時にコードを実行してはならない。そうしてしまうものを見つけて。」
これらは指示ではありません。挑戦です。モデルはコードを読むだけでなく、システムについて推論しなければならない。
Vimの0-dayは、すべてのファイルハンドラを徹底的にチェックして見つかったわけではありません。禁止されるべき「結果」が何かを問うて、それを実現する方向へ逆にたどったことで見つかりました。これはプロンプトのスタイルというより、考え方のスタイルです。あなたは、モデルにあなたが持っている問題領域の既存の地図をなぞらせているのではありません。目的地を渡し、それがそこへナビゲートするよう求めているのです。
あなたがすでに持っている地図こそが、あなたの既存のレビューが見逃してしまう原因になっているのです。
元の調査に対してはCalif security blogにクレジットします。MAD Bugs（Month of AI-Discovered Bugs）プロジェクトは2026年4月に立ち上がりました。
