Laravel Langサプライチェーンに関する注意喚起

Laravel-Langサプライチェーン攻撃：過去のPackagistバージョン700件以上が侵害

更新 - 2026年5月25日：進行中の調査で新たに判明した内容を反映するため、この記事を更新しました。今回の更新では、侵害の仕組みを明確化し、フォークを使った公開手順に関する以前の記述を差し替え、Composer/Packagistユーザーがプロジェクトへの影響を確認する方法を追加しました。影響を受けたバージョン番号は後に正規のコードへ再割り当てされたため、バージョン番号だけでは影響の有無を確認できない場合があります。Snykをご利用のお客様は、「SnykでLaravel Langサプライチェーン攻撃を検出する」セクションで、更新されたスキャン、トリアージ、修復のガイダンスをご確認ください。

要点

2026年5月22日と23日、攻撃者はPackagistのlaravel-lang名前空間で公開されている、コミュニティが保守するLaravelローカライゼーションライブラリ4件について、過去のリリースタグを使って悪意あるバージョン数百件を再公開しました。

仕込まれたhelpers.phpファイルがComposerのautoload.filesエントリに登録されており、パッケージのインストール直後からPHPリクエストのたびに実行される状態でした。このフックはflipboxstudio[.]infoに接続してクロスプラットフォーム対応の第2段階ペイロードをダウンロードし、クラウドキー、KubernetesやVaultのシークレット、CI/CDトークン、SSH関連データ、環境ファイル、ブラウザデータ、パスワードマネージャーの保管庫、暗号資産ウォレット、メッセージングトークンを収集する認証情報窃取プログラムを実行します。

影響を受けたバージョンのLaravelローカライゼーションライブラリを取得した環境は、影響がないと確認できるまで、侵害されたものとして扱ってください。

影響を受けたコンポーネントについて

対象となるパッケージは、PackagistおよびGitHubのlaravel-lang/*名前空間にあります。

Laravelコミュニティで広く採用されており、70を超える言語の翻訳文字列、バリデーションメッセージ、HTTPステータスの説明など、ローカライズされたアセットの提供に使われています。

これらのパッケージはLaravelコアチームが保守しておらず、公式Laravelフレームワークの一部でもありません。ただし、一般的なLaravelアプリケーションのディレクトリにインストールされ、他のローカライゼーションヘルパーの推移的依存関係として含まれることもよくあります。Composer経由で取得され、composer.jsonを通じて登録されるため、パッケージに含まれる悪意あるコードはアプリケーションの実行環境によって自動的に読み込まれ、実行されます。

影響を受けたパッケージ

以下の4パッケージは、公開済みの全バージョンが侵害されたものとして扱われました。Packagistは一時的にパッケージを非掲載にしましたが、修復後に再掲載されています。

研究者による初期の推定では、汚染されたバージョンは約233件でしたが、攻撃者がタグの公開を続けたことで件数は増加しました。現在の報告では、4パッケージにわたり過去のバージョン約700件が確認されています。

確認されているタイムライン

侵害の仕組み

攻撃者は、最近発生したGitHubのデータ侵害に起因すると推測される、漏えいしたGitHub Personal Access Token（PAT）を使って、侵害されたリポジトリにアクセスしました。このアクセス権を利用し、4つのlaravel-lang/リポジトリのリリースタグの多く、またはすべてを、マルウェアを含む攻撃者自身のコミットを指す偽装タグに置き換えました。その他の正規リポジトリは、過去のコミットを含め、侵害期間を通じてそのまま残されていました。

悪意あるタグが設定されると、影響を受けたバージョンを解決する新たなComposerインストールによって、偽装コミットのコードがダウンロードされました。ペイロードは新たに追加されたsrc/helpers.phpに隠され、composer.jsonのautoload.filesに登録されていました。この一覧にあるファイルはすべてComposerのオートローダーによって無条件に読み込まれるため、悪意あるコードはコマンド、バックグラウンドワーカー、キューハンドラーを含むPHPリクエストのライフサイクルの最初に実行されます。

ペイロードの挙動

src/helpers.phpに埋め込まれた第1段階のコードは、意図的に軽量化されています。ホストごとの一時ディレクトリに感染マーカーを書き込み、そのホストが一度だけ感染するようにした後、https://flipboxstudio\[.\]info/payloadから第2段階のペイロードを取得してバックグラウンドで実行します。起動処理はプラットフォームに応じて動作し、Linux、macOS、Windowsに対応しています。

第2段階は、認証情報やシークレットを窃取するプログラムです。実行されると、価値のある情報を探して多数の場所を調べます。

• クラウドプロバイダーの認証情報とトークン（AWS、GCP、Azureのプロファイルファイルなど）。

• Kubernetesのkubeconfigファイル、HashiCorp Vaultトークン、環境内に存在するCI/CDシークレット。

• SSH秘密鍵およびknown_hostsデータ。

• データベース、API、サービスの認証情報を含むアプリケーションの.envファイル。

• Cookie、閲覧履歴、保存されたログイン情報などのブラウザデータ。

• ディスク上でアクセス可能なパスワードマネージャーの保管庫。

• 暗号資産ウォレットのファイルとキーストア。

• Slack、Discord、Telegramなどのツールのメッセージングおよびコラボレーション用トークン。

収集したデータは暗号化され、https://flipboxstudio\[.\]info/exfilに送信されます。流出後、フォレンジック調査による復元を困難にするため、窃取プログラムは自身が配置したファイルの削除を試みます。Windowsホストでは、チェーンに.vbs起動スクリプトと、感染システムで確認されたDebugChromium.exeという実行ファイルが含まれます。

侵害の痕跡（IoC）

影響を受けたシステムの調査には、以下の侵害の痕跡を使用してください。C2ドメインとURLは悪意あるものとして扱ってください。

検出とスキャンのガイダンス

2026年5月22日から23日の間に4つのパッケージのいずれかを解決したホストは、再構築済みであっても、すべて調査対象として扱ってください。最も迅速に確認できるのは依存関係レベルです。各プロジェクトのcomposer.lockとcomposer.jsonを調べ、上記のlaravel-langパッケージが参照されていないか確認してください。具体的な確認方法を以下に示します。

• ビルドおよびデプロイの成果物を検索し、laravel-lang/lang、laravel-lang/http-statuses、laravel-lang/attributes、laravel-lang/actionsが含まれていないか確認してください。composer.lockに記録されているバージョンと整合性ハッシュを控えます。

• インストール済みのvendor/laravel-lang/*/を調べ、src/helpers.phpの有無を確認するとともに、composer.jsonのautoloadにあるfilesキーに登録されていないか確認してください。正規のローカライゼーションパッケージが、すべてのリクエストで自動読み込みされるhelpersファイルを含む理由はありません。

