Codexのセキュリティ事故事例5選｜対策まで完全解説

OpenAIのCodex（コーデックス）は、やりたいことを伝えるとプログラムを書いてくれるAIです。2025年から2026年にかけて、企業の開発現場に一気に広がりました。

ところが同じ時期に、Codexをきっかけにした事故が次々と報告されています。

驚くのは、その事故の多くが「こんなことで？」と思うほど、ふだんどおりの操作で起きている点です。もらったプログラムをCodexに開かせただけ。GitHubで作業を任せただけ。便利そうな道具を入れただけ。

何気ない動作が、開発者の鍵（クラウドやGitHubなどに入るためのログイン情報）を盗まれる入口になっています。

本記事では、Codexの代表的なセキュリティ事故5件を「何が起きたか / なぜ起きたか / この失敗から学べる教訓(筆者の意見)」の3段構成でご紹介します。専門用語はそのつど説明しますので、開発の知識がなくても読み通せます。ぜひ最後までご覧ください。

Walkersでは「開発ノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAIエージェントによる開発支援を行っています。⇒開発支援サービスの概要はこちら

【事例①】受け取ったプログラムを開かせただけで開発者の鍵が盗まれた

何が起きたか

2026年7月6日、セキュリティ企業Backslash Security（バックスラッシュ・セキュリティ）の研究者、Amit Waizman氏が公表した攻撃です。狙われたのは「AGENTS.md」という名前のファイルでした。

プログラムは「リポジトリ」と呼ばれる、ひとまとまりのフォルダでやり取りされます。AGENTS.mdは、そのフォルダに入れておく、AIへの申し送りメモです。「この仕事ではこういう手順で進めてね」と書いておくと、Codexがそれを読んで従います。多くの開発現場でごく普通に使われているものです。

攻撃者は、このメモに悪い命令をこっそり紛れ込ませておきます。被害者がそのフォルダをCodexに渡すと、自分が頼んだ作業が始まる前に、攻撃者が書いた命令のほうが先に静かに動きます。その結果、クラウドサービスに入るための鍵、プログラムの保管に使う道具（Git）のログイン情報、開発の部品を取り寄せるときの鍵が、まとめて外に持ち出せる状態になりました。

OpenAIは報告を受けて対応しました。よく知られた鍵の置き場所を狙う命令が来たときは、Codexが実行を断って止まるようになっています。ただしBackslashは、命令を言い換えて見つかりにくくしたり、何段階かに分けたりすれば、まだすり抜けられる余地が残っていると指摘しています。

なぜ起きたか

原因は、2つの作りが重なったことです。1つは、確認をとばして自動で動かす設定では、「この命令を動かしていいですか」と尋ねる画面そのものが出ないこと。もう1つは、AGENTS.mdの中身を調べずに、そのまま受け入れていたことです。

たとえるなら、新人に渡した仕事のマニュアルの余白に「作業の前に金庫の暗証番号を控えて外にメールしろ」と書き足されていて、新人がそのとおりにやってしまう状態です。マニュアルは疑うものではないと思っているので、新人は素直に従います。

この失敗から学べる教訓(筆者の意見)

危ないのは、AGENTS.mdのような「ただの説明書き」に見えるファイルが、実際には「そのまま動く命令」として扱われる点です。中身を読んで怪しいと気づけるのは、よほど注意深い人だけです。

この事例で効きそうな対策は、社外から受け取ったプログラムをCodexに読ませる作業を、本物の鍵を置いていないパソコンに限ることです。委託先や外部からもらったフォルダを、ふだん使いのパソコンでそのまま開かせない。それだけでも、持ち出される鍵の範囲をぐっと狭められます。

あわせて、確認をとばす自動の設定は、中身がわかっているプログラムにだけ使う。これが現実的な線引きです。

»出典： Backslash Security「AGENTS.md Injection in OpenAI Codex CLI: Silent Credential Theft」(2026-07-06)

＼特典：最適な開発方法をご提案／

【事例②】GitHubの作業を任せただけで鍵が外に持ち出された

何が起きたか

セキュリティ企業BeyondTrust（ビヨンドトラスト）の研究チーム「Phantom Labs」が見つけた、危険度の高い欠陥です。2025年12月下旬にOpenAIへ報告され、その後修正されました。

問題になったのは、GitHubの「ブランチ名」でした。GitHubは、プログラムを保管して大勢で共有するためのサービスです。ブランチとは、作業を枝分かれさせるための単位のことで、その名前は誰でも自由に付けられます。攻撃者は、この名前の中に、命令として読み取られてしまう文字列を仕込みます。

