🎍

n8n Supply Chain Attackなど: Cybozu PSIRT Monthly(2026年1月号)

に公開

こんにちは。PSIRTの田口です。

はじめに

PSIRTでは、各メンバーが気になったセキュリティに関する記事や話題を随時、社内のスレッドに投稿しています。本記事では、2026年1月にスレッド内で共有された記事や話題を紹介するとともに、同月に動きのあったWeb標準についてのセキュリティ関連トピックについても取り上げます。また今月は、PSIRTにおけるAIセキュリティの取り組みと、開発チーム向けに実施した勉強会資料についてもあわせて紹介します。

共有された記事・話題

ClickFix attack uses fake Windows BSOD screens to push malware

https://www.bleepingcomputer.com/news/security/clickfix-attack-uses-fake-windows-bsod-screens-to-push-malware/

Windowsのブルースクリーン(BSOD)を模した偽画面を表示し、ユーザーに修復操作を促すことでマルウェアを実行させる「ClickFix」と呼ばれる攻撃手法が紹介されています。攻撃者はWebページ上で本物そっくりのBSOD風の画面を表示し、「問題を修正するために指示に従ってください」といった文言でユーザーを誘導します。提示される手順には、PowerShellコマンドの実行などが含まれており、ユーザー自身の操作によってマルウェアが実行される点が特徴のようです。ソーシャルエンジニアリングとして非常に巧妙な手法であり、こうした非技術的なアプローチが依然として有効であることを再認識させられる事例でした。

Pwning Claude Code in 8 Different Ways

https://flatt.tech/research/posts/pwning-claude-code-in-8-different-ways/
Flatt Security社による調査により、Claude Codeに実装されていた安全機構を回避できる手法が複数発見されました。特定の引数パターンを拒否するblocklistベースの実装不備やCLIツールの仕様等を利用することで、ユーザーの承認なしで任意のコマンドを実行できる手法が紹介されています。本件にはCVE-2025-66032が割り当てられており、Claude Code v1.0.93にて修正済みとされています。
記事内でも強調されていますが、blocklistによる対策は仕様やパターンを完全に網羅することが困難であり、今回allowlist中心の設計へ見直したという修正方針は妥当な対応に思います。AIエージェントにどこまでの権限を与えるか、その境界をどう設計するかが今後ますます重要になることを示した事例だと感じました。

n8n Supply Chain Attack Abuses Community Nodes to Steal OAuth Tokens

https://thehackernews.com/2026/01/n8n-supply-chain-attack-abuses.html
ワークフロー自動化ツールn8nにおいて、悪意のあるコミュニティノード(npmパッケージ)を通じて OAuthトークンを窃取する攻撃が観測されたようです。問題となったノードには、ワークフロー実行時に取得したOAuthトークンを外部に送信する不正な処理が含まれていたとされています。OSSエコシステムにおける高い拡張性は大きな利点である一方で、信頼性とのトレードオフという側面もあり、組織としての導入可否の基準や運用ルールを厳格に整備する重要性を再認識させられる事例でした。併せて、拡張コードがどの権限で動作し、どの範囲に影響を及ぼし得るのかといった点についても、事前に慎重な評価を行う必要性を改めて感じました。

セキュリティインシデントやそれに伴うトラブル防止の観点で考えるビジネスリスク

https://jpn.nec.com/cybersecurity/blog/260116/index.html
セキュリティの技術的対策だけでなく、ビジネス上のやり取りや契約内容の曖昧さがインシデントやその後のトラブルにつながるリスクについて解説されています。セキュリティ対策というと、技術的な防御や検知に目が向きがちですが、契約内容や合意事項が不明確であること自体がインシデントの発生要因となったり、発生時の混乱を招いたりすることで、結果としてビジネス上のリスクを拡大させる可能性がある点を強く認識させられました。責任分担や対応範囲を明確にし合意内容は必ず文書化するなど、ビジネスプロセス側の堅牢化の重要性も感じました。

Google Gemini Prompt Injection Flaw Exposed Private Calendar Data via Malicious Invites

https://thehackernews.com/2026/01/google-gemini-prompt-injection-flaw.html
Google Geminiにおいて、悪意のあるカレンダー招待を介したプロンプトインジェクションにより、ユーザーのプライベートなカレンダーデータが漏洩する可能性があったと報告されています。攻撃者は、イベント内容に悪意のあるプロンプトを含めることで、AIが意図しない情報を参照・出力してしまう状態を引き起こしたとされています。本件は、AIが外部から与えられた入力をどのような文脈や権限のもとで解釈するかによって、そのまま情報漏洩に直結し得ることを示す典型的な事例だといえます。AI機能を設計する際には、入力元の信頼性や権限境界の取り扱いについて厳密な設計・検証を行う必要性を改めて認識しました。

