🦆
Rules File Backdoor について調べてみる

2025/03/24に公開
 なぜ作成したのか自社でもGitHub Copilot、Curesor使い始めたところなので、転ばぬ先の杖というやつです

 AIコード補助ツールに対する「Rules File Backdoor」攻撃の詳細調査
 はじめに近年、GitHub CopilotやCursorといったAIコード補助ツールが開発現場で広く利用されています。それに伴い、新たな供給網（サプライチェーン）攻撃として注目されるのが「Rules File Backdoor」と呼ばれる手法です。
これは、CursorやGitHub Copilotが参照するルールファイル（AIの動作方針やコーディング規約を定めた設定ファイル）に、一見無害に見える形で隠された悪意ある指示を埋め込み、AIが生成するコードにひそかに不正なコード片（バックドアや脆弱性）を仕込ませるものです[1][2]。
攻撃者はゼロ幅スペースや双方向制御文字など人間には見えない特殊文字を利用して指示を隠ぺいし、AIの文脈理解を悪用して開発者に気付かれないままマルウェアを埋め込むことが可能になります。
この攻撃により、開発者の「頼れるアシスタント」であるAIツール自体が “気付かぬ共犯者” となり、生成コードを通じてプロジェクト内に脆弱性が伝播する深刻なリスクが生じます。

 1. 攻撃の具体例とPoC（実証コード）Rules File Backdoor攻撃は、ソフトウェア開発プロジェクト内に存在するルールファイルを悪用してAIの挙動を不正に操作し、生成されるコードにバックドアを仕込む手法です。以下に、この攻撃の典型的なシナリオとPoC（概念実証）の具体例を示します。

攻撃対象:
開発プロジェクトに含まれるAI用のルールファイル（コーディング規約やベストプラクティスを記述した設定ファイル）。
例としてCursorではプロジェクト内の.cursor/rules/ディレクトリに配置されたテキストファイルが該当します [3]。

攻撃者の準備:
攻撃者は、見た目は無害なルール定義の中に巧妙なプロンプト（指示文）を仕込みます。この指示文にはゼロ幅ジョイナーや双方向テキストマーカーなどの不可視のUnicode文字を埋め込むことで、人間のレビューでは検出困難にします。また、AIの内容フィルタを迂回するためにシナリオ風の文章で包み込む 「ジェイルブレイク」的テクニック （例：「セキュリティ要件としてこの操作が必要」という物語調の説明）を用い、さらに 「生成コードの変更点を回答に含めるな」 という指示を潜ませて、AIが開発者に余計な情報を漏らさないよう細工します。
ルールファイルの例（概略）:
攻撃者が用意したルールファイルは、一見するとプロジェクトのコーディング規約やベストプラクティスを記述した単なるテキストです。
しかし、その中に例えば以下のような隠し命令が含まれています:
上記は概略イメージですが、このように 「特定の外部スクリプトを挿入せよ」「ただしそれを開発者に告知するな」 といった命令をルールファイル内に埋め込むことが可能です。
攻撃者はこのファイル名や内容を「HTMLのベストプラクティス」「セキュリティ強化ルール」と偽装し、オープンソースコミュニティやフォーラムで共有したり、あるいは著名なプロジェクトへのプルリクエスト経由で忍び込ませたりします。
PoCシナリオ:
Pillar Securityの研究者はこの攻撃を実証するため、Cursor環境で以下のデモを行いました。

Step 1
まず、上述のような悪意あるルールファイルを.cursor/rulesに配置します。


Step 2
次に、開発者がAIに「シンプルなHTMLページを作成して」と指示（プロンプト）する。


Step 3
AIは通常のHTML構造を生成するだけでなく、ルールファイルの隠し命令に従って攻撃者サイトからのスクリプト読み込みタグを密かにHTMLに追加しました。


驚くべきことに、AIアシスタントはこの追加を開発者への応答メッセージには一切表示しませんでした。
つまり、チャット画面上やコミットログ上には不審な変更が残らず、生成されたHTMLファイルの中だけにこっそりと悪意ある<script>タグが埋め込まれたのです。
このスクリプトは外部の攻撃者サーバからマルウェアを読み込むものであり、開発者がコードを十分精査せずに受け入れてしまうと、バックドア付きのコードがプロジェクトに取り込まれてしまいます。
図1: 攻撃者が共有した悪意あるルールファイルによりAIコード補助ツールがバックドア付きコードを出力する流れ。(Piller記事より)
攻撃者(A)は隠れた指示を含むルールファイル（例: Rulesfile.mdc）を作成しOSSコミュニティ等へ提供します。
開発者(B)がそれを自プロジェクトに取り込み（信頼してルールファイルを配置）、AIコーディング支援ツールを使って開発を進めると、AIエージェント(C)はそのルールファイルを参照しコード生成に反映します。
その結果、表面的には正当なコードの中に攻撃ペイロード（不正スクリプト等）が混入された出力(D)が得られます。
この一連のプロセスは開発者のレビューをすり抜け、静かにプロジェクト内へ悪意あるコードを拡散させます。
攻撃の意図は、開発者の目を盗んで脆弱なコードやバックドアを組み込むことにあります。具体的な悪影響の例として、以下のようなケースが想定されています：