• LinuxおよびmacOSホストでは、$TMPDIRと/tmpに.laravel_localeディレクトリがないか確認してください。中に何らかのファイルがあれば、コードが実行されたことを示します。フォレンジック分析のため、クリーンアップの前に保存してください。

• Windowsホストでは、ユーザーの一時ディレクトリ（通常は%TEMP%）を検索し、ランダムな16進数8文字のファイル名を持つ.vbsドロッパーが含まれる.laravel_localeフォルダーを探してください。さらに、ファイルシステム全体を検索し、DebugChromium.exeという名前の実行ファイルがないか確認してください。

• 送信プロキシ、DNS、ファイアウォールのログを確認し、flipboxstudio[.]infoへの名前解決や接続がないか調べてください。リゾルバーとネットワーク境界の両方で、このドメインをブロックしてください。

• EDRおよびエンドポイントのログで、予期しないphpまたはCScriptプロセスのバックグラウンド実行を調査してください。LinuxおよびmacOSでは、認証情報窃取プログラムがシークレット収集時にアクセスする/var/run/secrets/と`/proc/[pid]/environ`からの読み取りも監視してください。

無視に関するガイダンスの補足

侵害の性質とその後の修復対応により、Snykのシステムが現在認識できるのは、インストール済みの最新バージョンのみの場合があります。悪意あるパッケージが2026年5月22日から23日の間にインストールされていたか確認するため、過去のスキャンを実施してください。最新バージョンのステータスだけを根拠にしないでください。侵害期間中に4つのパッケージのいずれかをインストールしたホストは、影響がないと確認できるまで、影響を受けたものとして扱ってください。

SnykでLaravel Langサプライチェーン攻撃を検出する

Snykユーザー向けには、Open Source製品とSnyk Vulnerability Databaseで、影響を受けたパッケージの全バージョンにすでにフラグを付けています。侵害期間中、悪意あるタグには正規のバージョン番号が付けられていました。プロジェクトの復旧時には、同じ正規タグが悪意あるコミットから切り離されたため、バージョン番号だけでは、インストール済みパッケージがこの侵害の影響を受けたか、または受けていたかを判断できません。（上記の「侵害の痕跡」と「検出とスキャンのガイダンス」を参照してください。）Composerベースのリポジトリをすぐにスキャンし、モノレポと共有プラットフォームコードを重点的に確認してください。

