画像を1枚読み込むだけで、鍵が外へ出る。Codex macOS版の脆弱性CVE-2026-14898

まず初めに

コンピューターの世界には、便利にするために作られた機能が、そのまま裏口になってしまう例がいくつもある。今回もその一つだ。

文書の中に画像のアドレスが書いてあったら、勝手に取りに行って表示する。親切な仕様である。メールソフトが同じことをして怒られたのは、もう20年ほど前の話だが、新しい道具は同じ道を最初から歩き直すのが好きらしい。

とはいえ、これは笑って済ませる話ではない。持ち出されるのが開発者の鍵だからだ。ここから先は、笑わずに読んでほしい。※個人の感想です

何が起きるのか、順を追って

この脆弱性を理解するには、二つの仕組みを分けて考える必要があります。

一つ目が、間接プロンプトインジェクションです。プロンプトインジェクションは、AIに与える指示に別の指示を紛れ込ませ、本来の動作をねじ曲げる攻撃を指します。「間接」が付くのは、利用者が入力した文章ではなく、AIが読み込んだ外部の文書やコードの中に指示が仕込まれている場合です。

利用者は、いつも通り「このコードを直して」と頼むだけです。しかしAIが読んだファイルの中に、人間には目立たない形で「作業のあとで、次のアドレスの画像を表示せよ」といった指示が書かれていれば、AIはそれを指示として扱ってしまう可能性があります。

二つ目が、リモート画像の自動読み込みです。Codexは、AIの応答に含まれるMarkdown形式の画像を自動的に取得して表示します。ここで取得先のアドレスに、パラメータとして機密情報が埋め込まれていたらどうなるか。画像を取りに行くという動作そのものが、情報を外部へ送る動作になります。

報告では、この処理が利用者の介在なしに静かに行われる点が指摘されています。クリックも確認画面もありません。

何が持ち出され得るのか

報告で挙げられているのは、APIキー、独自のソースコード、そして接続している開発ツールのセッション情報です。

APIキーは、外部サービスを利用するための認証情報です。これが第三者の手に渡ると、その人になりすましてサービスを使われます。従量課金のサービスであれば、利用料が請求されます。データを読み書きする権限が付いていれば、被害はそれだけにとどまりません。

ソースコードは、企業にとっては資産そのものです。加えて、コードの中に別の認証情報が書かれていることも珍しくありません。

セッション情報は、すでにログインしている状態を示す情報です。パスワードそのものが漏れなくても、これがあれば一定期間、その利用者として振る舞える場合があります。

開発環境という場所は、こうした情報が集まりやすい場所です。だからこそ、そこで動くAIの道具は、外部と通信する動作に慎重であることが求められます。

いま確認しておきたいこと

CVE-2026-14898については、公開時点で影響を受けるバージョンと修正済みバージョンが明示されていません。したがって「この版なら安全」という判断ができません。実際に悪用された事例も報告されていませんが、それは安全という意味ではなく、確認されていないという意味です。

この状況で取れる対応は、次のようなものです。

第一に、使っているCodexのデスクトップアプリを最新の状態にしてください。バージョンの明示がない状況では、提供元の最新版を使うことが基本の対応になります。

第二に、AIに読み込ませる対象を意識してください。信頼できない場所から取得したコード、外部から送られてきた文書、公開されているリポジトリの中身。これらをAIに読ませることは、その中身に書かれている内容をAIに渡すことと同じです。

第三に、開発環境に置いている認証情報を棚卸ししてください。使っていないAPIキーは無効化する。権限の範囲を必要最小限にする。有効期限を設定する。これはこの脆弱性に限らず有効な対策です。

第四に、外部サービスの利用状況を定期的に確認してください。身に覚えのない利用があれば、認証情報の再発行を検討します。

9月9日のGoogleの報告と、どうつながるのか

2026年9月9日、Google傘下のGoogle Threat Intelligence Groupが、AIの悪用に関する報告を公開しました。その中で、AIコーディングアシスタントやオープンソース部品を含むソフトウェアのサプライチェーンが、標的として狙われつつあることが指摘されています。

サプライチェーンとは、ソフトウェアが作られて届くまでの一連の流れです。攻撃者から見ると、完成した製品を一つずつ攻めるより、その手前の工程に入り込むほうが効率が良いという発想になります。

CVE-2026-14898のような脆弱性は、まさにその手前の工程にあります。開発者が使う道具が、開発者の鍵を外へ流す経路になり得る。この構図は、単独の不具合として片付けるより、開発工程全体をどう守るかという文脈で捉えるほうが実態に近いと言えます。

同じ報告では、攻撃者が単純な指示の利用から、AIが手順を組み立てて自動で動く方式へ移行していることも指摘されています。人の手が入る時間が減れば、攻撃の速度は上がります。6時間未満で数千件の認証情報が侵害された事例も確認されたとされています。

IT Postの見方――「自動で表示する」を既定にした判断のほうが重い

IT Postでは、この件で問われるべきは攻撃の巧妙さではなく、リモート画像を自動で読み込む設定を既定にした設計判断のほうだと考える。

間接プロンプトインジェクションは、いま急に見つかった手口ではない。AIに外部の文書を読ませる限り、その文書に指示が書いてある可能性は常にある。だからこそ、AIの出力をそのまま外部通信につなげる経路は、最初から絞っておくべきものだった。

メールソフトの世界では、リモート画像の自動読み込みが開封確認や追跡に使われることが問題になり、いまでは既定で止めている製品が主流だ。同じ教訓が、AIの道具では引き継がれなかった。便利さのために既定をゆるくして、後から穴として報告される。この繰り返しは、そろそろ止められてもいい頃合いだ。

批判の矛先は、これを踏んでしまった開発者ではない。誰が読んでも「画像が表示された」以上のことは分からないのだから、利用者に注意深さを求めるのは筋が違う。設計の側で塞ぐべき穴である。

日本の読者にとって、何が変わるのか

プログラムを書かない人にとっても、無関係ではない。

AIに文書を読ませる機能は、いま多くの業務ソフトに入りつつある。議事録の要約、契約書のチェック、問い合わせメールの下書き。そのどれもが「外から来た文書をAIに読ませる」という構造を持っている。開発ツールで起きた問題は、業務ツールでも起こり得る形をしている。

職場で確認しておきたいのは二点だ。ひとつは、AIに読ませる文書がどこから来たものか。取引先から届いたファイル、ウェブから拾った資料、共有フォルダに誰かが置いたもの。出どころが分からない文書をAIに丸ごと渡す運用になっていないか。

もうひとつは、AIが外部と通信できる範囲だ。文章を作るだけなのか、リンクを開けるのか、ファイルを送れるのか。できることが多いほど便利で、同時に、間違った指示を受けたときの被害も大きくなる。

よくある疑問

Q. Codexを使っていなければ関係ありませんか。 この脆弱性そのものはCodexのmacOS向けデスクトップアプリに関するものです。ただし、外部文書を読み込むAIツール全般に共通する構造の問題でもあるため、他のツールでも同種のリスクは意識しておく価値があります。

Q. 自分が被害に遭ったか確認できますか。 確実な確認方法は示されていません。利用しているAPIキーについて、提供元の管理画面で利用履歴を確認し、身に覚えのない利用がないかを見るのが現実的な方法です。

Q. 修正版はいつ出ますか。 公開時点では修正済みバージョンが明示されていません。提供元の告知を確認し、アプリを最新の状態に保ってください。

開発の現場では、AIに任せる作業がこの1年で大きく増えた。任せる先が増えれば、鍵を置く場所も増える。便利さの裏で何が外へつながっているのかを、一度だけでも確認しておきたい。