AI で書いたハニーポット：Vibe Coding がもたらす脆弱性のケース・スタディとは？

What an AI-Written Honeypot Taught Us About Trusting Machines

2026/01/23 BleepingComputer — AI モデルを用いてコード作成を支援する Vibe Coding 手法が、多くのチームにとって日常的な開発プロセスの一部となっている。それにより、大きな時間短縮効果がもたらされるが、その一方では、AI が生成したコードを過度に信頼してしまうことで、セキュリティ脆弱性が入り込む余地を生み出す。AI 生成コードがセキュリティに及ぼす影響について、Intruder の経験は現実のケース・スタディとなっている。以下に示すのは、実際に起こったこと、そして、他の組織が注意すべき点である。

AI にハニーポット構築を手伝わせたとき

Rapid Response サービスを提供する同社は、初期段階の攻撃試行を収集する目的でハニーポットを構築している。そのうちの一つにおいて、要件に完全に合致するオープンソースの選択肢が見つからなかったことで、近年多くのチームが行っているのと同様に、AI を用いることで PoC エクスプロイト・コードの作成を支援させた。

それは、意図的に脆弱なインフラとして隔離環境にデプロイされたが、展開前には簡単なサニティ・チェックも実施していた。

デプロイから数週間が経ったころに、ログに奇妙な兆候が現れ始めた。本来は攻撃者の IP アドレスを名前とするディレクトリに保存されるはずのファイルが、ペイロード文字列としてディレクトリ名を持っていたのである。それが明確に示すのは、ユーザー入力が意図しない箇所に、問題が入り込んでいることである。

想定していなかった脆弱性

コードを詳しく調査した結果、原因が判明した。AI が、クライアントから送信された IP ヘッダを取得し、それを訪問者の IP アドレスとして扱うロジックを追加していたのである。

上記の処理が安全であるのは、自ら管理するプロキシからヘッダが送られてくる場合に限られる。それ以外のケースでは、ヘッダは実質的にクライアントの制御下にある。

つまり訪問者は、IP アドレスを容易に偽装することで、ヘッダを用いてペイロードを注入できることになる。この種の脆弱性は、ペンテストで頻繁に発見されるものである。

今回のケースでは、攻撃者はヘッダ内にペイロードを単に埋め込んでおり、それが異常なディレクトリ名の原因だった。その影響は小さく、完全なエクスプロイト・チェーンの兆候もなかったが、攻撃者がプログラムの挙動に一定の影響を与えられる状態であった。

ただし、さらに悪化していた可能性もある。もし、IP アドレスを別の用途で使用していたならば、同じミスが容易にローカル・ファイル・ディスクロージャや、サーバサイド・リクエスト・フォージェリにつながっていた可能性がある。

SAST が見逃した理由

一連のコードに対して Semgrep OSS と Gosec を実行したが、どちらもこの脆弱性を検出しなかった。Semgrep はいくつか無関係な改善点を指摘したが、これはツールの失敗ではなく、静的解析の限界である。

この欠陥を検出するには、クライアント提供の IP ヘッダが検証なしで使用されていること、そして、信頼境界が設定されていないことを理解する、文脈的な判断が必要となる。人間のペンテスターにとっては明白であるが、AI 生成コードに過度な信頼を置いたレビューでは、容易に見落とされるニュアンスである。

AI 自動化による油断

航空分野で広く知られる考え方として、手動で作業するよりも自動化を監視する方が、多くの認知負荷を要するというものがある。今回も同様の現象が見られた。

このコードは、厳密な意味で “自分たちが書いたもの” ではないため、内部での動作方式に対するメンタル・モデルが弱くなり、レビューの質が低下した。

ただし、航空分野との比較は、ここまでである。オートパイロット・システムには数十年分の安全工学が蓄積されているが、航空機のように検証されてきた安全基準が存在しない。したがって、現時点ではマージン (安全余裕) に頼ることはできない。

孤立した事例ではなかった

AI が自信満々に生成した安全でない事例は、これだけではない。Gemini 推論モデルを用いて AWS 向けのカスタム IAM ロールを生成した際にも、権限昇格が可能な設定が作られていた。その問題を指摘すると、モデルは同意したが、その後も脆弱なロールを生成し続けた。

安全なコンフィグに到達するまでに 4 回の反復が必要だったが、その間において、モデルが自律的にセキュリティ問題を認識することは一度もなかった。つまり、人間による誘導が常に必要だった。

経験豊富なエンジニアであれば、これらの問題を容易に発見できる。その一方で、セキュリティの背景を持たない人々でも、AI 支援開発ツールによりコードの生成が可能になっている。最近の研究では、こうしたプラットフォームにより、数千件の脆弱性が紛れ込んでいることが示されている。

そして、今回のケース・スタディが示すように、AI モデルが生成した “正しく動作するように見える自信ありげなコード” により、熟練した開発者やセキュリティ専門家であっても欠陥を見逃す可能性が生じている。エンドユーザーにとって、利用しているソフトウェアに AI 生成コードが含まれているかどうかを見分ける手段はない。言うまでもなく、責任はコードを出荷する組織の側にある。

AI を使用するチームへの教訓

最低限のラインとして、非開発者や非セキュリティ担当者が、AI にコード作成を任せることは推奨されない。

専門家による利用を、組織が許可する場合であっても、コードレビュー・プロセスや CI/CD における検知能力を見直し、この種の新しい問題がすり抜けないようにすべきだ。

AI により導入される脆弱性は、今後さらに一般的になると考えられる。

AI 利用が原因で発生した問題を、公に認める組織はほとんどない。したがって、報告されている以上に、実際の規模が大きい可能性が高い。今回の事例は、決して例外的なケースではなく、また、最後になることもないだろう。

Intruder の事例では、AI が作成したハニーポットのコードに、外部から送信される IP ヘッダを検証なしで受け入れてしまう致命的なミスが紛れ込んでいました。これにより、攻撃者はヘッダに悪意のある文字列を紛れ込ませるだけで、システムの動作を操作できる状態になっていました。驚くべきことに、この脆弱性は一般的な静的解析ツール (SAST) では検出できませんでした。これらのツールには、外部からのデータがどこへ流れ、どこで危険になるかという、コンテキストを理解する能力が不足しているためです。

今回の事例から得られる教訓は、AIが生成した正しく動いているように見えるコードほど、人間による厳格なレビューが必要だということです。特にセキュリティの専門知識を持たない人が、AI にコードを丸投げして出荷することは、組織にとって極めて高いリスクとなります。AI は、あくまで強力な助手であり、最終的な安全性の責任は、常に人間が負わなければなりません。よろしければ、Vibe Coding での検索結果も、ご参照ください。