セキュリティ

GitHub偽VS Codeアラートが拡散、開発者を標的に

開発者の日常に、静かに罠が仕掛けられている。GitHubのDiscussions機能を悪用した大規模フィッシングキャンペーンが、Visual Studio Codeの偽セキュリティアラートを使い、数千のリポジトリに拡散している。

情報の灯台

2026年3月28日

数千のリポジトリに一斉投稿された「緊急警告」

GitHubのDiscussionsに、VS Codeの深刻な脆弱性を警告する投稿が大量に出現している。

タイトルは巧妙だ。「Visual Studio Code – Severe Vulnerability – Immediate Update Required」「Critical Exploit – Urgent Action Needed」──いずれも本物のセキュリティアドバイザリそっくりに作られている。投稿には架空のCVE番号や影響バージョンの範囲まで記載され、一見すると正規の脆弱性情報と見分けがつかない。

アプリケーションセキュリティ企業のSocketが3月25日に公開した調査レポートによれば、これは単発の荒らしではない。数千件の投稿が数分以内に一斉投下される、組織的なスパムキャンペーンだ。投稿元のアカウントは新規作成されたものか、ほとんど活動履歴のないものばかりだった。

Socketの分析では、ほぼ同一の内容を持つ投稿がGitHub全体で数千件確認されており、孤立したインシデントではなく組織的なスパムキャンペーンと判断されている。

そしてここからが、このキャンペーンの本当に巧みなところだ。

GitHubの通知機能が「共犯者」になる構造

攻撃者が狙っているのは、GitHub Discussionsの特性そのものだ。

各投稿には大量の開発者がメンション（@タグ付け）されている。GitHub Discussionsでは、リポジトリのウォッチャーや参加者に対してメール通知が自動送信される。つまり攻撃者はGitHubの正規の通知システムを利用して、偽のセキュリティ警告を開発者の受信トレイに直接届けている。

従来のフィッシングメールなら、見慣れないドメインやフォーマットが警戒心を呼ぶ。しかしGitHubからの通知は、開発者にとって日常の一部だ。差出人は信頼されたプラットフォーム、内容はもっともらしい脆弱性警告、そしてメンテナーやセキュリティ研究者を騙った投稿者──疑う理由が見当たらないのだ。

正直なところ、忙しい作業の合間にこの通知を受け取ったら、反射的にリンクを踏んでしまう開発者は少なくないだろう。

リンクの先にある「見えない選別」

投稿に含まれるリンクは、VS Codeの「修正パッチ」をダウンロードするよう促す。リンク先はGoogle Driveなどの外部ファイル共有サービスだ。正規のVS Codeアップデートがこうした経路で配布されることは絶対にないが、Google Driveという「信頼できるサービス」が使われていることで、警戒のハードルが下がる。

Socketの分析が明らかにした攻撃チェーンは、想像以上に精巧だった。

クリックするとまずGoogleのshare.googleエンドポイントに誘導される。ここで攻撃は分岐する。ブラウザにGoogleクッキーがあるかどうかで、振る舞いが変わるのだ。クッキーがあれば──つまり通常のブラウザ利用者であれば──攻撃者が管理するC2サーバー（Command and Control＝指揮統制サーバー、ドメインはdrnatashachinn[.]com）へ301リダイレクトされる。

クッキーがなければ、フィンガープリンティングページが直接配信される。

この分岐は、自動スキャナーやボットを排除し、「本物の人間」だけを攻撃対象として選別するためのフィルタリング機構として機能している。

着地先では、難読化されたJavaScriptが即座に実行される。タイムゾーン、OS、ユーザーエージェント、隠しiframeによる二次UA、そしてnavigator.webdriverのような自動化検出シグナル──これらのデータが収集され、ユーザーの操作を一切介さずにPOSTリクエストでC2サーバーに送信される。

「第二の矢」はまだ確認されていない

注目すべきは、この段階ではクレデンシャルの窃取も、目に見えるマルウェアの配信も行われていないことだ。

Socketはこの挙動をTDS（トラフィック分配システム）と一致すると分析している。被害者をプロファイリングし、条件に合致した「価値の高い」ターゲットだけをフィッシングページやエクスプロイトキットへ誘導する──そうした多段階攻撃の前段として機能しているとみられる。

第二段階のペイロードは現時点でSocketも捕捉できていない。見方を変えれば、攻撃の本体はまだ姿を現していないということだ。

繰り返されるGitHubの「信頼」を逆手に取った攻撃

GitHubの正規機能が悪用されるのは、今回が初めてではない。

2025年3月には、約1万2,000のGitHubリポジトリを対象にした偽セキュリティアラートキャンペーンが発生した。このときは開発者を騙して悪意あるOAuthアプリを承認させ、アカウントへのアクセス権を奪取する手口だった。2024年6月には、リポジトリへのスパムコメントやプルリクエストを利用してGitHubのメール通知をトリガーし、フィッシングページへ誘導する攻撃も確認されている。

パターンは明確だ。攻撃者は外部からフィッシングメールを送る代わりに、GitHubという「信頼された空間の中」から攻撃を仕掛けるアプローチを繰り返し選択している。プラットフォームの協調的な機能──Discussions、通知、コメント──がそのまま攻撃のインフラになる。

脆弱性情報に接したときの確認手順：CVE番号はNVD（National Vulnerability Database）やMITREの公式サイトで照合する。外部リンクからのダウンロードを求める「緊急パッチ」は、正規のアップデートチャネルでは配布されない。

開発者が「疑う力」を持つしかない現実

正直に言えば、このキャンペーンに対する完璧な技術的防御策は存在しない。

GitHubがDiscussionsのスパム検知を強化することは当然必要だ。しかし根本的な問題は、開発者が日常的に依存するプラットフォームそのものが攻撃のベクターになっている点にある。

対策はシンプルだが、実行には意志がいる。VS Codeのアップデートは必ず公式チャネル（Visual Studio Marketplaceまたはアプリ内更新）から行うこと。GitHub Discussionsに投稿されたセキュリティアラートは、投稿者のアカウント年齢・活動履歴を確認すること。そして「緊急」「即座に対応が必要」というプレッシャーに対して、一度立ち止まること。

開発者にとってGitHubは仕事場であり、信頼の空間だ。その信頼を逆手に取る攻撃が増え続けるなら、私たちは「信頼するが、検証する」という姿勢を──たとえ面倒でも──日常の習慣にするしかない。

参照元