セキュリティ制御の無効化: ルールファイル中の指示でAIが安全設定やチェックを意図的に外したコードを生成する（例：デフォルトの認証や検証処理をバイパスする実装に書き換える）。

脆弱な実装の挿入: 古い暗号アルゴリズムの使用を「推奨」するルールを仕込み、AIに安全でないアルゴリズムや乱数生成を使わせる。あるいは、バックドア用のパスワードチェックを挿入する（常に特定のマスターキーで通過してしまう認証など）。

データ漏洩の仕込み: 一見「デバッグ目的のログ出力を入れる」という指示になっているが、実際には環境変数や機密情報を外部に送信するコードを追加させる。例えば「デバッグのベストプラクティスに従う」と銘打ったルールが隠れてAPIキーやユーザーデータを収集・送信する処理を忍ばせる可能性があります。

持続的なバックドア: 一度このようなルールファイルをプロジェクトに組み込んでしまうと、その後の全てのAI支援コード生成に影響を与え続けます。プロジェクトをフォークした場合でも設定が引き継がれるため、派生プロジェクトや下流の利用者にも継続的にバックドアが伝播しかねません。
このように、Rules File Backdoor攻撃のPoCでは、AIコード補助ツールが如何に容易く騙されて 「見えない指示」に従ってしまうか が示されました。
実際のデモ動画も公開されており、Cursor環境およびGitHub Copilot環境の双方で、ルールファイルを通じてAI生成コードが不正に改変される様子が確認されています。
開発者がAIからの提案を無批判に受け入れてしまうと、知らぬ間に攻撃者の意図した脆弱性を自分のコードに取り込んでしまう危険性が明らかになったのです。

 2. 影響を受けるツールと脆弱性の位置付け「Rules File Backdoor」攻撃の影響範囲は、主にGitHub CopilotとCursorという代表的なAIコード補助ツールで指摘されていますが、同様の仕組みを持つ他のツールやエコシステムにも波及し得ると考えられます。
