Laravel Langサプライチェーン攻撃｜Packagist侵害4パッケージ最大700版とPHP autoload経由クロスプラットフォーム窃取

PHP/Laravelエコシステムを直撃するサプライチェーン攻撃が、2026年5月22日にAikidoの脅威インテリジェンスチームによって発覚しました。
日本のニュース系媒体では「Linuxマルウェア混入」と報じられた本件ですが、一次情報をたどると実態はクロスプラットフォーム（Linux／macOS／Windows）対応のクレデンシャル窃取マルウェアであり、被害の本質は「開発者の手元から各種シークレットが抜かれる」点にあります。

この記事では、laravel-lang ネームスペース配下の人気多言語化パッケージが侵害された手口を攻撃者視点で分解し、Composer 利用環境に潜む依存検査の盲点と、現場の開発・運用チームがいま実行すべき具体的なチェックリストを整理します。
入門記事ではなく、すでにPHP/Laravelで開発・運用しているチームが「自分のところでも踏んでいないか」を見極めるための速報分析として読んでください。

laravel-lang 侵害事案の全体像

本件の対象は、Packagist 上で laravel-lang ネームスペースで公開されている Laravel 多言語化系パッケージ群です。
具体的に侵害が確認されたのは以下の3パッケージ＋関連1パッケージで、laravel-lang/lang は約7,800のGitHubスター数を持つ広く使われたパッケージです（出典: Aikido Threat Intel）。

・laravel-lang/lang: Laravel本体に複数言語の翻訳メッセージを提供する代表的パッケージ
・laravel-lang/attributes: バリデーション属性の多言語化
・laravel-lang/http-statuses: HTTPステータスコードの多言語訳
・laravel-lang/actions: アクション名の多言語化（侵害の可能性ありとして調査中）

侵害された範囲は、Aikidoの直接調査で233のバージョンタグ、Socketによる広域調査で最大700のヒストリカルバージョンに及ぶと報告されています（出典: BleepingComputer）。
過去のリリースタグまで丸ごと書き換えられている点が本件の特徴であり、「古いバージョンに固定しているから安心」とは言えない構造になっています。

攻撃手口の核心：GitHubタグ書換とComposer autoload

本件の攻撃が「単なる悪意あるパッケージ公開」と一線を画すのは、攻撃者がGitHubの仕様の盲点を突いた点です。
攻撃者は新しい悪意あるバージョンを公開するのではなく、既存の正規バージョンタグを、攻撃者所有のフォークリポジトリ内のコミットに付け替える手法を使いました（出典: Aikido / BleepingComputer）。

GitHubでは、リポジトリのタグはコミットを指すポインタですが、リポジトリのフォーク間で同一の git オブジェクトを共有しているため、フォーク側のコミットを指すタグを元リポジトリ上に作ることが技術的には可能です。
攻撃者はこの性質を利用し、laravel-lang の正規リポジトリ上で「v3.5.0」のような既存タグを、攻撃者フォーク内の悪意あるコミットへ向け直しました。Packagist はタグから取得したコードをそのまま配信するため、composer install/update した開発者の手元に悪意あるコードが正規版として降ってきたわけです。

仕込まれた `src/helpers.php` は、Composer の autoload 機能で「composerのオートロード対象に登録するだけで自動実行される」位置に置かれていました。
つまり、開発者は侵害版を install しただけで実行コードを読み込み、`composer install` の直後・あるいは Laravel アプリの初回ブートで悪意あるコードが起動する状態に追い込まれていたわけです。

クレデンシャル窃取マルウェアの挙動と漏洩対象

第一段の `src/helpers.php` は「ドロッパー」として機能し、外部C2サーバ（flipboxstudio[.]info）から第二段ペイロードを取得して実行します（出典: Aikido / BleepingComputer）。
第二段は約5,900行のPHPコードで実装された包括的なクレデンシャル窃取マルウェアであり、その対象範囲は実用上「開発者の手元にあるすべての秘密」と言っていいほど広範です。

具体的な漏洩対象は以下のように分類できます（出典: Aikido）。

窃取された情報はAES-256で暗号化され、攻撃者のサーバに送信された後、ローカルでは自己削除される設計になっています。
痕跡を残さないための洗練された設計であり、開発者のマシンが侵害されたかを後追いで断定するのは容易ではありません。だからこそ、「踏んだ可能性があるなら、踏んだものとして対応する」のが現実解になります。

クロスプラットフォーム性能の本質

日本国内の一部報道では「Linuxマルウェア混入」という表現が使われましたが、実態はもっと広く、PHPコードベースで書かれているため動作環境を選びません（出典: Aikido / The Hacker News）。

・Linux／macOS: PHPコードから直接 exec() でstealerペイロードを起動
・Windows: Visual Basic Script ランチャーを生成し cscript 経由で実行
・共通: PHPランタイムが入っているマシンであれば、開発者環境・CIランナー・本番Webサーバを問わず動作可能