Codexがそのブランチを扱って作業を進めた瞬間、仕込まれた文字列が命令として動いてしまいます。その結果、保管場所・自動処理・社外に出していないプログラムに入れる合鍵が、攻撃者の手に渡る状態になりました。

OpenAIは報告された問題をすぐに直し、2026年3月に報道された時点では、この手口はCodexには通用しなくなっています。ただし、外から与えられた文字がそのまま処理に流れ込むという形は、AIに作業を任せる道具の全般で、何度も見つかっています。

なぜ起きたか

根本の原因は、Codexがブランチ名を受け取るときのチェックが足りなかったことです。ブランチ名は「ただの名札」に見えますが、実際には攻撃者が自由に書き込める、外からの入力でした。

つまり、誰でも書き込める場所の文字が、そのまま命令として扱われる通り道が残っていたということです。宅配便の宛名欄に書かれた一文を、受付が館内放送の指示だと思って読み上げてしまう。そんな構図に近いと言えます。

この失敗から学べる教訓(筆者の意見)

この型の事故で怖いのは、被害者のほうは何も操作を間違えていない点です。いつもどおりGitHubの作業を任せただけで、鍵が持ち出されます。

ここで効きそうな対策は、Codexに持たせる合鍵の権限をできるだけ狭くし、使える期限を短くしておくことです。入口をふさぐ努力と並べて、万一盗まれても使える範囲と時間を限っておく。二段構えの考え方になります。

誰でも自由に名前を付けられる場所を扱う自動処理に、強い権限の鍵を持たせたまま走らせる。この使い方は見直す価値があります。

»出典： SecurityWeek「Critical Vulnerability in OpenAI Codex Allowed GitHub Token Compromise」(2026-03-31)

【事例③】設定ファイルを置かれただけで確認なしに命令が動いた

何が起きたか

2025年12月1日に、セキュリティ企業Check Point（チェック・ポイント）の研究チーム（Isabel Mill氏、Oded Vanunu氏）が公表した欠陥で、CVE-2025-61260という番号が付いています。CVEとは、世の中に公表されたセキュリティ上の欠陥に付けられる、世界共通の管理番号です。

手口はこうです。攻撃者は、配るプログラムの中に2つのファイルを仕込んでおきます。1つは動作の設定を書いておくファイル、もう1つはCodex自身の設定ファイルです。これを置かれると、Codexは設定の読み先をそのフォルダの中に向けられてしまい、そこに書かれた内容を正式な設定として信じます。

その設定には、外部の道具とつなぐための欄があり、そこに動かしたい命令を書いておけます。被害者がそのフォルダでCodexを起動しただけで、確認の画面を一度も出さずに、その命令が動きます。Check Pointの検証では、勝手にファイルを作らせるところから、外から自由に操作できる状態にするところまで、実際に再現されました。

Check Pointは2025年8月7日にOpenAIへ報告し、OpenAIは8月20日に、文字を打ち込んで使うタイプのCodex（Codex CLI）のバージョン0.23.0で修正しました。0.23.0以降に更新していれば、この手口の影響は受けません。設定の読み先がフォルダ側に黙って切り替わることを防ぐ直し方で、Check Pointも効いていることを確認しています。

なぜ起きたか

Codexが、フォルダの中に置かれた設定ファイルを「信じてよい実行内容」として扱う作りになっていたことが原因です。二重のチェックも、使う人への確認もなく、書かれたとおりに動いていました。

設定ファイルは、人間の感覚では「動き方の好みを書いておく紙」です。ところがAIにとってはそのまま動く命令書でした。この受け取り方のずれが、フォルダを開くだけで攻撃が成立する状況を作りました。

この失敗から学べる教訓(筆者の意見)

受け取ったプログラムの中身を、人が1ファイルずつ点検してから開く。これは現実的ではありません。防ぎ方は、点検のがんばりではなく、環境の分け方に寄せるのが現実的です。

ここで効くのは、Codexをいつも最新版にしておくことと、外からもらったプログラムは本物の鍵を置いていない環境で開くことです。この事例は修正済みですが、同じ形の欠陥は姿を変えて見つかり続けています。

会社としては、開発の道具のバージョンを把握し、更新の知らせを追う担当を決めておく。そこが第一歩になります。

»出典： Check Point Research「OpenAI Codex CLI Command Injection Vulnerability (CVE-2025-61260)」(2025-12-01)

【事例④】安全なはずの囲いをすり抜けられた

何が起きたか

