この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
OSSを日常的に活用するLinuxエンジニアにとって、ここ最近もっとも注意すべき脅威が水面下で急拡大しています。
日経クロステックの報道（2026年4月）によると、「GlassWorm」と呼ばれる新型サイバー攻撃がGitHubやnpm、Open VSXといったコード管理プラットフォームで猛威を振るっており、151件以上のGitHubリポジトリと433件以上のソフトウェアパッケージが汚染されていることが確認されています。
この記事では、GlassWormの仕組みをLinuxエンジニア向けにわかりやすく解説し、現場での対策を考えます。
この記事のポイント
・GlassWormはUnicode不可視文字を使い、コードレビューをすり抜けてマルウェアを埋め込む
・1行のコードの中に1万8000行以上の悪意あるコードが隠せることが判明
・GitHubのOSSを利用する開発・運用現場は今すぐ対策が必要
・検出にはテキストエディタでのUnicode確認や専用ツールの活用が有効
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
GlassWormとは何か？
GlassWorm（グラスワーム）は、2025年10月にイスラエルのセキュリティ企業が初めて発見し、2026年3月に急増が明らかになった新型のサプライチェーン攻撃です。「Worm（ワーム）」という名前がついていますが、自己増殖型のウイルスとは少し異なります。むしろ「見えない（Glass）」という特性が本質で、コードレビューをしても肉眼ではまったく発見できないように設計された攻撃手法です。
攻撃者は「善意の開発協力者」を装い、OSSプロジェクトにプルリクエスト（コード変更提案）を送ります。表面上のコードは正常に見えますが、その1行の中に不可視文字として大量の悪意あるコードが埋め込まれているのです。
Unicode不可視文字を悪用する仕組み
1. 不可視文字とは
Unicodeには、画面に何も表示されない「制御文字」や「異体字セレクター」と呼ばれる文字が存在します。これらは通常、テキストの書式や言語表示の調整に使われるものですが、GlassWormはこれを悪用します。攻撃者はこれらの不可視文字を大量に組み合わせることで、表示上は何もない空白や1行のコードに見せかけながら、内部に独立した実行可能なコードを隠します。
2. 1行に1万8000行が隠れる
実際の攻撃事例では、たった1行のコードの中に1万8000行以上の悪意あるコードが隠されていた事例が確認されています。コードエディタ（VS Codeなど）で見ると普通の1行。しかしテキストバイナリダンプで確認すると、膨大なデータが格納されていることがわかります。
# 一見普通に見えるコードの例（実際は1行に不可視データが埋め込まれている） source_code = "normal_function()" # ← この1行に見えない悪意ある文字列が存在 # od（オクタルダンプ）コマンドで検証する方法 $ od -c suspicious_file.py | head -5 # 不可視文字があれば \xe2\x80\x8b などのバイト列が大量に現れる
3. コードレビューで検出できない理由
GitHubのPR（プルリクエスト）画面、多くのコードエディタ、そしてLLM（大規模言語モデル）によるコードレビューでも、この不可視文字は見えません。コードの「意味的な部分」だけを評価するため、視覚的に存在しない文字を攻撃として検出できないのです。これが「Glass（見えない）」と呼ばれる理由です。
感染規模と影響範囲
2026年4月時点で確認されている被害規模は以下の通りです。| プラットフォーム/対象 | 確認された汚染数 |
|---|---|
| GitHubリポジトリ | 151件以上 |
| ソフトウェアパッケージ全体 | 433件以上 |
| 対象プラットフォーム | GitHub、npm、Open VSX |
| 初発見 | 2025年10月（イスラエルのセキュリティ企業） |
特にnpmはNode.jsのパッケージ管理システムとして世界中のWebシステムで利用されており、汚染パッケージが依存関係経由で伝播するサプライチェーン攻撃のリスクが極めて高い状況です。
Linuxエンジニアが今すぐできる対策
1. 外部コードの取り込みは必ずバイト単位で検証する
視覚的なコードレビューだけでは限界があります。以下のコマンドを使い、不可視文字が混入していないか確認することを習慣にしましょう。# 不可視Unicode制御文字の確認（catで非表示文字を可視化） $ cat -A suspicious_file.py # hexdumpで生バイトを確認 $ hexdump -C suspicious_file.py | head -20 # 特定のUnicode制御文字ブロック（U+200B等）を検索 $ python3 -c " content = open('suspicious_file.py', encoding='utf-8').read() suspects = [hex(ord(c)) for c in content if ord(c) in range(0x200B, 0x200F) or ord(c) in range(0xFE00, 0xFE0F)] print(f'疑わしい文字: {suspects[:10]}') print(f'合計: {len(suspects)}件') "
2. 信頼できるソースからのみパッケージを取得する
npmやpipでパッケージをインストールする際は、以下を確認する習慣をつけましょう。・公式ページと一致するパッケージ名か（typosquattingに注意）
・メンテナーが最近変わっていないか
・コントリビューターが突然増えていないか（攻撃者が紛れ込んでいる兆候）
・ダウンロード数が急に増加していないか（拡散後の指標）
3. CIパイプラインに静的解析ツールを組み込む
自動ビルド・デプロイを行うCI/CDパイプラインに、Unicode不可視文字の検出ツールを組み込むことを推奨します。# GitHub Actionsでの例：怪しいUnicode文字を含むファイルを検出 - name: Check for invisible Unicode characters run: | python3 -c " import os, sys found = False for root, dirs, files in os.walk('.'): for fname in files: if fname.endswith(('.py', '.js', '.sh')): path = os.path.join(root, fname) content = open(path, encoding='utf-8', errors='ignore').read() suspects = [i for i, c in enumerate(content) if ord(c) in range(0x200B, 0x200F) or ord(c) in range(0xFE00, 0xFE0F) or ord(c) == 0x00AD] if suspects: print(f'[WARN] {path}: {len(suspects)}件の不可視文字') found = True sys.exit(1 if found else 0) "
4. LLMによるコードレビューを過信しない
ChatGPTやGitHub CopilotなどのAIツールでコードを確認しても、この種の攻撃は検出できません。AIレビューはあくまで補助ツールとして位置づけ、重要なコードの変更は人間による詳細なバイト検証を必ず行いましょう。なぜこれがLinuxエンジニアにとって重大なのか
サーバー管理者・インフラエンジニアは、日常的にシェルスクリプト、Ansible、Pythonスクリプト、各種ミドルウェアをOSSから導入します。15年以上サーバー運用に関わってきた経験から言えば、「公式GitHubのコードだから安全」という思い込みは今や通用しません。攻撃者はOSSの「信頼の連鎖」そのものを狙っているのです。
特にLinuxサーバー環境では、汚染されたスクリプト1本が実行されることで、以下のような被害につながる可能性があります。
・バックドアの設置（リモートアクセスを許可する設定が埋め込まれる）
・認証情報の窃取（/etc/passwdやSSH鍵へのアクセス）
・ランサムウェアの実行（ファイルの暗号化・削除）
・他のサーバーへの横移動（内部ネットワークへの侵入）
VS Code拡張機能の点検手順（Linux運用者向け）
GlassWormは2025年10月17日にKoi Securityによって発見されました。OpenVSXに公開されていた7本のVS Code拡張機能が初期感染の起点となり、合計約35,800ダウンロード分が汚染されています。VS Codeは拡張機能を自動更新する設定がデフォルトのため、運用者が気づかないうちに被害が拡大した点が特徴です。Linuxサーバーの運用作業で開発端末（macOS / Linux / Windows）に VS Code を入れている場合、まず手元の拡張機能リストを点検してください。私のチームでは2026年4月から、四半期に1度は以下の手順で点検しています。
# インストール済み拡張機能をリストアップする $ code --list-extensions --show-versions # 出力例 # ms-python.python@2024.0.1 # rust-lang.rust-analyzer@0.4.2042 # yzhang.markdown-all-in-one@3.6.2 # 拡張機能の発行元（publisher）を確認する $ code --list-extensions --show-versions | awk -F. '{print $1}' | sort -u
~/.vscode/extensions/ 配下に残ったキャッシュファイルを削除します。手順は次のとおりです。# 拡張機能のアンインストール $ code --uninstall-extension ＜publisher.extension-name＞ # 拡張機能ディレクトリの残骸を確認する $ ls -la ~/.vscode/extensions/ # 残っている怪しいディレクトリを削除する（バックアップしてから） $ tar czf ~/vscode-ext-backup-$(date +%Y%m%d).tar.gz ~/.vscode/extensions/＜怪しいディレクトリ＞ $ rm -rf ~/.vscode/extensions/＜怪しいディレクトリ＞
Solanaブロックチェーン C2 が現場運用にもたらす影響
GlassWormが従来のサプライチェーン攻撃と決定的に違うのが、コマンド＆コントロール（C2）にSolanaブロックチェーン（公開・分散・改ざん耐性のある台帳）を使っている点です。具体的には、攻撃者が支配する固定ウォレットアドレス「28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2」に対するトランザクションのメモ欄に、Base64でエンコードされたC2サーバーURLが格納されています。フォールバック経路としてGoogle Calendarのイベントタイトルにも同様のURLが仕込まれています。| 項目 | 従来型C2 | GlassWorm（Solana C2） |
|---|---|---|
| 遮断手段 | DNS / IPブロック | 事実上不可能（ブロックチェーンは消せない） |
| 追跡性 | WHOIS / Passive DNS | ウォレットの公開履歴は読めるが「停止」はできない |
| 切替頻度 | 攻撃者が定期的に変更 | 新ウォレット発行で簡単に切替 |
| 運用側の検出 | EDRでドメイン検知可能 | 送信先がブロックチェーンノードのため判別困難 |
ファイアウォールやプロキシ製品で「悪性ドメイン」を遮断する従来の防御は、Solana C2には効きません。これからのサーバー運用者にとっての現実解は、「侵入された後に何ができないか」を縛る方向の防御です。具体的には、開発端末からの本番サーバーへのSSH踏み台を必ず通す、SSHキーを期限付きにする、AWS IAMやGCP IAMで「拡張機能から見える範囲」を最小化する。受講生にも繰り返し伝えていますが、「入口で全部止める」ではなく「入られても抜かれない」設計に発想を切り替える時期に来ています。
SSH鍵の取り扱いについては SSH接続のルートログイン制限 と lsofでプロセスが開いているファイルを確認する方法 も併読すると、「鍵の流出経路」と「踏み台で使われている鍵の現状把握」が両方できるようになります。
サプライチェーン攻撃に強くなる現場チェックリスト
GlassWormは「Linux開発者の手元から狙う」攻撃の象徴例ですが、これに対する備えは、スキャンツールを増やすより、運用ルールを整えることのほうが効きます。受講生のいる企業に「最低限これだけは」と伝えているチェックリストは次のとおりです。・VS Code 拡張機能の自動更新を制限する：
"extensions.autoUpdate": false を設定し、更新前に変更履歴を確認する運用に切り替える・npm install の出所監視を入れる：
npm audit signatures でパッケージ署名を確認する。--ignore-scripts オプションを社内デフォルトにし、postinstallスクリプトを暗黙実行させない・git fetchの後にdiffを目視する：
git diff --stat で大量変更ファイルがないかチェック。grepコマンドで $'0' のような不可視文字パターンを検出する習慣を持つ・SSHキー / クラウド認証トークンを開発端末に置きっぱなしにしない：1Password CLI / aws-vault / op-cli などでセッションごとに引き出す運用
・サンドボックス環境で「最初の1回」を実行する：見慣れないツールやスクリプトはVMもしくはDockerコンテナの内側で動かしてから本番に持ち込む
・OSSの組み合わせを年1回監査する：依存関係グラフ（npm ls / pip show / cargo tree）の差分を年1で点検し、メンテナの交代・突然のコントリビュータ参入を見逃さない
GlassWorm はLinuxの脆弱性ではなく、「Linuxを触る人の周辺ツール」を狙った攻撃です。だからこそ、CVE-2026-31431（Copy Fail）のようなカーネル脆弱性と並べて運用設計する必要があります。「カーネルにパッチを当てる」と「開発端末をきれいに保つ」、両輪で初めて2026年のLinux運用は成立します。
本記事のまとめ
| 項目 | 内容 |
|---|---|
| 攻撃名 | GlassWorm（グラスワーム） |
| 手口 | Unicode不可視文字を使いコードに悪意ある処理を隠蔽 |
| 被害規模 | 151件以上のGitHubリポジトリ、433件以上のパッケージ |
| 検出困難な理由 | コードエディタ・LLMでは不可視文字が見えない |
| 対策1 | od -c/hexdump/python3でバイト単位検証 |
| 対策2 | パッケージの出所・メンテナー変更を確認 |
| 対策3 | CIパイプラインに不可視文字検出ツールを組み込む |
OSSは現代のLinuxインフラに欠かせない存在ですが、「コードが公開されているから安全」という思い込みはすでに危険な時代になっています。
GlassWormはその象徴です。コードレビューの習慣に「バイト単位の検証」を加えることが、今のLinuxエンジニアに求められるセキュリティ意識です。
参考: 日経クロステック「不可視文字でマルウエア混入 GitHubなどで汚染拡大、開発基盤の信頼揺らぐ」（2026年4月掲載）
「Linuxが分かる」を実感できる学習を始めませんか？
セキュリティ意識の高いLinuxエンジニアになるには、コマンドの使い方だけでなく、現場でのリスク管理の「型」を身につけることが大切です。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linux 7.1でi486 CPUサポートが終了｜現場エンジニアが知っておくべき32ビット時代の幕引き
- 前のページへ：Ubuntu 26.04 LTSにすぐアップグレードすべきか？現役講師が語る移行判断の勘所と注意点
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます