【2026年5月22日発生】Laravel-Lang を狙ったサプライチェーン攻撃の特徴と対応策を解説

2026年5月22日から23日にかけて、PHP / Laravel エコシステムで広く利用されている laravel-lang/* 系パッケージを起点とした大規模なサプライチェーン攻撃が発生しました。攻撃者は新しい悪意あるバージョンを「追加」したのではなく、過去にさかのぼって既存のリリースタグをすべて書き換えるという手口を取り、最終的に4パッケージ・約700もの過去バージョンが侵害されました。

侵害されたバージョンには src/helpers.php というファイルが仕込まれ、Composer の autoload.files に登録されることで、アプリケーションの起動時に自動実行されます。実行されたコードは flipboxstudio[.]info からクロスプラットフォーム対応の第2ステージをダウンロードし、クラウド・CI/CD・SSH・ブラウザ・暗号資産ウォレットなど、現代の開発環境にあるほぼあらゆる認証情報を窃取しました。

最大の特徴は、攻撃者がコードの脆弱性ではなく、「リリースタグは不変（immutable）である」「同じバージョン番号なら中身は同じである」という、OSS エコシステムが暗黙に置いてきた前提を突いたことです。「タグを打てば公開内容は確定する」という前提が崩されたインシデントとして、Composer / Packagist を利用するすべての開発者が対応を迫られる事案と言えます。

本記事では、攻撃の特徴・対応策、そして Composer / Packagist を利用する立場で取るべき対応を解説します。

国内唯一のISMAP登録済
脆弱性管理ツール

サマリー

今回の攻撃の 3 つの特徴

① 既存リリースタグの一斉書き換え

攻撃者は新しいバージョン（例: 15.29.6）を公開するのではなく、laravel-lang/lang の 502 個すべてのタグを含む過去の全リリースタグを、悪意あるコミットを指すように force push で書き換えました。

これにより、15.29.5 のようなバージョン番号はそのままに中身だけがすり替わるという状態が生まれます。同じ 15.29.5 という番号が、取得タイミングによってクリーンなコードを指すこともあれば、マルウェアを指すこともあるため、「どのバージョンが安全か」をバージョン番号だけで判断できなくなりました。

② Composer の autoload.files を悪用した自動実行

Composer のオートロードには 3 つの方式があります。

• psr-4
• classmap
• files

psr-4 と classmap は遅延読み込み（クラスが参照されたときに初めてロード）ですが、files だけは即時読み込みで、vendor/autoload.php を require した瞬間に列挙されたファイルがすべて require されます。

攻撃者は悪意ある src/helpers.php を composer.json の autoload.files に登録しました。Laravel・Symfony・PHPUnit など主要な PHP フレームワークは起動時に必ず vendor/autoload.php を読み込むため、クラスのインスタンス化も特別なトリガーも不要で、アプリケーションが起動した瞬間にペイロードが実行されます。

③ 多段構成のクロスプラットフォーム・認証情報窃取ツール

src/helpers.php 自体はローダー（本体を呼び込むコード）にすぎず、本体は外部から取得される第 2 ステージです。これは Linux / macOS / Windows に対応した十数種類の「コレクタ（収集モジュール）」で構成される約 5,900 行の PHP 製の窃取ツールで、収集対象は PHP / Laravel 環境にとどまりません。窃取後は痕跡を残さないようドロップしたファイルを自己削除する設計になっていました。

事象の解説

時系列タイムライン

影響を受けたパッケージ

対象はいずれも Laravel-Lang 組織（GitHub）がコミュニティ主導でメンテナンスしているローカライズ用のサードパーティライブラリであり、Laravel 公式フレームワークの一部ではありません。ただし、Composer 経由で導入され composer.json に登録されるため、悪意あるコードはアプリケーションのランタイムによって自動的に実行されます。

今回の攻撃は新バージョンの「追加」ではなく既存タグの書き換えであるため、^3.4・~2.0・* のようなバージョン範囲指定で依存しているプロジェクトが composer update を実行すると、汚染されたタグに解決されてしまいます。

攻撃メカニズム

リポジトリへの侵入：漏洩した GitHub PAT

攻撃者は、流出した GitHub Personal Access Token（PAT）を用いて Laravel-Lang 組織への書き込み権限を取得したと見られています。この PAT は、近時の GitHub 関連のインシデントで流出したものと推定されています。リポジトリのコミット履歴やブランチといった既存の正規コードはそのまま残されており、攻撃はあくまでタグの書き換えという形で行われました。

タグの書き換え（force push）

ここで言うタグの「書き換え」とは、タグ名（バージョン番号）はそのままに、そのタグが指すコミット（参照先）を別のコミットへ差し替えることを指します。ブランチやコミット履歴そのものは改変されません。

攻撃者は、自分が作成した悪意あるコミットを指すように、既存のリリースタグを force push で書き換えました。これらの悪意あるコミットはどのブランチからも到達できない状態で、タグのターゲットとしてのみ push されています(該当コミット)。これはImpostor Commit と呼ばれ、GitHub の Fork Network を悪用し、 Fork したリポジトリに悪意のあるコミットを生成してあたかも元のリポジトリの安全なコミットであるかのように見せかける攻撃手法です。GitHub のコミット画面に表示される「This commit does not belong to any branch」というバナーが、その特徴を示しています。

攻撃前: 15.29.5 → 9a1d194c…（クリーンなコミット）
攻撃後: 15.29.5 → a5ea2e8f…（悪意あるコミット）

書き換え後の偽コミットは、いずれも composer.json と src/helpers.php の 2ファイルのみを変更しており、コミット著者は Your Name <you@example.com> という同一の偽の identity に統一されていました。4パッケージすべてで同じ偽の著者・同じ変更ファイル・同じペイロード挙動が確認されており、組織全体への push 権限を持つ1つの認証情報を用いた単独の攻撃者の犯行とほぼ断定できます。

autoload.files による自動実行

書き換え後の composer.json では、autoload.files に src/helpers.php が追加されています。前述のとおり files 方式は即時読み込みであるため、composer install / composer update でこのコミットを取得したプロジェクトでは、vendor/autoload.php を読み込むタイミングでペイロードが発火します。

影響を受けたかどうかの確認

タグの書き換えという手口の性質上、影響の有無は「いつ、どのように依存を取得したか」で大きく変わります。

ただし、composer update を控えれば安全という理解は正確ではありません。今回は「既存バージョンのすり替え」でしたが、権限を奪った攻撃者が正規の新バージョンとしてマルウェアを公開すれば、同じ攻撃は成立します。composer update の抑制は今回型の攻撃には有効な一手ですが、完全な防御ではない点に注意が必要です。

なぜ lockfile ありの install は比較的安全なのか：Composer の挙動

composer install は、composer.lock に記録された内容をそのまま信頼して依存を取得します。lockfile には各パッケージのコミット SHA（reference）が記録されており、Git のコミット SHA は内容から計算される SHA-1 ハッシュです。同じ SHA で異なる内容のコミットを作ることは現実的に不可能なため、lockfile に記録された SHA がクリーンなコミットを指している限り、上流のタグが force push で書き換えられても、composer install は元のクリーンなコードを取得します（GitHub から元コミットが完全に削除されていない限り）。

緊急対応（感染が疑われる場合）

対象 4 パッケージのいずれかに依存しているプロジェクトでは、攻撃期間（2026-05-22 22:32 UTC 以降）に依存を取得した可能性がある環境を「侵害された前提」で扱い、以下の手順でトリアージを進めてください。「あれば侵害確定だが、なければセーフ確定とは限らない」点に留意してください。

手順 1. 影響範囲の確認

① IoC（侵害指標）の確認

一時ディレクトリ配下のマーカーディレクトリやドロップされたファイルを確認します。ただし、ドロップされたファイルはペイロード実行後に数秒で自己削除されるうえ、/tmp 自体も揮発するため、検出されなくても安全の証明にはなりません。

# マーカーディレクトリ
find /tmp /var/tmp /private/tmp -name ".laravel_locale" 2>/dev/null

# ドロップされた不審ファイル
find /tmp \( -name "*.vbs" -o -name "*.php" \) 2>/dev/null

Windows では %TEMP% 配下の .laravel_locale フォルダ、8 桁の 16 進数を名前に持つ .vbs ファイル、および DebugChromium.exe の有無を確認します。これらが存在した場合は侵害確定と考えてください。

② helpers.php の存在確認

正規のローカライズパッケージが、リクエストごとに自動実行されるヘルパーファイルを同梱する理由はありません。vendor 配下に侵害済みファイルがあるか、それが autoload.files に登録されているかを確認します。

# 侵害済みファイルの有無
hits=$(find . -type f -path 'vendor/laravel-lang/*/src/helpers.php' 2>/dev/null)
[ -n "$hits" ] && echo "⚠️ FOUND: $hits" || echo "✅ NOT FOUND"