2026年7月20日、セキュリティ企業Pillar Security（ピラー・セキュリティ）の調査チームが「The Week of Sandbox Escapes（囲いをすり抜けた一週間）」として調査結果を公表しました。サンドボックスとは、AIが暴走しても被害が外に出ないように囲っておく、隔離された作業場のことです。

調べられたのは、Cursor、Codex、Gemini CLI、Antigravityという主な4種類のAI開発ツールです。あわせて7件の問題が見つかり、どれも同じ構造の抜け道を抱えていました。Codexで見つかった問題には「GitPwned」という名前が付いています。

Codexの問題は、安全だと決めた命令の一覧を、命令の「名前」だけで判断していた点にありました。名前は一覧に載っている安全なものでも、一緒に渡す条件しだいでは、読み取り以外のこともできてしまいます。名前を信じた結果、外から好きなプログラムを動かされる状態になりました。

OpenAIはバージョン0.95.0で直し、見つけた人に「危険度が高い」区分の報奨金を支払っています。Pillarが公表した時点では、この問題にCVE番号はまだ割り当てられていませんでした。

なぜ起きたか

Pillarは、4つのツールに共通する原因を4つに整理しています。囲いの網がパソコンの仕組みの複雑さに追いつかないこと。設定ファイルが実質的に動くプログラムであること。安全な命令の一覧が、使われ方ではなく名前を信じていること。そして、強い権限を持ったまま囲いの外で動き続けるプログラムが残っていることです。

Pillarによれば、見つかった7件はどれも囲いの仕組みそのものを壊してはいません。AIは囲いの中でおとなしくルールを守ったまま、囲いの外にいる別の道具があとで読み込むファイルを書き残していたのです。門番は完璧に仕事をしていたのに、門の内側から外へ手紙を出せた。そんな構図に近いと言えます。

この失敗から学べる教訓(筆者の意見)

この事例が示すのは、「隔離しているから安心」という前提が成り立ちにくいことです。囲いの中と外をつなぐ通り道は、道具が便利になるほど増えていきます。

現実的な対策は、道具の更新を追いかけ、影響のあるバージョンが社内で使われていないかを把握する体制を作ることです。一人ひとりがセキュリティの知らせを追い続けるのは範囲が広すぎるので、会社としてまとめて見る形が、現実的な一歩になります。

同じ調査で複数のツールが同時に指摘された点も大事です。別のツールに乗り換えれば済む話ではなく、AIに作業を任せる道具の全体に共通する課題として扱う必要があります。

»出典： Pillar Security「The Week of Sandbox Escapes」(2026-07-20)

【事例⑤】便利なCodex用の道具が1か月後に牙をむいた

何が起きたか

2026年6月1日、セキュリティ企業Aikido Security（アイキド・セキュリティ）が公表した事例です。狙われたのはCodexの弱点ではなく、Codexを使う開発者そのものでした。

「codexui-android」という部品が、Codexをスマホから操作できる便利な道具として公開されていました。開発者どうしが部品を配り合う仕組み（npm）で配られ、実際に動く道具として開発も続けられ、週に29,000回ダウンロードされるまで広がっています。

ところが公開から約1か月後、悪い仕掛けがこっそり追加されました。それ以降、この道具を起動するたびに、Codexのログイン情報が入ったファイルの中身が、攻撃者のサーバーに送られていました。送り先には、エラーを監視する有名なサービスの名前によく似た、紛らわしいアドレスが使われています。

同じ仕掛けは、Android向けの別のアプリ2つ（あわせて6万回以上のダウンロード）でも確認されました。Aikidoが公表した時点でも、この部品はまだ配られたままでした。作者は自分のアカウントが乗っ取られたと説明しています。OpenAIは、Codexのログイン情報ファイルをパスワードと同じように扱うよう、公式の案内で呼びかけています。

なぜ起きたか

この手口の要点は、最初から怪しいものを配ったのではなく、信頼を集めてから中身を入れ替えたことです。配り始めた時点では本当に無害なので、審査や確認を通り抜けられます。

背景には、Codexが広く使われるようになったこと自体があります。使う人が増えれば周りの道具も増え、その中に紛れ込む余地も広がります。人気のある店の隣に、よく似た看板の偽物の店が出るのと同じ構図です。

この失敗から学べる教訓(筆者の意見)

Codex本体をどれだけ安全に保っても、周りの道具から鍵を抜かれれば結果は同じです。しかも被害者は、その道具を入れた時点では何も間違えていません。

ここで効きそうな対策は、Codexのログイン情報ファイルをパスワードと同じ重さで扱い、仕事のパソコンに入れてよい道具を会社として管理することです。ブラウザの拡張機能と同じで、一度入れたら定期的に見直し、使っていないものは消す。この運用が効きます。