composer.lock、ビルドまたはインストール時期、入手可能な侵害の痕跡を確認し、プロジェクトが影響を受けていないと判断できた場合は、SnykのIgnore機能を使って今後のスキャン結果にこの問題が表示されないようにできます。詳しくはSnykの問題の無視に関するドキュメントをご覧ください。

Snyk CLIはComposerのロックファイルを自動的に検出し、脆弱なパッケージと悪意あるパッケージを検出します。

1snyk test

Snyk CLIは無料です。まだインストールしていない場合は、Snyk CLIユーザードキュメントに従ってください。

SnykをGitリポジトリに接続すると、composer.lock内の脆弱なパッケージを安全なバージョンに更新するPRを、Snykが自動的に作成できます。

Snyk Enterpriseをご利用のお客様に代わってスキャンを再実行しました。Analytics → Reports → Zero-Day → Active Security Incident Assessmentで、Laravel-Langサプライチェーン攻撃の評価結果をご確認いただけます。

緩和策と修復

影響を受けたパッケージがインストールされていたことが確認された場合、実行時にPHPプロセスから読み取り可能だった情報はすべて流出したものと想定し、適切に対応してください。以下の順序は、一般的なインシデント対応の手順に沿っています。

• 影響を受けたホストを隔離してください。影響を受けたバージョンを実行していたインターネット公開サービスを稼働対象から外し、フォレンジック用にディスクスナップショットを取得したうえで、その場でクリーンアップするのではなく、信頼できるクリーンなイメージから再構築してください。

• 影響を受けたLaravel Langのパッケージ一式（および、このメンテナー／チームが管理する他のパッケージも含まれる可能性があります）を取得しないでください。攻撃者が過去のGitタグを書き換えたため、公開されているバージョン番号だけでは信頼できません。古いリリース番号が、現在は悪意のあるコミットを指している可能性があります。

• PHPプロセスが読み取れた可能性のある認証情報をすべてローテーションしてください。クラウドプロバイダーのキー、データベースのパスワード、キューおよびキャッシュの認証情報、サードパーティAPIトークン、OAuthクライアントシークレット、SSHキー、署名キー、VaultおよびKubernetesのトークン、CI/CDから注入されたあらゆるシークレットが対象です。

• 同じワークステーションを使っているユーザーアカウントを監査してください。ブラウザーに保存されたログイン情報、パスワードマネージャーの保管庫、暗号資産ウォレット、SlackやDiscordのトークンも盗まれた可能性があります。ブラウザーに保存されたパスワードを変更し、セッションを無効化して、MFAの登録状況を確認してください。

• C2ドメインをブロックしてください。DNSシンクホール、プロキシの拒否リスト、EDRの検知ルールにflipboxstudio[.]infoを追加してください。名前解決が一度でも試みられた場合、侵害を示す強い兆候です。

• laravel-lang/*が推移的に取得されていた可能性があるため、SCMとレジストリの権限を監査してください。自社のGitHub、GitLab、Packagist組織で、ハードウェアベースのMFA、スコープを限定したトークン、タグ作成とパッケージ公開のレビュープロセスが設定されていることを確認してください。

教訓と多層防御

今回のインシデントは、パッケージの信頼境界がブラウザーのタブで開いているソースリポジトリではないことを改めて示しています。公開アーティファクトとなるコミットを決定するシステムの連鎖こそが、信頼境界です。同様の攻撃による被害を抑えるために、次の対策が有効です。

• インストール時に完全性を検証してください。Composerはパッケージのコンテンツハッシュをcomposer.lockに記録します。CIで--no-cacheと完全性検証を使用し、改ざんを検知できるようにしましょう。

• ビルド環境に送信先制御を導入してください。CIランナーと本番コンテナから、任意のドメインにアクセスできないようにします。許可リストを使用していれば、今回の第2段階のダウンロードは防げたでしょう。

• 有効期間が短く、スコープを限定したシークレットを使用してください。.envファイルに長期間有効な認証情報を置くと、プロセス内でシークレットが盗まれた場合の被害が拡大します。

GitHubに関する詳細を含む、影響を受けたプロジェクトの公式声明はこちらです。インシデントに関する公式声明。

セキュリティ対策を見直すとともに、以前公開した記事Laravel PHPフレームワークを安全に使う方法と、安全なPHP開発のためのSnyk Learnのリソースもご確認ください。

Snykの対応状況

Snykの製品およびインフラは今回のインシデントの影響を受けていません。影響を受けたパッケージに関するSnykのアドバイザリは公開済みで、確認された新たなバージョン範囲に応じてSnyk Vulnerability Databaseを更新しています。Snykは引き続き状況を監視し、詳細が明らかになり次第、このアドバイザリを更新します。