VS Code拡張で新たなマルウェア感染 GlassWormが再び確認される

開発者向けエディタとして多くの利用者を持つVisual Studio Codeで、拡張機能を狙う新たなマルウェアが確認されました。

名称はGlassWorm。見た目には分からない不可視コードを仕込み、認証情報や暗号資産を盗み出すとされています。ブロックチェーンを利用した制御サーバー更新など、従来の対策をすり抜ける手口が注目されています。

本記事では、その仕組みと影響、利用者が取るべき対策を解説します。

何が起きたのか（要点と最新状況）

Visual Studio Code（VS Code）の拡張機能で、新たに確認されたマルウェア「GlassWorm」が開発者コミュニティに深刻な影響を与えています。

今回の感染は、OpenVSX上で公開されていた3つの拡張機能を通じて拡大しており、開発環境から資格情報や暗号資産ウォレット情報を盗み出す仕組みが確認されています。

2025年10月にいったん収束宣言が出されたものの、わずか16日後に再感染が確認され、再び警戒が高まっています。

直近の発生事象と対象拡張

2025年11月6日にKoi Securityが公表した報告によると、新たに感染が確認された拡張機能は以下の3つです。いずれも公式レジストリで一時的に配布され、合計で約1万件のダウンロードが行われていました。

これらの拡張機能には、不可視のUnicode文字によって埋め込まれた悪意あるコードが含まれており、開発者が目視で確認しても発見できない仕様となっていました。

感染が発生した拡張の一部は、すでにOpenVSXから削除されていますが、再公開のリスクも指摘されています。

セキュリティ研究者は「自動更新を許可していたユーザー環境では、気づかないうちに感染が拡大していた可能性がある」と分析しています。

時系列整理（収束宣言から再感染まで）

GlassWormの感染経過を整理すると、当初は2025年10月17日に初めて感染が発見され、10月21日にはOpenVSXが「完全に収束した」と発表していました。しかし、その後も攻撃者のインフラが稼働を続けており、11月6日に再び感染が検知されました。

感染再発の要因は、攻撃者がSolanaブロックチェーン上で新しいC2（Command and Control）サーバー情報を更新し、検知を回避したことにあります。

• 10月17日：初期感染確認（7つの拡張が影響）
• 10月21日：OpenVSXが収束宣言
• 10月31日：GitHubリポジトリへの感染拡大報告
• 11月6日：新たな3拡張で感染再発を確認

この一連の流れから、GlassWormは単発の攻撃ではなく、自己増殖型の持続的な脅威として設計されていることが明らかになっています。

ブロックチェーンを利用することでサーバーが停止しても即座に別の命令経路へ切り替えられる点が、従来型マルウェアと異なる特筆すべき特徴とされています。

感染が疑われる利用者の初動対応

VS Codeを利用しているユーザーで、これらの拡張機能をインストールした可能性がある場合は、即座に確認と隔離を行うことが推奨されています。感染リスクを最小限に抑えるため、以下の手順が基本対応とされています。

• 拡張機能の確認：OpenVSXやVS Codeの拡張管理画面で対象拡張が存在しないか確認
• 隔離措置：疑わしい拡張を無効化または削除し、VS Codeを再起動
• ネットワーク遮断：感染の疑いがあるPCを一時的にオフライン化
• 認証情報の更新：GitHub・OpenVSX・暗号資産ウォレットの認証トークンを再発行

加えて、Koi Securityが公表しているIOC（Indicator of Compromise：侵入指標）をもとにハッシュ照合を行うことも推奨されています。こうした基本対応を取ることで、さらなる拡散や不正アクセスを防ぐ効果が期待できます。

仕組みと手口（不可視Unicode／C2更新／自己増殖）

GlassWormは、拡張機能を介して開発者の環境に侵入し、自己増殖と不可視化を組み合わせた前例のない攻撃手法を取るマルウェアです。

従来の検知ツールを回避しながら資格情報を奪い取り、ブロックチェーンを経由して指令を更新するなど、従来の対策をすり抜ける構造を持っています。

不可視Unicodeによるコード隠蔽の仕組み