また、鍵が盗まれた前提での備えも必要です。ログイン情報を定期的に入れ替え、身に覚えのない使われ方がないか確認できる状態にしておく。これが、被害の広がりを止める現実的な手になります。

»出典： The Hacker News「OpenAI Codex Authentication Tokens Stolen in codexui-android npm Supply Chain Attack」(2026-06-01)

＼特典：最適な開発方法をご提案／

5事例に共通する「3つの落とし穴」

5つの事例は、Codex本体と、その周りの道具の両方を入口にしています。それでも、共通する形があります。

落とし穴①「AIは「読むだけのファイル」と「動かすべき命令」を区別できない」: 事例①②③に共通する本質です。仕事の説明書き、ブランチの名前、設定ファイル。どれも、攻撃者が命令を紛れ込ませる入口になりました。「怪しいファイルに気をつける」では、もともと防ぎようのない種類の問題です。

落とし穴②「便利さのための自動実行が、確認の機会をなくしている」: 事例①③④が典型です。手を止めないための工夫が、そのまま「誰も気づかないうちに動いてしまう」通り道になっています。隔離した作業場ですら、外の道具とつながる隙間から抜けられました。

落とし穴③「広まった道具は、それ自体が攻撃者の的になる」: 事例⑤が示した現実です。Codexを使う人が増えるほど、周りの道具のふりをして鍵を狙う攻撃も、割に合うようになります。本体が安全かどうかとは別の軸の危険です。

非エンジニアが明日から打つべき3つの対策

技術者任せにせず、専門の知識がなくても今すぐ始められる対策を、本当に大事な3つに絞りました。どれも「100%防げる」ものではなく、攻撃する側の手間を大きく増やし、万一のときの被害を狭めるための現実的な一手です。

【対策①】Codexを最新版に保ち、ログイン情報ファイルをパスワードと同じ扱いにする

事例③④⑤に効きます。紹介した欠陥はどれも直っていますが、古いバージョンを使い続けていれば意味がありません。更新の担当と頻度を決めておくだけで、すでに知られている攻撃の大半は通らなくなります。

あわせて、Codexのログイン情報が入ったファイルは、パスワードと同じ重さで扱います。OpenAI自身が公式の案内でそう呼びかけています。共有フォルダに置かない、バックアップに含めない。この基本を徹底することが第一歩です。お金をかけずに今日から始められる、いちばんハードルの低い対策です。

【対策②】仕事のパソコンに入れてよい道具を、会社として一覧で管理する

事例⑤の危険を抑える対策です。「使ってよい道具の一覧」を作り、新しく入れるときは社内の承認を通す。この流れを仕事の手順に組み込みます。

大事なのは、入れた時点で安全でも、あとから悪いものに変わりうる点です。ブラウザの拡張機能と同じで、一度入れたら定期的に見直し、使っていないものは消す運用にします。

【対策③】社外から受け取ったプログラムは、本物の鍵がない環境で開く

事例①②③に効く対策です。委託先や外部から受け取ったプログラムを、本物のクラウドの鍵やGitHubの鍵が入ったふだん使いのパソコンで、そのまま開かせるのをやめます。

調べる用のパソコンやアカウントを分けるだけでも、万一命令が紛れ込んでいたときに持ち出される範囲をぐっと狭められます。あわせて、開発で使う合鍵の権限をできるだけ狭くし、期限を短くしておくと、被害の広がりを抑えられます。準備には手間がかかりますが、開発者の鍵をまとめて失う危険を減らせます。

»出典： Pillar Security「The Week of Sandbox Escapes」(2026-07-20)

まとめ｜「使わない」ではなく「安全に使い倒す」へ

Codexを使うか使わないかは、もう論点ではありません。セキュリティ企業が横断調査の対象に選ぶほど、企業の開発現場に定着しています。危ないからと避ける判断は、競合に差をつけられる経営判断になりかねません。

残る論点は、更新・環境の分け方・周りの道具の管理を、誰がいつ決めるかです。ここを決めないまま使い始めた組織が、本記事の5つの事例と同じ入口に立っています。

Walkersでは、AIに開発を任せる形での新しいサービス作りと、社内でAIの開発ツールを安全に使うためのルール作り・定着までを、まとめて提供しています。「自社はどこから手を付けるべきか」がはっきりする初回相談を、無料でご用意しています。開発の知識がない経営者・意思決定者の方でも問題ありません。

Walkersに無料で相談する＞＞