世界を動かす技術を、日本語で。

グラスワームが帰ってきた:見えないUnicode攻撃の新たな波がリポジトリを襲う

2026年3月15日原文(aikido.dev)

概要

  • Glassworm による不可視Unicode攻撃が再び活発化
  • GitHub、npm、VS Codeなど複数エコシステムに被害拡大
  • 攻撃は 不可視Unicode文字 を使いマルウェアを隠蔽
  • 有名リポジトリも複数被害、AIを用いたカモフラージュも観測
  • Aikido などの専用検出ツールによる防御が重要

Glassworm攻撃の再来と拡大

  • 2025年から追跡している Glassworm による不可視Unicode攻撃の再発
  • 2026年3月にGitHub、npm、VS Code Marketplaceで大規模な攻撃キャンペーンを確認
  • PolinRiderキャンペーン とは別に、Glasswormが独自に活動再燃
  • 影響範囲は数百のGitHubリポジトリ、npmパッケージ、VS Code拡張機能に及ぶ

攻撃手法の概要

  • 攻撃者は 不可視Unicode文字 (PUAなど)を空文字列内に埋め込み、マルウェアペイロードを隠蔽
  • 例:const s = v => [...v].map(w => ...); eval(Buffer.from(s(``)).toString('utf-8'));
    • 一見空のバッククォート内に不可視文字を挿入
    • デコーダ関数で復元し、eval()で実行
  • 復元後のペイロードは Solana経由で第二段階スクリプトを取得し、トークンや認証情報を窃取

2026年3月の被害規模

  • GitHub上で少なくとも151件 のリポジトリに同一パターンのデコーダを確認
    • 実際の被害数は削除済みリポジトリも含めさらに多い可能性
    • 攻撃期間は2026年3月3日~9日
  • npmやVS Code Marketplaceにも同様の手法で感染拡大
    • 例:@aifabrix/miso-client (npm), quartz.quartz-markdown-editor (VS Code)
  • 有名プロジェクトへの被害
    • pedronauck/reworm(1,460スター)
    • anomalyco/opencode-bench、doczjs/docz-plugin-css など

AIによるカモフラージュ

  • 攻撃コミットは ドキュメント修正やバージョンアップ、リファクタ など自然な内容で偽装
  • 151件以上のリポジトリに対し個別最適化された変更が行われているため、 大規模言語モデル(LLM)による自動生成 の可能性が高い
  • 手動でこれほど多くの自然なコミットを用意するのは現実的ではない

検出と防御策

  • 肉眼や一般的なLintツールでは不可視Unicodeは検出困難
  • Aikidoなどのセキュリティツールは不可視Unicode混入を自動検出可能
    • Aikido利用者には100/100のクリティカル警告として通知
  • Aikido Safe Chain はnpm、yarn、pnpmなど主要パッケージ管理ツールに対応したリアルタイムマルウェア防御ツール
    • AIと人間の研究者による最新サプライチェーン攻撃の即時検出・遮断
  • 無料プラン でもマルウェア検出機能を利用可能

まとめ

  • Glasswormの不可視Unicode攻撃は 多エコシステム・AI活用・大規模化 が特徴
  • 見えない脅威には 専用検出ツールの導入 が不可欠
  • オープンソース利用者は Aikidoなどの対策ツール で早期検知・感染防止が重要

Hackerたちの意見

昨日ちょっとした議論があったね(9+9ポイント、9+4コメント) https://news.ycombinator.com/item?id=47374479 https://news.ycombinator.com/item?id=47385244

eval だけでも十分に警告サインだよね。

いや、違うよ。

そうだね、明らかにエクスプロイトがある例じゃないのを見てみたかったな。レビュアーが実際に見逃す可能性があるようなやつ。

JSの人じゃないけど、その行をそのまま受け取ると何もならないんじゃない?もし俺の理解が正しければ、マージされることはないはず。なんでノーオプをマージするの?

個人的には、「特定の攻撃に対してリポジトリの運営者自身が守る責任がある」と言うのはハードルが高いけど、これは該当すると思う。GitHubがSecret Scanningを提供しているのと同じように、言語的に標準的でない使い方をされているゼロ幅文字のスパンに対して警告を出すべきだよ。これにはLLMは必要なくて、n-タプルだけで十分。もちろん、OPのようなサードパーティのサービスがスキャンするボットを提供することもできるけど、もし脅威アクターがPRを提出できるエコシステムを作るなら、コミュニティへのコミットメントの一部として、目に見えない攻撃を可視化することを提供し、それを例外ではなく標準にするべきだと思う。[0] https://docs.github.com/en/get-started/learning-about-github...

GitHubの責任がどうかという難しい問題は置いといて、彼らが早急にやるべきことだと思う。

「特定のパターンに一致するファイルのために可視ASCIIを強制する」モードは、シンプルで役立つと思うよ。(これには.gitattributesファイルの「encoding」コマンドを使えるかもしれないけど、エラーや警告が報告されるかはわからないし、実装によるかもしれないね。)

その問題で指摘されているコードを、何をするのかも知らずにマージするメンテナーがいるなんて信じられない。目に見えない文字が見えるかどうかに関係なくね。ここには変換関数とeval()の呼び出しがある。ソフトウェアのメンテナーが何をするかも知らずにコードをマージするって、ソフトウェアのひどい状態を物語ってるよ。

もっとアップボートできたらいいのに。

今回の件でマージされたPRは6年前のもので、はっきりしてるね。https://github.com/pedronauck/reworm/pull/28 俺には、6年後に行われた強制プッシュが、今の履歴にあるコミットを上書きしたように見える。

どんなメンテナーが、問題にハイライトされたようなコードを、何をするのかも知らずにマージするのか理解できない。ここで議論されている特定のケースに関係があるかは分からないけど、もしその脆弱性が以前信頼されていた提出者のアカウントにアクセスすることから来ているなら(または彼らを偽装できる場合)、PRをレビューするのが山ほどあるチームが、信頼できるソースからの更新を通してしまう可能性がある。これは怠慢や手抜きが原因だと正しく主張できるけど、ボランティアの労働力で運営されているプロジェクトは限られた時間しかないから、理解できる部分もあるよね。

Hacker Newsで議論の続きを見る