GlassWormは、Unicode制御文字（Variation Selectorなど）を悪用して、ソースコード内に目視では確認できない不正処理を埋め込んでいます。

エディタ上では空白のように見えても、JavaScriptインタプリタ上では実行可能なコードとして解釈される点が特徴です。

Koi Securityの報告によると、GitHubの差分ビューでも検出されず、通常のコードレビューでは判別が不可能なケースが確認されています。

背景として、開発者が利用する多くのIDEや静的解析ツールが「印字可能文字のみに基づいた構文解析」を行っているため、不可視文字を含む攻撃に対して脆弱です。これにより、正規の拡張開発者が自分のコード内に不正部分を見つけられないまま配布してしまう状況が生じました。

• 検出困難性：不可視Unicodeを利用しているため、視覚的レビューや通常の署名検査では検出できない。
• 攻撃目的：拡張を通じてGitHubやOpenVSXの認証情報を奪取し、拡散の足掛かりを作る。
• 影響範囲：2025年10月時点で少なくとも7件の拡張が感染、3万5000件以上のDLに影響したと推定されています。

この不可視化手法は、セキュリティ検査の盲点を突いたものであり、「見えないコードが動作する」という構造的リスクを浮き彫りにしました。今後、Unicode正規化や不可視文字検査の導入が標準化される可能性も指摘されています。

ブロックチェーンC2の更新手法

GlassWormは、従来のC2（指令サーバー）構造を持たず、Solanaブロックチェーンを中継として命令データを伝達します。

攻撃者はSolana上の取引データ（memo欄）にBase64エンコードされたURLを埋め込み、感染端末がこれを自動的に読み取ることで次のペイロードを取得します。

つまり、C2サーバーが停止しても、攻撃者は新たな取引を投稿するだけで全感染端末を再起動させられる仕組みです。

この手法は「ブロックチェーンをC2として悪用した世界初級の事例」とされ、攻撃者にとっては遮断不能・追跡困難という利点があります。

OpenVSXの遮断措置後も、感染端末がSolana経由で命令を取得する形で活動を再開しており、分散型ネットワークの耐障害性が皮肉にも犯罪利用された形です。

自己増殖サイクルの仕組み

GlassWormの最大の脅威は、感染後に自ら拡散を続ける「ワーム的構造」です。感染端末が保持するGitHubやOpenVSXの認証情報を奪取し、それを使って他の拡張やリポジトリに不正コミットを追加することで、新たな被害者を生み出します。

Aikido Securityの分析によれば、AI生成風の自然なコミットメッセージを利用して正規の更新に見せかけるケースも確認されています。

• 増殖経路：感染→資格情報窃取→不正更新→再感染という循環を自動で実行
• 影響対象：開発者個人だけでなく、企業リポジトリ・政府系組織の環境にも波及
• 検出困難性：署名や差分確認を行ってもAI生成風の改変では違和感が少ない

この自己増殖モデルは、従来のサプライチェーン攻撃と異なり「1件の感染が次の感染を自動生成する」構造を持ちます。そのため、1つの開発環境が破られただけで数十のリポジトリへ波及する恐れがあります。

セキュリティ研究者は、これを「開発者エコシステム全体を揺るがす長期型攻撃」と位置付けています。

影響範囲と想定リスク（企業・個人・OSSコミュニティへの具体的影響）

GlassWormの技術構成と自己増殖の特性を踏まえると、被害は開発者個人に留まらず、企業内システムやOSSエコシステム全体に波及する可能性が高いとされています。

認証情報の窃取や改ざんコミット、暗号資産の流出、さらには感染端末を経由した社内ネットワーク横展開など、複数レイヤーでの被害シナリオが現実味を帯びています。

被害領域の洗い出し（資格情報・ウォレット・改ざんコミット等）

事実として、GlassWormは開発環境から以下のような資産を狙うことで実害を発生させています。

Koi SecurityおよびAikido Securityの報告を基にすると、対象はNPMトークン、GitHubパーソナルアクセストークン、OpenVSXの認証情報、並びに暗号資産ウォレット拡張のシークレットです。

これらの窃取により、不正パッケージの公開、リポジトリへの改ざんコミット、ウォレット残高の不正送金といった被害が確認されています。