# autoload への登録有無
grep -n 'laravel-lang' vendor/composer/autoload_files.php 2>/dev/null \
  && echo "⚠️ REGISTERED" || echo "✅ NOT REGISTERED"

なお、この検知は composer install 済みで vendor ディレクトリが存在することが前提です。lockfile だけでは helpers.php の有無は判定できません。

③ composer.lock の reference 確認

composer.lock にロックされているコミット SHA を確認します。ロックされた SHA が偽コミットのものである場合、あるいは lockfile 自体が攻撃期間以降に再生成されている場合は侵害扱いとします。
正規のコミットハッシュかどうかは Packagist や GitHubリポジトリからご確認ください。

cat composer.lock | grep -A5 '"laravel-lang/lang"' | grep reference
# "reference": "9a1d194c…" → ✅ クリーン
# "reference": "a5ea2e8f…" → ⚠️ 侵害済みコミット

④ install 実行タイミングの確認

タグの大規模な書き換えは 2026-05-22 22:32 UTC ごろに始まりましたが、これは初動の一波にすぎません。その後も5月23日にかけて悪意あるタグの公開が断続的に続き、侵害バージョン数は約233から約700へと増加しました。リスク期間は、2026-05-22 22:32 UTC 以降、Packagist が悪意あるバージョンを削除する5月23日までと考えるべきです。vendor ディレクトリの更新日時や CI/CD のログから、この期間に composer install / composer update が実行されていないかを確認します。

