Packagistで8件のパッケージが改ざん、package.jsonの罠でLinuxバイナリ実行—PHP×JSの境界を突く巧妙なサプライチェーン攻撃です

今日の深掘りポイント

• PHPの依存管理（Composer）に目がいく心理を突き、同梱されたNode系ツールのpackage.jsonに悪性postinstallを仕込む“視線の誘導”が本質です。
• 実行対象はGitHub由来のLinuxバイナリで、LinuxベースのCIランナーやサーバを的確に踏み台化し得ます。開発機よりCI/CDの方が危険度が高い可能性があります。
• “ロックファイルを固定すれば安心”は半分正しく半分誤りです。固定は拡散抑止に有効ですが、悪性版を固定してしまうリスクも内包します。固定＋検知・ブロックの二段構えが必要です。
• 依存解決時のスクリプト実行そのものをデフォルト拒否し、許可リストで最小化する運用（--ignore-scripts等）に舵を切るべき局面です。
• CIの信頼境界を再設計し、依存インストール工程の外向き通信をレジストリと社内ミラーに限定する“出入口対策”を優先度高で実装すべきです。

はじめに

Packagistで配布される8つのパッケージに悪性コードが混入し、package.jsonに仕込んだスクリプト経由でGitHub上のLinuxバイナリを実行するサプライチェーン攻撃が確認されています。標的はPHPコードとJavaScriptビルドツールを併用するプロジェクトで、開発者がComposerのメタデータだけを精査してpackage.jsonを見落とす「認知の死角」を突いています。改ざん済みパッケージはすでにPackagistから削除されていますが、被害範囲や攻撃者の目的はなお不明点が残る状況です。報道では、同系統のペイロードが777のファイルで観測されたとの指摘もあり、単発ではなく広範なキャンペーンの一部である可能性が示唆されています。

本件は「即応する価値が高い」部類のサプライチェーン事案です。過度な楽観論を退けつつ、ロックファイル固定やCI信頼境界の見直しを“今日から”適用できる作業単位にまで分解して進めることが鍵になります。

参考：報道まとめは末尾の参考情報を参照ください。

深掘り詳細

事実整理（いま分かっていること）

• Packagist上の8パッケージに悪性コードが混入し、package.jsonに挿入したスクリプトでGitHubから取得したLinuxバイナリを実行していた可能性がある、という報道が出ています。
• 標的はPHPとJavaScriptビルドツールを併用するプロジェクトで、Composerのメタデータに注意を引きつける一方、package.jsonのスクリプトで挙動を埋め込む手口です。
• 悪性パッケージはPackagistから削除済みですが、感染経路・侵害範囲・実害の有無は未確定の部分があります。
• 同様のペイロードが777ファイルで見つかったとの指摘があり、より広いキャンペーンの一部である可能性があります。
• 出所はGitHub上のアーティファクト（Linuxバイナリ）で、CIやLinuxサーバ上での自動実行を意図していると読めます。

上記は公開報道に基づく要点であり、確定値は今後のフォレンジック次第です。

インサイト（編集部の見立て）

• 視線の誘導こそがコア戦術です。PHPの依存管理ではcomposer.json/composer.lockの整合やプラグイン許可に意識が集中しがちです。一方で、同居するNode系のpackage.jsonは「ビルド定型」としてレビュー密度が薄く、postinstall・prepare・installなどの自動実行フックが“盲点”になりやすいです。
• LinuxバイナリをGitHubから直取得する設計は、GitHub ActionsやGitLab CI、各種ホステッドランナーがLinuxを標準とする現実を踏まえた“CI直撃型”に見えます。開発者PCのセキュリティよりも薄い、短命で監査が粗くなりがちなランナー環境を足掛かりにシークレットやトークンを狙う仮説は十分に合理的です。
• ロックファイル固定は“拡散速度の抑制”には効きますが、“混入版がロックされたまま残留する”副作用があります。したがって固定は前提としつつ、依存インストールにおけるスクリプト実行を原則禁止（--ignore-scripts）し、許可が必要なときのみ審査を通す方針に切り替えるのが現実解です。
• 「スクリプト＝コード」と捉え、依存更新のレビューで新規・変更されたinstall系スクリプトを差分抽出して強制確認する運用が必要です。トライアージの優先度付けは、ネットワーク呼び出し（curl/wget/git）、権限変更（chmod +x）、一時領域実行（/tmp配下）といった高リスク動作を含むかどうかを軸にすべきです。

脅威シナリオと影響

以下は現時点の公開情報から導く仮説ベースのシナリオです。MITRE ATT&CKの用語に沿って整理します（テクニックIDは割愛し名称で記載します）。

• シナリオ1：CI/CDランナーの踏み台化

  • 侵入ベクトル: 依存導入時のpostinstall実行（Supply Chain Compromise: Compromise Software Dependencies and Development Tools）
  • 実行: コマンド／スクリプト実行（Command and Scripting Interpreter）、外部バイナリ取得（Ingress Tool Transfer）
  • 窃取・横展開: CIの短期トークン・クラウド資格情報の窃取（Credentials from Password Stores/Cloud Credentials）、リポジトリへの不正Push（Exfiltration/Impact via Version Control）
  • 影響: ビルド成果物の改ざん、他プロジェクトへの二次供給による連鎖的汚染