背景として、対象資産はいずれも開発・デプロイ作業に自動的に用いられることが多く、トークンや認証情報が一度漏洩すると即時的に悪用されやすい点が挙げられます。

特に自動デプロイ設定やCIの認証情報が流出すると、不正コードが組織のプロダクトに混入するリスクが増大します。

• 資格情報窃取：NPM/GitHub/OpenVSXの認証が悪用され、不正パッケージ公開や改ざんが実行される。
• ウォレット被害：49種のウォレット拡張が標的とされ、実際に資金流出が発生する事例が報告されている。
• プロキシ化：感染端末がSOCKSプロキシ化され、攻撃者が社内ネットワークへ間接的にアクセスする足掛かりとなる。

意味として、単一の開発者端末の侵害が、ソフトウェア供給連鎖全体や企業の運用基盤へ波及する恐れがあるとされています。被害の深刻度は、流出した認証情報の権限範囲と自動化の度合いに左右されるため、最小権限と鍵管理の厳格化が重要になります。

日本の企業・開発組織における実務リスク（影響分類と対応の優先度）

現状として、日本国内の企業が直面するリスクは、主に三つの軸で整理できます。第一に開発プロセスとCI/CDに組み込まれた認証情報の流出、第二にプロダクト／顧客向け納品物への改ざん、第三に感染端末を踏み台とした社内システムへの横展開です。

これらは企業の規模に関係なく発生し得ますが、被害影響は大企業の方がサプライチェーンを通じた副次的被害が大きくなる傾向があります。

以下の表は、影響対象と想定される実務上の被害および初動での対応優先度を示します。優先度は高・中・低で示しています。

背景として、日本企業では共有トークンやスクリプトによる自動化が広く使われているため、認証情報の露出が即時的かつ広範囲な影響をもたらす点が問題視されています。

意味として、組織はまずCI/CDのシークレット管理とリポジトリ保護を優先する必要があり、技術面の対処と並行して、インシデント時の法務・広報対応計画も整備することが求められます。

OSSエコシステムへの波及（マーケットプレイス・リポジトリ運用上の構造的脆弱性）

事実として、OpenVSXやMicrosoftのMarketplace、GitHubなどの公開リポジトリは、開発者が配布や受信を日常的に行う場であり、ここに不正コードが混入すると多数の利用者へ自動拡散する構造が確認されています。

Koi Securityの初期報告では、複数の拡張がマーケットプレイス上で短期間に感染版として配布され、合計で数万件のインストールが発生したとされています。

背景には、拡張やパッケージの配布モデルが「信頼に基づく取引」に依存している点があります。つまり、公開者アカウントの乗っ取りやトークンの不正利用が起きると、マーケットプレイスの審査だけでは完全に防げないという限界が露呈しました。

• 構造的脆弱性：拡張の自動更新や高権限での実行が標準設定になっている点
• 波及メカニズム：マーケットプレイス経由の自動更新→利用者の無自覚感染→認証情報窃取→さらなる配布
• 運用上の懸念：マーケットプレイス側での完全自動検査は難しく、ヒューマンレビューとの組合せも盲点が残る

意味として、OSS運用者やマーケットプレイス事業者は、拡張やパッケージの署名・供給連鎖の可視化、不可視文字検査、そして公開者アカウントの多要素保護を早急に強化する必要があるとされています。

利用者側も、マーケットプレイスからの自動更新設定や拡張の権限を見直す運用変更が求められます。

検出・隔離・復旧手順

感染が疑われる端末や組織では、即時の検出と隔離、そして段階的な復旧が求められます。本章ではローカル確認から認証情報のローテーション、リポジトリ健全化までの優先的な実務手順を示します。

実施順は即時対応→中期対応→恒久対策の流れを想定しており、被害拡大を最小化するための具体的行動を中心に整理します。

ローカル環境での確認と隔離（拡張停止・ハッシュ照合・ネットワーク遮断）

事実として、まずは疑わしい拡張機能の有無を確認し、インストール済みであれば即時に無効化または削除することが最優先です。

