この記事のポイント
- 脆弱性
- CVE-2026-117558
- 深刻度
HIGH8.5
- 対象
- ai-sdlc plugin MCP Server 0.31.2以下(@ai-sdlc/plugin-mcp-server)
- 悪用状況
- 不明
- 推奨対応
- 0.31.2以下を使用している場合は修正コミット717d7ecを含む配布版へ更新し、更新まで対象ツールを停止します。利用済み環境ではツール引数、子プロセス、外向き通信、GitHub CLI資格情報の利用を調査します。
- 公表日
目次
AI支援開発の手順をツールとして提供するai-sdlc plugin MCP Serverに、の-2026-117558が公表されました。影響するのは0.31.2以下です。MCPのcheck_issueまたはcheck_pr_statusを使い、やクライアントからrepo引数を受け取る構成は、配布版と修正コミットの取り込み状況を優先して確認してください。
この問題は、インターネットからなしでMCPサーバーへ直接侵入する脆弱性ではありません。開発元は、利用者自身のローカルセッションでMCPツール引数を操作できることが前提であり、間接、侵害されたエージェント、悪意あるMCPクライアントなどが入口になると説明しています。ただし成立すると、MCPサーバーを実行するユーザー権限で任意コマンドを実行でき、、環境変数、鍵、GitHub の認証状態まで影響し得ます。
本稿は2026年10月28日にCVE公式レコード、開発元Issue、修正PR、リリースを確認したニュース解説です。攻撃コードの再現ではなく、影響条件、更新先の確かめ方、更新までの実行制御、更新後の検証と初動調査を整理します。
スポンサーリンク
repo引数がシェルの一部として解釈された
問題のある実装では、GitHubのIssueやPull Requestを取得するためにgh issue viewまたはgh pr viewを呼び出していました。その際、呼び出し元から渡されたrepo文字列をコマンド文字列へ連結し、Node.jsのexecSync()で実行していました。repoは任意の文字列として受け付けられ、所有者名とリポジトリ名の形式検証も、シェル用の無害化もありませんでした。
この組み合わせでは、区切り文字やコマンド展開として解釈される文字列がrepoへ混ざると、本来のghコマンドとは別の処理が動く可能性があります。Issue番号とPR番号は数値型で検査されていたため、開発元の報告が特定した入口はrepoです。ツール名を許可していることや、引数がとして正しいことだけでは、OSコマンドの境界は守れません。
修正PR #1982では、文字列をシェルへ渡す方式を廃止し、execFileSync('gh', args)のように実行ファイルと引数配列を分離しました。加えてrepoをowner/name形式へ制限し、シェル記号を含む入力では子プロセスを起動しない回帰テストを追加しています。PRは2026年10月23日にコミット717d7ecとして統合され、同コミットを含む参照リリースv0.37.0は10月28日に公開されました。
CVSS 9.8と公式レコードの8.5を混同しない
開発元Issueの初期報告には 3.1の9.8という評価があります。一方、2026年10月27日に公開されたCVE公式レコードは、攻撃元をローカル、必要権限を低と評価し、CVSS 4.0は8.5、CVSS 3.1は7.8、いずれもHighです。本稿と構造化メタデータではCVE公式レコードのCVSS 4.0=8.5を採用します。
この差は、影響が小さいことを意味しません。攻撃者がネットワーク越しに未認証で直接到達する経路と、AIが読み込んだIssue本文などからツール引数へ誘導される経路では、成立条件が違います。運用上は「MCPがローカルだから安全」と決めつけず、誰がモデル入力を作れるか、モデルがツール引数を自動決定するか、実行プロセスがどの資格情報を持つかを組み合わせて優先度を決めます。
| 確認項目 | 影響判断 |
|---|---|
| 製品と版 | @ai-sdlc/plugin-mcp-server 0.31.2以下はCVE公式レコードで影響あり |
| 対象ツール | check_issue、check_pr_status |
| 必要な入口 | repo引数を操作できるMCP呼び出し。プロンプトインジェクションを含む |
| 実行権限 | MCP Serverを起動したOSユーザーと、そのユーザーのGitHub CLI認証範囲 |
| 修正の識別 | コミット717d7ecを含み、引数配列とowner/name検証を実装 |
スポンサーリンク
最初に配布版と実行経路を棚卸しする
package.jsonだけで判断せず、、実際に起動するMCP設定、コンテナや開発端末へ配布された成果物を確認します。パッケージ名はCVE公式レコードで@ai-sdlc/plugin-mcp-serverとされています。モノレポではルートの宣言と、MCP Serverを起動するワークスペースの解決版が一致しない場合があります。
npm ls @ai-sdlc/plugin-mcp-server
npm explain @ai-sdlc/plugin-mcp-server
# 配布物に修正の特徴があるか確認する例
rg "execFileSync|check_issue|check_pr_status" node_modules/@ai-sdlc
上の検索結果だけで安全を証明することはできません。ベンダー配布版、フォーク、固定コミットを使う環境では、修正コミットと実際の差分を照合します。CVEレコードは0.31.2以下を影響版としていますが、更新先の番号を推測せず、コミット717d7ecを含むこと、execSyncによる文字列連結が消えていること、形式検証テストが入っていることを確認してください。参照リリースv0.37.0は修正後の状態を含みますが、自組織が利用するパッケージの配布名・タグとの対応も別に確認します。
次に、ツールを誰が呼び出せるかを整理します。開発者が手動で固定値だけを渡す構成、モデルがIssue本文やPRコメントから対象リポジトリを選ぶ構成、外部入力を含むエージェントが自動実行する構成では危険度が異なります。特に、外部コントリビューターが書けるIssueやPR本文をモデルへ渡し、承認なしでMCPツールを呼ぶ場合は、入力と実行がつながっています。
更新までの間はツールと資格情報の両方を絞る
更新をすぐ配布できない場合は、check_issueとcheck_pr_statusを許可リストから外すか、MCP Server自体を停止します。UI上で「確認する」と表示するだけでは、クライアントや別経路から呼べる可能性が残ります。サーバー側でツールを公開しない、または固定のowner/nameだけを受け付ける境界を設けます。
実行プロセスへ与える資格情報も縮小します。GitHub CLIのトークンは、必要なリポジトリと読み取り操作へ限定し、MCP Serverのに鍵や本番秘密を同居させないようにします。専用OSユーザー、書き込み不能な作業ディレクトリ、外向き通信の制限を組み合わせれば、コマンド実行が成立した場合の範囲を抑えられます。ただし、これらはの代替ではありません。
ツール呼び出しの承認画面では、ツール名だけでなくrepoの最終値を表示します。形式が正しくても、モデルが意図しないリポジトリを選ぶ可能性は残るため、承認対象と実行時引数が一致することも検証します。既存のMCPツールの説明文とスキーマ差分を確認する運用は、更新で公開範囲が変わる場合の台帳作りに利用できます。
スポンサーリンク
更新後は悪性文字列を実行せず拒否境界を試験する
本番資格情報を持つ環境で公開を実行する必要はありません。テストでは子プロセス呼び出しをモックし、正常なowner/nameでは引数配列に分離されること、空白やシェル記号を含む入力では子プロセスが一度も呼ばれないことを確認します。開発元PRも、この二つを回帰テストの要点にしています。
- 正常なリポジトリ名で
ghと各引数が別要素として渡る - 形式外の
repoが検証で拒否される - 拒否時に
execFileSyncや他の子プロセス関数が呼ばれない - Issue番号とPR番号の型検証が維持される
- ツールエラーへ環境変数やコマンド全文を返さない
さらに、モデルへ外部Issue本文を読ませる評価ケースを用意し、本文中の指示がrepoへそのまま移らないことを確認します。ツール呼び出しのJSONがスキーマに適合しても、安全な値とは限りません。構造化出力とツール呼び出しの責任分界で整理したように、最終的な実行と業務上の検証はアプリケーション側に残ります。
既に使っていた場合はMCPとGitHubの記録を突き合わせる
0.31.2以下で対象ツールを外部入力と組み合わせていた場合は、更新だけで調査を終えません。MCPクライアントのツール呼び出し記録、エージェント会話、プロセス起動ログ、シェル履歴、、・ログを、IssueやPRを読み込んだ時刻と対応付けます。repoへ通常のowner/name以外が渡った記録、MCP Serverの子プロセス、未知の外向き通信、作業ディレクトリの変更を確認します。
GitHub側では、利用していたトークンの、直近のリポジトリアクセス、意図しないIssue・PR操作を確認します。不審な実行があれば、MCP Serverを隔離し、GitHub CLIの認証を失効してから新しいトークンへ差し替えます。同じプロセスに渡していたやSSH鍵も影響範囲に含め、利用記録を調べての要否を判断します。
ログがないことは侵害がない証拠になりません。反対に、形式外の入力が一度あっただけでコマンド実行を断定することもできません。入力、子プロセス、外部通信、資格情報利用を時系列で結び、観測できた事実と推定を分けます。今回の修正は、AIに渡す説明文の改善ではなく、モデルの判断が誤ってもシェルへ越境させない実装境界を追加した点が重要です。
出典・一次情報
本記事は以下の公開情報をもとに作成しています。最新の状況は各リンク先で確認してください。
-
CVE
-
公式アドバイザリ
-
公式アドバイザリ
-
公式アドバイザリ












![[入門]LLMアプリ開発 --基本・LLMのしくみ・MCP・AIセキュリティ](https://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/4707/9784297154707_1_29.jpg?_ex=240x240)