• シナリオ2：開発者ワークステーションでの情報窃取

  • 侵入ベクトル: パッケージインストール時の自動実行
  • 実行・防御回避: 正規ツール悪用（Trusted Developer Utilities/Install Scripts）、難読化／一時領域実行（Obfuscated/Deobfuscated, Masquerading）
  • 影響: SSH鍵、クラウドCLI資格情報、ブラウザセッションの流出。社内リポジトリ・VPNへの横展開

• シナリオ3：本番環境での任意コード実行

  • 侵入ベクトル: デプロイ工程やコンテナビルドでcomposer install/npm installを実施している環境
  • 実行: バイナリ実行、外向き通信でのペイロード追加取得
  • 影響: サービス停止、データ抽出、ランサム的二次被害。コンテナイメージの汚染と継続的な再汚染

共通の観測指標（Hypothesis）

• 依存導入中にgithub.comやraw.githubusercontent.com、GitHub Releases/CDNへの不審なアウトバウンド通信
• 親プロセスがnpm/yarn/pnpm/nodeやcomposerで、子にcurl/wget/chmod/bashを伴うプロセスツリー
• /tmp配下やワークスペース直下に落ちた未知バイナリの実行痕
• package.jsonに新規追加されたinstall/preinstall/postinstall/prepareスクリプトの増加

地政学的含意（仮説）

• 言語・レジストリ境界を超える攻撃は、国・業界を選ばず広域に拡散しやすく、短期間でサプライチェーン全体の信頼を毀損します。国家関与の有無は未確定ですが、標的選ばずの拡散性自体が地政学的リスクを増幅します。

セキュリティ担当者のアクション

優先度順に、実務で即着手できる対策を整理します。

• 依存導入の“スクリプト実行”を原則オフに

  • CI/CDと本番ビルドでnpm/yarn/pnpmは--ignore-scripts、Composerは--no-scriptsをデフォルトにする運用へ移行します。例外は明示的な許可リストで管理します。
  • Yarn Berry等、スクリプト実行を構成で無効化できる仕組みはプロジェクト標準にします。

• ロックファイル固定＋審査ゲート

  • composer.lockとpackage-lock.json/yarn.lockをfrozenモードで運用し、ロック更新はPR審査を必須化します。
  • 依存更新PRでは、package.jsonと依存ツリー内の“install系スクリプト”の差分を自動抽出し、ネットワーク呼び出しや実行権付与を含む場合はセキュリティ承認を必須にします。

• 依存インストール工程のネットワーク制御

  • CIのアウトバウンドをパッケージレジストリ（Packagist/Composerリポジトリ、npmレジストリ、社内キャッシュ）に限定し、GitHubのリリース/CDN/Rawドメインへの直接アクセスをブロックします。必要時はダイジェスト固定のミラー経由にします。
  • 社内アーティファクトリ（JFrog/Nexus等）で外部依存のキャッシュ・検疫（スキャン合格まで隔離）を標準化します。

• 観測と検知

  • EDR/SIEMで「親: npm|yarn|pnpm|node|composer → 子: curl|wget|bash|chmod|sh」のルールを追加し、CIランナーと開発端末双方に適用します。
  • インストール時の外向き通信先を記録し、githubusercontent系や未知ドメインへのアクセスが発生したジョブを自動で赤旗にします。
  • SBOMの継続生成と、install/preinstall/postinstall/prepareスクリプトの有無をメタデータとして蓄積し、変化点を検出します。

• 供給元の信頼強化

  • Composerではallow-pluginsを明示許可制にして、プラグインの横入り実行を抑止します。
  • 可能な範囲でソースビルド由来のアテステーション（署名・プロビナンス）を活用し、リリース資産直落としのパターンを避けます。

• 運用是正

  • 本番サーバでcomposer/npmインストールを実行する設計を廃止し、ビルド済みアーティファクトをデプロイするモデルへ移行します。
  • CIのシークレット最小化と短寿命化を徹底し、GITHUB_TOKEN等の権限を最小化します。ランナーはエフェメラルを基本にし、キャッシュは読み取り専用で運用します。

• インシデント対応の観点（念のための初動）

  • 期間を区切り、依存導入ジョブのログから該当の不審通信・コマンド実行を遡及調査します。
  • 影響が疑われるリポジトリのデプロイ鍵・PAT・CIシークレットをローテーションします。
  • ロックファイルが悪性版を固定している可能性を考慮し、安全版へ明示更新のうえ再ビルドします。

メトリクス的に見れば、本件は“発生可能性が高く、緊急の対応価値が高いが、ポジティブ要素は乏しい”タイプのイベントです。平易な緩和策（--ignore-scripts、ネットワーク制御、審査ゲート）で被害面積を大きく縮められるため、まずはCIの標準テンプレートに対策を折り込み、例外運用をゼロから見直すことをお勧めします。

参考情報

• 報道まとめ（The Hacker News）: https://thehackernews.com/2026/05/packagist-supply-chain-attack-infects-8.html

以上、PickUpでした。依存管理の“当たり前”に小さなほころびが生まれたとき、攻撃者はそこを必ず突いてきます。スクリプトはコードです。今日から扱いを一段引き上げていきましょう。