外部公開されたLLM(生成AIサーバ)を探す不審な通信を観測

https://www.mbsd.jp/research/20260121/llmai/
外部に公開された生成AIサーバ(LLM)を探索する目的とみられる不審な通信が確認されたことが報告されています。送信されているリクエストには、OpenAIが提供する Chat Completions APIに類似した形式のものが確認されているようです。LLMも通常のWebサービスと同様に探索・攻撃対象となっており、安易に外部公開すること自体がリスクにつながり得るということを再認識させられる内容でした。

AWS CodeBuildの設定不備を起点にAWS 公式 GitHubのリポジトリが乗っ取られる恐れ

https://rocket-boys.co.jp/security-measures-lab/aws-codebuild-misconfiguration-risks-official-github-repo-takeover-codebreach/
AWSがGitHubで公開しているいくつかのリポジトリに紐づくCodeBuild CIパイプライン設定に不備があり、条件が揃うと第三者が特権的なビルドを実行しGitHubの管理トークンを盗んでリポジトリを乗っ取れる可能性があったようです。AWSは報告を受けて設定修正や追加の防御策を実施し、悪用の痕跡は確認されなかったとのことです。今回のように微妙な正規表現の誤りやそれによる認可不備が、リポジトリ管理権限やソフトウェア供給網全体に影響するリスクにつながることが示されました。クラウドサービスやCI基盤自体の脆弱性に限らず、このような設定ミスが実質的な侵入口になり得るという点でCI/CDはアプリケーションと同等、もしくはそれ以上に慎重な設計とレビューが求められると感じました。

Web標準に関するトピック

サイボウズは、2025年4月よりW3Cのメンバーに加入しており、一部のメンバーはWeb標準についてキャッチアップを行なっています。
https://blog.cybozu.io/entry/joining-w3c
このコーナーではW3Cに限らず、TC39やWHATWGなどの標準化団体のセキュリティ関連トピックについても扱います。

WebAuthn Level 3がCandidate Recommendationに到達

https://www.w3.org/TR/webauthn-3/
W3CにおいてWebAuthn Level 3がCandidate Recommendation(CR)に到達しました。
CRは、仕様の方向性が概ね固まり、実装および相互運用性の検証を進める段階を示す位置付けです。WebAuthnはこれまでもPasskeyをはじめとしたフィッシング耐性がある認証方式の基盤として実運用されてきましたが、Level 3への到達により、Web標準として安定的に議論・参照できるフェーズに入ったと考えられます。

W3CによるThreat Modeling/VDPの明文化の動き

技術仕様とは別の側面として、W3CのSecurity Interest Groupでは、Threat Modeling Guideや標準向けVulnerability Disclosure Process(VDP)を文書として整理する動きが進められています。これらは規範的な仕様ではありませんが、W3C が「標準をどのような脅威モデルのもとで設計し、脆弱性をどのように扱うのか」といったプロセス面のセキュリティを明示しようとしている点は重要であると感じました。

PSIRTのAIセキュリティの取り組み

弊社製品におけるAI機能の開発が進む中、PSIRTとしてもAIセキュリティへの対応を継続的に進めてきました。具体的には、AI機能に対する脆弱性診断を内製で実施するとともに、開発チームへのセキュア開発支援を行っています。

以下の資料は、そうした取り組みの一環として、開発チーム向けに実施した勉強会で使用した資料です。ご興味があれば、ぜひご覧ください。
https://www.docswell.com/s/cybozu-tech/Z74WN6-2025-10-14_LLM_Security
https://www.docswell.com/s/cybozu-tech/KQX62N-2025-11-12-MCP_Security

おわりに

今月の話題は技術的な脆弱性対応にとどまらず、設計レビューや運用ルールの重要性を改めて示すものが多かったように思います。特にAIやCI/CDのような基盤系は、一度問題が起きると影響範囲が広がりやすいため、早い段階からのレビューや横断的な視点でのチェックが不可欠だと感じました。また、単体の脆弱性だけでなく、どの権限で何が動くのか、どこまでを信頼してよいかといった前提を改めて見直す必要性を感じました。

サイボウズ PSIRT

Discussion