stat vendor/laravel-lang/lang/composer.json
git log --format="%ai %s" | grep -i "composer\|vendor\|install"

手順 2. 影響ホストの隔離と保全

攻撃期間以降に対象パッケージを取得・実行した可能性がある環境は、ネットワークから切り離します。インターネットに面したサービスはローテーションから外し、フォレンジック用にディスクスナップショットを取得したうえで、その場での駆除ではなく既知のクリーンなイメージから再構築してください。composer.lock・Composer キャッシュ・各種ログ（プロセス実行、ネットワーク / DNS、クラウド監査）は浄化前に保全します。

手順 3. シークレットの即時ローテーション

侵害環境では「そのユーザー権限で読めるファイルはすべて窃取されうる」と考えます。PHP プロセスが読み取り可能だったすべての認証情報を「変更」ではなく「失効（Revoke）」させたうえで、新しいキーを発行してください。

対象には、クラウドプロバイダのキー（AWS / GCP / Azure）、Kubernetes / Vault トークン、CI/CD シークレット、GitHub / GitLab トークンと PAT、データベース認証情報、SSH 秘密鍵、Laravel の APP_KEY、各種 API キー・OAuth クライアントシークレットなどが含まれます。

あわせて、ブラウザのセッション窃取は MFA / Passkey を含む認証をすべて迂回します。盗まれた Cookie をセットするだけでログイン済み状態が再現されるため、主要な SaaS では「全セッションを切断する」機能を実行し、開発端末を共有する各アカウントのブラウザ保存パスワード・パスワードマネージャーも見直してください。

手順 4. C2 ドメインのブロックと監視

flipboxstudio[.]info を DNS シンクホール、プロキシの拒否リスト、ファイアウォール、EDR の検知ルールに追加します。egress プロキシ・DNS・ファイアウォールのログを遡り、このドメインへの名前解決や接続が発生していないかを確認してください。たとえ 1 回の名前解決であっても、暴露の強いシグナルです。

なお、本記事執筆時点で flipboxstudio[.]info の A レコードは削除されています。早期段階では DNS 解決履歴や接続履歴の確認が有効でしたが、現在は痕跡が残っていない可能性があります。