Laravel開発の現場では、開発者のmacOS／Linuxノートだけでなく、CIサーバ（GitHub Actions・GitLab CI など）でも `composer install` が走るのが通常です。
したがって、本件の現実的な影響範囲は「PHP開発に関わるすべての実行環境」と捉えるべきで、開発マシン1台の感染を発見しただけで「対応完了」にしてはいけません。

自分の環境が踏んでいるかの確認手順

1. 影響範囲の特定（5分でできる初動）

まず、laravel-lang 配下のパッケージを自プロジェクトが直接・間接的に取り込んでいないか確認します。直接の依存だけでなく、推移的依存（依存先の依存）も含めて見るのが重要です。

# プロジェクト全体で laravel-lang 配下のパッケージを検索
composer show | grep -i laravel-lang

# 詳細な依存ツリーで間接依存まで確認
composer show --tree | grep -i laravel-lang

# composer.lock 内の installed バージョン文字列を直接検査
grep -E '"name": *"laravel-lang/' composer.lock

該当パッケージが見つかったら、`composer.lock` 中の `dist.url` や `dist.reference` のコミットSHAを記録し、Packagist公式が削除した範囲と突き合わせます。Packagist側で該当バージョンが既に削除されていれば、`composer install` の段階でエラーになるはずです。

2. インストール時刻と挙動の痕跡確認

本件は2026年5月20日前後から流通したと見られ、攻撃発覚の22日までに `composer install` または `composer update` を実行した環境は要注意です。
特に確認すべきポイントは次の3つです。