GitHub Copilot:
マイクロソフトとOpenAIが提供する広く普及したAIコーディング支援ツールです。
Copilot自体にはCursorのような明示的な「ルールファイル」機能は公表されていませんが、開いているファイルやプロジェクト内のコンテキストをもとにコード提案を行います。
そのため、リポジトリ内に含まれる設定ファイルやコメント、ドキュメントの内容次第で提案が変化します。攻撃者が巧妙に細工したコメントや設定をリポジトリに含めることができれば、Copilotもそれを学習コンテキストとして取り込み、結果的に有害なコードスニペットを提案する可能性があります。
実際、Pillar SecurityはGitHub Copilot上でもCursorの場合と同様の攻撃フローが成立することをデモで示しています。
つまり、Copilot利用者もこの攻撃の潜在的な標的となります。
Cursor:
新興のAIコードエディタで、「Rules for AI」と呼ばれる独自機能によりプロジェクト固有のルールファイルを定義できます [3:1]。
開発者は自分のプロジェクトに合わせたコーディング規約や設計指針を.cursor/rules/以下に記述し、CursorのAIに守らせることができます。
しかし、この利便性が裏目に出ており、Cursorはルールファイルの内容を信頼してそのままAIに与えるため、悪意ある指示も無検証で実行されてしまいます。
Pillar Securityの報告では、この脆弱性によってCursor利用者がバックドア付きコードを生成させられる危険性が指摘されました。
Cursor開発チームも本件の報告を受けましたが、「これはユーザー側の責任範囲であり、我々のプロダクトの脆弱性ではない」との立場を示しています。
その他のエコシステム:
上記以外にも、AIを用いたコード支援機能を持つツール全般が潜在的に影響を受けます。
例えば、Visual Studio Code拡張やJetBrains系IDEのAI補完プラグイン、さらにはAmazon CodeWhispererやAlibabaのCode Copilotのような類似サービスも、プロジェクトコンテキストから推論する仕組みがあれば同様のリスクがあります。
Pillar Securityはこの攻撃を「クロスエージェントな脆弱性」と位置付け、特定の製品固有ではなくAIコードアシスタント全般に通じる設計上の問題だと指摘しています。
要は、**「AIが参照するあらゆる外部データ（ルール設定やコメント等）を信用しすぎている」**ことが根本原因であり、これを突く攻撃は今後他のAIツールにも応用される可能性があります。
脆弱性の位置付けとしては、従来のソフトウェア脆弱性のようにバッファオーバーフローやSQLインジェクションといった技術的欠陥ではなく、**AIシステムの設計上の穴（プロンプトインジェクションの一種）**です。
ソフトウェア開発ライフサイクルにAIが深く組み込まれた結果生まれた新しい攻撃面であり、ソフトウェア供給網全体に影響を及ぼし得る点で非常に厄介です[4]。
攻撃者はコードそのものではなくAIの挙動を武器化するため、従来型のセキュリティレビューやテストでは検知されにくいという特徴があります。
さらに問題を大きくしているのが、ルールファイルが共有・再利用されやすいという現状です。
多くの開発チームやOSSコミュニティでは、有用なルールセットやテンプレートを互いに共有し合う文化があります。例えば、「良く整理されたTypeScriptプロジェクトのルール集」や「セキュアコーディングのベストプラクティス集」といったファイルがインターネット上で流通しています。
攻撃者にとってこれは絶好の機会であり、そのような公共ルールカタログに毒入りのルールを紛れ込ませれば、多数の開発者がそれをダウンロードしてプロジェクトに含めてくれる可能性があります。
一度人気リポジトリのテンプレートに混入すれば、フォークやコピーを通じて広範囲にバックドアが伝播し、サプライチェーン攻撃として大きな被害を与えかねません。
最後に、ベンダー側（Copilot運営元のGitHubやCursor開発元）の対応について触れておきます。
前述の通り、**GitHubおよびCursorは本件を「脆弱性ではなくユーザー側の問題」**と位置付けています。
GitHubは「Copilotが出力するコード提案をレビュー・採択する責任はユーザーにある」と回答し、Cursorも「ルールファイルの内容はユーザー管理下のもので当社の責任範囲外」という立場を取りました。
つまり現時点で製品側にセキュリティ修正は加えられておらず、利用者自身で対策を講じる必要があるというのが現状です。この点も本攻撃の厄介さを物語っています。

 3. 防御策と検出方法Rules File Backdoor攻撃への防御には、開発者・組織側でのセキュリティ意識向上とチェック体制の強化が欠かせません。以下に、専門家が提案する具体的な対策と検出アプローチをまとめます。