自衛の強化

今回のような攻撃を前提に、平時の防御策を見直す必要があります。

クールダウン戦略：リリース直後のバージョンを取り込まない

サプライチェーン攻撃は「発見 → アドバイザリ発行 → スキャナ反映」までに数時間〜半日のラグがあります。逆に言えば、新規リリース直後のバージョンを即座に取り込まず、数日間の「クールダウン（待機期間）」を置くだけで、今回のような侵害の多くを踏まずに回避できます。実際、近年の主要なサプライチェーン攻撃の多くは、悪意あるバージョンの公開から数時間〜数日で検知・削除されています。

ただし注意点として、Composer 自体には、現時点でネイティブのクールダウン機能がありません。npm（min-release-age）、pnpm・Bun（minimumReleaseAge）、Yarn（npmMinimalAgeGate）、Deno、uv、pip など他の主要なパッケージマネージャが「公開から N 日経過したバージョンしかインストールしない」設定を備えているのに対し、Composer は未対応です。

そのため Composer では、依存更新ボットを使って間接的にクールダウンを効かせるのが現実的な手段になります。

• Renovate: minimumReleaseAge でクールダウン期間を指定できます。
• Dependabot: dependabot.yml の cooldown 設定で、更新種別（major / minor / patch）ごとに待機日数を指定できます。

なお、Composer 本体にネイティブのクールダウン機能を求める Issue（composer/composer#12633）はすでに提起されており、実装に向けたプルリクエストも進行しています。

サプライチェーンの脆弱性を可視化する 脆弱性管理クラウドyamoryのご紹介

株式会社アシュアードが提供する脆弱性管理クラウド「yamory」は、システム内に潜む脆弱性などのITリスクの検知から対応の優先度付けまでを自動で行う、国産のクラウドサービスです。

yamoryを使えば、重大な脆弱性が発生したときでも、「どのプロジェクトで、どのバージョンの該当パッケージが利用されているか」を即座に特定することが可能です。

幅広いレイヤーのITリスクを一元管理

クラウド・オンプレミス環境に問わず、インフラからアプリレイヤー内のITリスク（脆弱性・EOL・OSSライセンスリスク・クラウド設定不備）を一元管理することができます。

分かりやすいダッシュボードで結果を可視化

お使いのシステム環境に合わせて、検出したITリスクの対応優先度を自動で判別し、結果をダッシュボードに可視化。専門家でなくてもリスクの状況をひと目で把握することができます。

間接依存関係にあるライブラリの脆弱性も瞬時に発見

ライブラリの依存関係をツリー構造で可視化。間接依存関係にあるライブラリの脆弱性も瞬時に発見することができます。

政府認定のクラウドセキュリティ評価制度『ISMAP』に登録された唯一の脆弱性管理ツール

yamoryは、政府情報システムのためのセキュリティ評価制度『ISMAP』において、
「唯一、SBOM・脆弱性管理ツールとして登録された国産クラウドサービス」です。

経済産業省が策定した「ソフトウェア管理に向けたSBOMの導入に関する手引」においても、唯一の有償国産ツールとして紹介され、数多くの企業様に導入いただいております。

• 重大サプライチェーン攻撃が発生したとき、すぐに該当パッケージが自社システムで使われているかを確認したい。
• ITリスクを一元管理できるサービスを探している。

というご担当者様。
ぜひこの機会に、ISMAP登録済みのセキュアな基盤で、ITリスク管理をスタートしませんか？

国内唯一のISMAP登録済
脆弱性管理ツール

■参考文献

• ThreatLocker「Reverse Shai-Hulud: Supply chain compromise impacts @antv packages」
• Aikido Security「Mini Shai-Hulud strikes again: npm worm compromises hundreds of @antv packages」
• JFrog Security Research「Shai-Hulud Returns: npm Worm hits @antv in latest ongoing campaign」
• Microsoft Security Blog「Mini Shai Hulud: Compromised @antv npm packages enable CI/CD credential theft」
• Upwind「The New Face of Supply Chain Attacks: npm Malware Built for CI/CD and Cloud Compromise」
• The Hacker News「Mini Shai-Hulud Pushes Malicious AntV npm Packages via Compromised Maintainer Account」