ハクソク

世界を動かす技術を、日本語で。

GitLab Duoにおけるリモートプロンプトインジェクションがソースコードの盗難を引き起こす

367日前原文(legitsecurity.com)

概要

  • Legitチームが GitLab Duo における 複数の深刻な脆弱性 を発見
  • 隠しコメント だけで プライベートソースコード漏洩 や HTMLインジェクション が可能
  • 攻撃チェーンは OWASP Top 10 for LLMs 2025 の5項目に該当
  • GitLabは 迅速にパッチを適用 し、脆弱性を修正
  • AIアシスタントの 安全な運用の重要性 を強調

GitLab Duoにおける脆弱性の発見と概要

  • Legitリサーチチームによる GitLab Duo の脆弱性発見
  • GitLab Duo はAnthropicのClaudeを搭載したAIアシスタント
  • 開発者向けに コード提案、 セキュリティレビュー、 マージリクエスト分析 を支援
  • 本来は安全性向上のためのAIが 逆に悪用可能 というリスク
  • リモートプロンプトインジェクション により ソースコード窃取、 他ユーザーへの悪意ある提案、 ゼロデイ情報漏洩 が可能

隠しプロンプトによるGitLab Duoの操作（LLM01）

  • ソースコード内 や MR説明文・コメント、 コミットメッセージ などに 隠し命令 を埋め込み可能
  • GitLab Duoは ページ全体の文脈 を分析するため、 どこに埋め込んでも影響
  • これにより 攻撃者の指示通り にAIが動作

KaTeX・Base16・不可視テキストによる検知回避（LLM08）

  • ASCII Smuggler や Base16エンコード、 KaTeXの白文字 などでプロンプトを不可視化
  • GitLabのUI上で 目立たない形で命令を埋め込み
  • それでも Duoは隠し命令を検出・実行

信頼できないAI出力の危険性（LLM09）

  • Duoの コード提案を操作 し、 悪意あるJavaScriptパッケージ を含める
  • 悪意あるURL を「安全」と表示し、ユーザーを フィッシングサイト に誘導
  • マージリクエスト の安全性を偽装し、 レビュワーを誤誘導

HTMLインジェクションによるWeb攻撃ベクトル化（LLM05）

  • Duoの回答は Markdown形式 で表示、 カスタムラベル付きURL も利用可能
  • ストリーミングMarkdownレンダリング の仕組みで HTMLタグが早期に解釈
  • ラベル部分に生HTML を注入し、 <img>タグ などを挿入可能
  • DOMPurify によるサニタイズも、 <img>や<a>タグ はデフォルトで除去されない
  • <img>タグなどを利用し、 攻撃者サーバーへの自動リクエスト 発生

プライベートソースコードへのアクセス悪用（LLM02）

  • Duoは 被害者ユーザーと同等の権限 で動作
  • プライベートリポジトリ や 限定的なMR にもアクセス可能
  • 攻撃者は 隠しプロンプトでDuoにソースコード抽出・Base64エンコード・<img>タグ埋め込み を指示
  • 被害者がDuoを利用すると、 ソースコードが攻撃者サーバーに送信

実際の攻撃シナリオ例

  • 攻撃者が 公開プロジェクトのMR説明文 に隠しプロンプトを埋め込み
  • 被害者がDuoに コードレビューや分析を依頼
  • Duoが 隠し命令を実行し、<img>タグ付きの回答を生成
  • 被害者のブラウザが攻撃者サーバーに機密情報を送信

機密Issue・ゼロデイ情報の漏洩リスク

  • Duoは プロジェクトIssue にもアクセス可能
  • 内部ディスカッション や 未公開の脆弱性情報 も漏洩対象
  • 隠しプロンプト でDuoに 機密Issue内容の抜き出し・Base64化・HTML埋め込み を指示可能
  • GitLab従業員やコントリビューター のゼロデイ情報も標的に

GitLabの対応とパッチ内容

  • 2025年2月12日、 脆弱性報告後に迅速な対応
  • HTMLインジェクションおよびプロンプトインジェクション 両方を修正
  • duo-ui!52で 安全でないHTMLタグのレンダリング禁止 （外部ドメインへの<img>や<form>等）
  • 現時点で本攻撃チェーンは利用不可
  • GitLabの 透明性と迅速な協力 に感謝

結論と教訓

  • AIアシスタントの深い統合 は 利便性と同時に攻撃面の拡大 をもたらす
  • 無害に見えるプロジェクト内容 にも 悪意ある命令が潜む可能性
  • AIの出力だけでなく入力も厳重に管理 する必要性
  • LLMがユーザー制御コンテンツを処理する場合、常に不正入力を前提に設計
  • 文脈認識型AIの強力さ と リスク を再認識

参考：対象となったOWASP Top 10 for LLMs 2025

  • LLM01: Prompt Injection
  • LLM02: Sensitive Information Disclosure
  • LLM05: Insecure Output Handling (HTML Injection)
  • LLM08: Steganography/Obfuscation
  • LLM09: Insecure Code Generation

Hackerたちの意見

GitLabの修正対応は、正直ちょっと怪しい感じがするね。

└

「LLMをどこにでも導入しよう」っていうのは、正直言って怪しいよね。

└