ルールファイルの監査と可視化:
まず、自社プロジェクト内に既に存在するルールファイル（または類似の設定ファイル）を洗い出し、その内容を精査します 。
特に、ゼロ幅スペースやBidirectional文字など不可視のUnicode文字が含まれていないかチェックすることが重要です。
一般のテキストエディタやGitのWebインタフェースではこれらの文字が表示されないため、専用のツールやエディタ設定で不可視文字を強調表示させると良いでしょう。
例えば、VS Codeでは設定で不可視文字（Whitespaceや制御文字）を表示できますし、オンラインのUnicode可視化ツールを使ってテキスト中の見えない文字を検出することもできます。
実際、Pillarの調査ではGitHub上のプルリクエスト画面でもゼロ幅文字が表示されずレビュアーが気付けないことが確認されています。
そのため、信頼できる方法でファイルの生データを確認し、怪しい制御文字や不自然な文章が無いか確認してください。
ルールファイルのセキュリティレビュー:
ルールファイルも通常のコードと同様にレビューと承認プロセスを設けましょう。
開発チーム内で誰かが外部から新しいルールセットを持ち込む場合、少なくとも二人以上の目で内容をチェックし、意味を理解できない指示や過剰に包括的な指示が含まれていないか確認すべきです。
攻撃者は都合の悪い指示を巧妙に隠すため、文章の不自然な断絶や文脈に合わない挿入がないか注意深く読む必要があります。
また、ルールファイル中のコメントや説明文であっても、AIにとっては有効な指示となり得ることを念頭に置き、「コメントだから無害」と決めつけないようにします。
信頼されたルールのみを使用:
可能な限り、ルールファイルは自分たちで作成したものか、十分に信頼できるソース（公式ドキュメントや実績ある団体）から入手したものに限定します。
オープンコミュニティから取得した便利そうなルール集については、上記の監査を徹底するか、必要最低限の部分だけを自前で実装し直す方が安全です。
また、プロジェクトの依存関係に含まれるテンプレートやスキャフォールディング（足場）にも注意を払い、それらに同梱されたルールファイルを見逃さないようにします。
検出ツールの活用:
大規模なコードベースでは人手で全てのファイルを確認するのは困難です。
そこで、自動検出ツールの導入を検討します。例えば、CI（継続的インテグレーション）パイプラインにスクリプトを組み込み、リポジトリ内のファイルに怪しいUnicode制御文字（UTF-8ではない不審なバイトシーケンス）が含まれていればビルドを失敗させる、といった対策が考えられます。
また、コミットフックで特定のキーワード（例えば「do not mention」や「秘密」など、隠し指示に典型的なフレーズ）を検知する仕組みも有効かもしれません。
既知の類似攻撃としてTrojan Source攻撃（ソースコード中の双方向制御文字による視覚的詐欺）がありますが、これに対応するための静的解析ツールやエディタ拡張機能が公開されています。
そうしたツール（例：Invisible Character DetectorやGitのsecret-scanningの拡張設定など）をルールファイルや設定ファイルにも適用することで、隠れた指示の混入を機械的に洗い出すことができます。
AI生成コードのレビュー強化:
ルールファイルの検査と並行して、AIが出力したコード自体のレビュー体制も強化すべきです。
具体的には、AI提案コードに普段見慣れない外部リソース参照（突然追加されたCDNや外部スクリプト）、不自然な乱数種やハードコードされた定数、用途不明なロギングや通信処理が含まれていないかをチェックします。
特に、プロンプトに要求していない機能が紛れ込んでいる場合は注意信号です。
開発者がAI生成物を鵜呑みにせず、必ず人間の目でセキュリティ観点からレビューする習慣を持つことが最後の防波堤となります。
これはベンダー各社が「ユーザーの責任範囲」として強調している点でもあります。
以上の対策により、「Rules File Backdoor」のリスクを低減できます。
要するに、AI自身を信頼しすぎないこと、そしてAIに影響を与える外部ファイルを信頼しすぎないことが肝要です。
AIコーディング支援ツールの便利さゆえに、開発者は提案コードを深く検証せず受け入れてしまう**オートメーション・バイアス（自動化偏重）**に陥りがちです。
しかし、AI時代のソフトウェア開発では従来になかった攻撃手法が登場しているため、我々はセキュリティモデルをアップデートし、AIが新たな攻撃経路になり得ることを念頭に置いて防御策を講じる必要があります。
企業や組織は、自社の開発プロセスにAIが組み込まれている場合、そのAIを含めた開発パイプライン全体を包括的に守る戦略を検討すべきでしょう。
新たな脅威に対抗するため、開発者一人ひとりが注意を払い、組織としても検出・対処の仕組みを整えることが重要です。

 参考資料本報告書の内容は、Pillar Security社の技術レポート (New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents) やThe Hacker Newsによる解説記事 (New 'Rules File Backdoor' Attack Lets Hackers Inject Malicious Code via AI Code Editors)などに基づいており、実際のPoCデモや推奨対策の詳細についてはこれらの情報源も参照してください。
今回取り上げた「Rules File Backdoor」は、OWASPの提唱するAIセキュリティのカテゴリ（例えばAAI-003: エージェントの指示操作やAAI-006: エージェントの文脈改ざん にも合致する、新種のリスクです。今後もAIと開発の融合が進む中で、このような攻撃手法への警戒と対策は避けて通れない課題となるでしょう。

 所感CURSORのRuleの扱いについては社内でもちょっと議論になったけれど、一旦自由に使わせよう、という方針になった。
自由にやらせるのは探索的なアプローチには良いものの、生産性はトレードオフになる印象。
セキュリティリスクもあるなら最低限のガイドラインは必要かも

脚注
https://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agents ↩︎
https://thehackernews.com/2025/03/new-rules-file-backdoor-attack-lets.html ↩︎
https://docs.cursor.com/context/rules-for-ai ↩︎ ↩︎
https://securityaffairs.com/175593/hacking/rules-file-backdoor-ai-code-editors-silent-supply-chain-attacks.html ↩︎
GitHubで編集を提案
なぜ作成したのか

AIコード補助ツールに対する「Rules File Backdoor」攻撃の詳細調査

はじめに

1. 攻撃の具体例とPoC（実証コード）

2. 影響を受けるツールと脆弱性の位置付け

3. 防御策と検出方法

参考資料

所感

Discussion