・Composerキャッシュの内容: `~/.composer/cache/files/laravel-lang/` 配下に古い悪意あるtarballが残っていないか
・vendor/laravel-lang/*/src/helpers.php の中身: 正規ファイルにないリモートURL取得処理が含まれていないか
・外部通信ログ: 開発者マシン・CIランナーから `flipboxstudio[.]info` への通信履歴がないか

vendorディレクトリは `composer install` で再生成される性質上、過去の悪意ファイルが消えている可能性もあります。判定の決定打になるのはネットワーク側の通信ログです。

3. 影響を受けた場合の即時対応

侵害が疑われたら、迷わず以下を実施します。中途半端な対応は「ゾンビ化したシークレット」を生み、半年後にどこかから漏洩する遠因になります。

・全クラウドAPI鍵のローテーション: AWS IAMアクセスキー、GCPサービスアカウント鍵、Azureクライアントシークレット等は当該開発者の関連分すべて再発行
・GitHub Personal Access Token・OAuthトークン・Deploy Keys の失効と再発行
・SSH秘密鍵の作り直しと、関連サーバ側の authorized_keys 整理
・npm/pip/Packagist 等のパッケージレジストリトークンの再発行
・ブラウザに保存していたパスワードの全件パスワード変更（パスワードマネージャ移行を兼ねる）
・Slack/Discord/Telegram のセッション全切断＋2要素認証強化
・暗号通貨ウォレットのシードフレーズ確認と、必要に応じ新規ウォレットへの資産移動

サプライチェーン攻撃の構造的な防御戦略

本件のような攻撃は、laravel-lang に限った話ではありません。npm、PyPI、RubyGems、Maven Central、Packagist の歴史を振り返ると、過去数年で同種の事案が繰り返されています。
個別の侵害事案に都度反応するだけでは、構造的な脆弱性は埋まりません。組織として以下のレイヤを積み上げるのが本質的な防御です。

レイヤ1：依存可視化とSBOMの常時更新

自社プロダクトが取り込んでいるOSSパッケージを、直接・間接ともにリスト化したSBOM（Software Bill of Materials）を維持します。
SBOMがあれば、外部から「laravel-lang/lang が侵害された」という情報が流れた瞬間、社内で何分以内に「自社プロダクトのうちXとYが影響あり」と切り分けられます。SBOMがない組織は、この判定に何時間もかかるか、最悪「わからない」と回答することになります。

レイヤ2：依存パッケージのバージョンピンと整合性検査

Composerであれば `composer.lock` のコミット運用、Composer.lockに含まれるハッシュ値の検証を欠かさないことが基本です。
ただし本件はタグ書換攻撃のため、ピンしていても古いタグが新しいコミットを指すようになると `composer install –no-dev` で新しい悪意コードを引き込む可能性があります。`composer install –no-scripts` のような防御は限定的で、autoload の仕組み自体が悪用される本件には効きません。

レイヤ3：CIとシークレット分離

開発者ローカルとCI環境で、シークレットスコープを徹底的に分けます。
本件のように開発者のmacOSノートが侵害される事案では、ノート上で扱える「本番権限」を最小化しておくことが被害局所化の鍵です。本番デプロイは専用CIランナーで、デプロイ鍵は専用HSMやSecret Managerに格納する、といった原則の差が、こうした事故の影響範囲を1桁変えます。

レイヤ4：脅威インテリジェンス連動と自動アラート

Aikido、Snyk、Socket、GitHub Dependabot Security Alertsなどの脅威インテリジェンスサービスを、自社の依存ファイルに連携させます。
無償枠のあるサービスも複数あり、中小企業でも導入のハードルは下がってきました。アラートが鳴ったときに即座にローテーションを開始できる体制が、平時から準備されているかが本番です。

SOC・運用部門が見るべき検知ポイント

SOC側の観点では、PHP/Laravelを使うプロダクトを抱える組織は以下を検知ルール化しておくのが現実的です。

・flipboxstudio[.]info などの新興C2ドメインへの通信: 既知C2リストの即時取り込み
・開発者マシン・CIランナーから外部HTTPS POSTで暗号化バイナリを送る挙動: 巨大POSTボディの監視
・PHPプロセスから cscript.exe / cmd.exe / bash の子プロセス起動: プロセスツリーの異常パターン
・VBSドロップ・実行イベント: Sysmon のプロセス作成イベント（Event ID 1）と組み合わせ

EDR/XDRが入っている環境では、これらのテレメトリを横串でクエリ可能にしておくと、「開発者ノートでcomposer install後30秒以内に外部通信」のようなふるまいベース検知が機能します。シグネチャベース検知は本件のような新興マルウェアに対しては後追いになりがちで、ふるまい検知の強化が本質的な強化です。

クラウド側の二次被害を防ぐ視点

本件で窃取された可能性のあるシークレットは、開発者マシン側でだけではなくクラウド側でも追跡が必要です。
クラウドプロバイダ側のIAMアクティビティログから「想定外のリージョン・想定外のサービス呼び出し・想定外のIPからのアクセス」が発生していないかを必ず確認します。

クラウドの権限分離・最小権限設計の基礎は、姉妹サイトCloudMaster.JPでも継続的に取り上げています。
本件のような事案を契機に「IAMロール棚卸し・AWS Access Analyzerの活用・GCP Recommenderの利用」など、平時から運用していれば本番権限の漏洩リスクを構造的に下げられる施策の導入を検討してください。

よくある質問（FAQ）

Q1. composer install を1回しか実行していません。それでも危険ですか？
A. 危険です。autoload は1回のロードで実行コードが走るため、インストール回数ではなく「侵害版を引き込んだかどうか」だけが判定基準になります。直近の install 履歴と composer.lock の中身を必ず確認してください。

Q2. CIサーバでだけ composer install しています。本番Webサーバは影響を受けますか？
A. CIで生成されたビルド成果物（vendor 含む）が本番に展開される場合、本番側も実行コードを抱えることになります。CIでの侵害は本番侵害と等価として扱ってください。

Q3. Packagist が該当バージョンを削除した今、composer install しても問題ないですか？
A. Packagist側の削除でこれから新規にインストールする経路は閉じられましたが、過去に取り込んでローカルキャッシュに残っている tar や、社内ミラーに残っている可能性があります。キャッシュも含めた除去が必要です。

Q4. クレデンシャル窃取が成功したかどうか確認するにはどうすればいいですか？
A. 100%の確認は困難です。flipboxstudio[.]info への通信履歴があれば「ほぼ確実に窃取された」と判定しますが、ない場合でも「窃取された痕跡が見つからない」止まりです。安全側で「踏んだなら漏れた前提で対応」を取るのが定石です。

Q5. Laravel本体を使っていますが laravel-lang は使っていません。それでも対応が必要ですか？
A. 直接依存にも推移的依存にも含まれていないことを確認できれば、本件の直接的な対応は不要です。ただし、自社で使っている他のサプライチェーンが同種の攻撃を受ける可能性は常にあるため、依存可視化とアラート設定の整備は本件を契機に進めるとよいでしょう。

Q6. 個人開発で laravel-lang を使っていた場合、何を優先すべきですか？
A. ①開発に使っていたマシンで保存していたブラウザパスワードの全件変更、②使っていたGitHub Personal Access Tokenの失効、③クラウドAPI鍵の再発行、④暗号通貨ウォレットを扱っていた場合は資産移動の検討、の順で実施してください。

Q7. Composer 以外のパッケージマネージャでも同じことが起きますか？
A. はい、起きます。npm／PyPI／RubyGems／NuGetなど、Gitタグや任意のリポジトリリリースを取得する仕組みを持つすべてのエコシステムで同様のリスクがあります。本件はComposerでしたが、他言語のチームも他人事と捉えないことが重要です。

本記事のまとめ

laravel-lang サプライチェーン攻撃は、「正規パッケージの過去タグを攻撃者フォークに付け替える」という、現代のサプライチェーン攻撃の典型的な進化形を示しました。
影響を受ける可能性のあるPHP/Laravel開発チームは、composer.lockによる固定だけでは防げないこと、Composer autoload の構造そのものが攻撃面になりうることを、改めて認識する必要があります。

個別事案への対応はもちろん必要ですが、本質的にはSBOMの整備、依存可視化、シークレットスコープの分離、脅威インテリジェンスの常時連動の4本柱が、こうした攻撃の影響範囲を構造的に縮める唯一の道です。
中小企業の開発・運用チームでも、無償ツールを組み合わせれば最初の一歩は踏み出せます。本件を契機に、まずは「自社のSBOMを1本作る」ことから始めてみてください。