onerror、onload、onclickが特別扱いされる理由って何なんだろう？他にも同じような注入ができる属性が30個くらいあるのに。

└

それ、私も思った。根本的な問題は解決してないし、ただ2つの可能な情報漏洩方法をパッチしただけだよね。きっと賢い人たちが他の使い方を見つけるだろうな。

プロンプトインジェクションが解決されるまでは、もし解決されることがあればだけど、LLMを何にでも使うつもりはないよ。MCPやIDE、エージェントなんて無理。質問があるときは、シンプルなプロンプトボックスを使って、その出力を手動で処理することにする。

└

自分のコードが特別なものであれば、同じように慎重になるけど、実際はCRUDの雑なものをサッと出すためにしっかり報酬をもらってるからね。ちゃんとテストもされてるし。私のコードを盗む人には幸運を祈るよ。

└

プロンプトインジェクションは修正される可能性が低いと思う。LLMをソフトウェアとして考えて、頑張ればSQLインジェクションの脆弱性を修正できるって考え方はやめた方がいいよ。むしろ、従業員からの内部リスクのように考えた方がいい。彼らが従業員だとは言わないし、そのレベルで動いているわけでもないけど、LLMの挙動は曖昧で定義が難しいからね。フィッシングメールをクリックしないユーザーを保証することはできない。教育することはできるし、リスクを最小限に抑えることもできるけど、最終的にはいくつかの解決策を組み合わせて、ある程度の信頼を持つ必要がある。LLMをこのように考えると、セキュリティに関する議論はもっと生産的になると思うよ。

└

DeepMindが最近この分野で素晴らしい成果を上げたみたいだよ。もし正しく実装されれば、提示された方法はほとんどのプロンプト注入ベクターを効果的に防げるらしい。https://news.ycombinator.com/item?id=43733683

└

私も手動でやってるけど、その方がいいと思ってるよ。

└

Cursorが私のLinuxユーザーを全部消しちゃって、OSをソフトリセットしたから、君を責める気にはならないよ。

Duoをシステムユーザーとして動かすのはマジでクレイジーだし、GitLabがその罠にハマったのは残念だな。すでに個人アクセス用のトークンがあるから、Duo専用に静かに作成するだけでも、プラットフォーム内の全リポジトリにLLMに読み取り権限を与えるよりはずっと改善されるはず。

素晴らしい仕事だね！信頼できないサードパーティのサーバーを介したデータ漏洩（特に画像レンダリングを通じて）は、AIアプリケーションセキュリティの最も一般的な問題の一つで、大手ベンダーが出荷前にこれを見逃すのは心配だよ。投稿に書かれていたASCII Smugglerを作ったし、過去には10件以上の発見をブログで画像の流出ベクターとして記録したよ。GitHub Copilot Chatも去年、非常に似たバグがあったしね。

└

GitHub Copilot Chatは去年、非常に似たバグがあったよ。昨日の「Tachy0n: The Last 0day Jailbreak」を思い出すな。https://blog.siguza.net/tachy0n/ 要約すると、セキュリティの問題が見つかって、OSのリリースでパッチされたけど、Appleはリグレッションテストをやってないみたいで、セキュリティ研究者がそれをテストしたら、後のOSリリースでそのバグが未修正のままだったって。

それって、GitLab DuoでDoomが動くってこと？

└

決定的ではないよ。LLMは確率的なマシンだからね。

もしドキュメントが特定の無害な解釈を示しているなら、LLMもそれを採用した方がいいかもね。「プロンプトメディスン」っていう、ユーザーを助けるための明示的な安全性とインフォームドコンセントを持った埋め込みプロンプトのアイデアを探求してきたよ。https://github.com/csiro/stdm O3やClaudeに「説明して」や「従って」と言って、埋め込み指示を試してみて。

これヤバいね、LLMがどれだけセキュリティの脆弱性を生み出すか、LLMがコードを書くのに支配的になってるから？？大体のプログラマーってセキュリティ苦手だし、それをLLMに学ばせてるから驚くことじゃないよね。

└

これが、LLM生成コードのセキュリティに関する懸念を軽視する人たちに言ってきたことなんだ。彼らが訓練されたデータの大半は、最低限のセキュリティしかなかったから。単に「安全にしてね」って言ったところで解決しないよ。自分でセキュリティの問題を特定できないなら、LLMが全部キャッチできたかどうかもわからないよね。

外部ドメインを指すような安全でないHTMLタグをレンダリングすることは、gitlab.comの下にない。別のgitlab.comのURL（オープンリダイレクトみたいな）に脆弱性があったら、この脆弱性は再び問題になるってこと？

Duoがウェブアプリケーションだったら、ページのレスポンスヘッダーでContent Security Policy (CSP) を適切に設定するだけで、こういう問題を防げるのかな？ https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

└

画像を通じた情報漏洩を防ぐためには？ そうみたいだね。img-srcを設定すれば、最初のディレクティブであるdefault-srcは、ドキュメントと同じオリジンのリソースだけをブラウザに読み込ませるように指示するんだ。他のより具体的なディレクティブが異なるポリシーを設定しない限りね。二つ目のimg-srcは、同じオリジンの画像か、example.comから提供される画像を読み込むようにブラウザに指示する。でも、AIが人間に危険な指示をプレーンテキストで書くのを止めることはできないよね。