Koi Securityが公開したIOCや拡張名リストに照らし合わせ、対象拡張が存在するかを確認します。自動更新が有効だった場合は、被害端末が不正ペイロードを既に取得している可能性が高いため、ネットワークから切り離すことが推奨されます。

背景として、GlassWormのような不可視コード型の侵害は、見た目のソース確認だけでは発見が難しいため、ハッシュ照合や既知IOCによるスキャンが有効です。

組織内でEDR（Endpoint Detection and Response）を運用している場合は、拡張のプロセス挙動や外部接続ログを優先的に調査します。

なお、報告されているC2やエクスフィルトレーション先としては 199.247.10.166 や 199.247.13.106:80/wall 等が指摘されていますので、これらへの通信ログを重点的に確認します。

• 即時対応：対象拡張の無効化・削除、PCの一時ネットワーク遮断
• 検査手順：拡張ファイルのハッシュ対照、IDEの拡張フォルダをバックアップしてオフラインで解析
• ログ確認：外向き接続先のDNS/HTTPログ、プロセス開始のタイムスタンプを確認

意味として、初動を誤ると認証情報の窃取や社内ネットワークの踏み台化が進むため、疑わしい端末は業務切り離しのうえで専門チームが対応することが被害軽減に直結するとされています。

認証情報のローテーションと強化（GitHub・OpenVSX・ウォレット）

事実として、GlassWormはNPMトークンやGitHubのパーソナルアクセストークン、OpenVSX認証情報、そして暗号資産ウォレットのシークレットなどを狙っています。

感染が疑われる場合は、これらのトークンと認証情報を速やかに無効化し、再発行することが必須です。特にCI/CDに保存されたシークレットは優先度を最上位にしてください。

背景には、自動化された権限付与や共有トークンの運用が広く行われていることがあります。GitHubのPersonal Access Token（PAT）やNPMトークンは発行時に広範な権限を与えがちであり、漏洩時の被害が拡大しやすい点が問題視されています。

対応としては、トークンの即時無効化、2要素認証の全面適用、権限最小化の原則適用が推奨されます。

意味として、認証情報のローテーションは単なる再発行に留まらず、権限の棚卸しと認証基盤の強化（2FA・SSO・短寿命トークン化）を同時に行う好機とされています。

特にCI/CDでの機密管理は、VaultやSecret Managerを用いた暗号化保管へ段階的に移行することが推奨されます。

リポジトリ健全化（改ざんコミット検出・強制署名・保護ルール）

事実として、GlassWormは奪取したGitHub認証情報を用いて不正コミットを押し込み、AI生成風の自然な差分で改ざんを隠す事例が報告されています。

これに対しては、既存コミットの整合性確認、強制署名（GPG/署名コミット）の導入、保護ブランチやCIチェックの強化が有効とされています。被害を受けたリポジトリでは、改ざん箇所の特定と差し戻し（revert）、さらに侵害源の特定調査が必要です。

背景には、開発フローの自動化とリポジトリの公開性があります。公開リポジトリは協業性を担保する一方で、認証情報が奪われた場合の波及経路となるため、署名やブランチ保護を通じた「更新ガード」が必須です。

具体的な対策には、強制的なコード署名、マージ前の自動静的解析、外部コミットの追加検査が含まれます。

• 検出手段：差分分析、コミット署名チェック、CIの異常検出ルール
• 復旧手順：不正コミットのrevert、影響範囲のビルド再実行、依存パッケージの再発行
• 恒久対策：保護ブランチの必須化、GPG署名の必須化、外部コミットに対する審査強化

意味として、リポジトリ健全化は単発の修復作業ではなく、将来の攻撃を未然に防ぐための仕組み作りと位置づけられます。特に公開リポジトリを持つ組織は、署名・保護ルール・CIゲートを組み合わせた防御層の構築を急ぐ必要があるとされています。

メグルテ編集部

テックの今を伝える編集部

MEGURUTE編集部は、国内外のテクノロジー・IT・AIニュースを日本語でわかりやすく届けるメディアです。SNSで話題のサービスや革新的な研究も、実用目線で解説。初心者にも読みやすく、信頼できる情報発信を心がけています。特集して欲しい事があればお問い合わせよりご連絡ください。