2026年5月22日、Laravel関連のパッケージ「Laravel-Lang」が乗っ取られる事件が発生しました。composer update 後にアプリを動かすと認証情報が盗まれてしまう、というかなり深刻な内容です。
手口はかなり巧妙です。
現在は感染パッケージは削除されています。ただ、過去にインストールしてしまった可能性がある場合は、確認と対応が必要です。
どんな手口だったか。感染チェック方法、今後の対策もお伝えします。
Laravel Langとは？
Laravelの多言語対応ライブラリです。laravel-lang/lang はGitHubで7,800スター以上を獲得している人気パッケージで、日本語化以外の用途でも広く使われています。
わたしはあまり使っておらず、自身でも、コンテンツでも、breezejpを使ったり、すすめたりしています。
攻撃の仕込み
2026年5月22日 22:32 UTC（日本時間で5月23日 朝7:32頃）、攻撃者が Laravel-Lang のGitHub組織への書き込み権限を取得。
どのようにLaravel-Langの書き込み権限を取得したかは、まだはっきりしていません。
攻撃者は、4つのパッケージのバージョンタグを一斉に書き換えました。影響を受けたパッケージは下記の4つです。
laravel-lang/langlaravel-lang/attributeslaravel-lang/http-statuseslaravel-lang/actions
これで仕込み完了となります。
なぜバージョンタグが狙われたのか
バージョンタグとは、リポジトリの中のあるコミットに名前をつけたものです。「どのコミットを正式版とみなすか」を示す仕組みとなります。
バージョンタグを書き換えるだけなら、リポジトリ本体のコードは変わりません。そのために、ここが狙われたのでしょう。
バージョンタグを使って、見つかりにくくしているのです。
なおタグが指すコミットは、元のリポジトリの中である必要がありません。攻撃者はこの仕様を利用して、タグの参照先を悪意あるコードへ切り替えました。
感染方法
タグが指す場所が切り替わったので、ユーザーがcomposer update や composer install を実行すると、composer は、新しく指定されたコードをとってきます。
つまり攻撃者が用意した悪意あるコードをダウンロードしてしまうのです。
ダウンロードしたコードは、vendorディレクトリの中に入ります。
開発者の手元では、いつも通り composer update が成功したように見えます。
わかりやすく言いますと、正規の出版社の本に、カバーだけは正規のものをつけて、中身を別の本にすり替えた感じです。
仕掛けられたコード-helpers.php
攻撃者が用意したコードには、src/helpers.php というファイルが含まれていました。
このファイルが、Composerのオートローダー機能によって、Laravelアプリ起動時やコマンド実行時などに自動実行される仕組みになっていました。
オートローダー機能とは、各パッケージが用意したファイルを、開発者が意識しなくてもLaravelアプリ起動時に自動で読み込んでくれる仕組みです。
つまり、入ってきたら自動で実行されてしまうわけです。
盗まれた認証情報
仕掛けられた helpers.php は、見た目は正規の翻訳ヘルパー関数に見せかけながら、裏で以下のものを探索していました。
- クラウド認証情報（AWS、GCP、Azureのアクセスキー）
- Kubernetes関連（kubeconfig、トークン）
- HashiCorp Vault（
~/.vault-token） - SSHキー（
~/.ssh/id_rsaなど） .envファイル（Laravelアプリの設定そのもの）- ローカルアプリ設定（各種開発ツールの認証情報）
- 暗号資産ウォレット
などなど。
これらを攻撃者が用意した flipboxstudio.info というドメインに送信していました。
ちなみにこの「Flipbox Studio」は、実在するLaravel系ツール開発組織の名前を真似たものです。
実在の企業に似せたドメインを使うことで、疑われないようにしているわけです。ここも巧妙ですよね。
攻撃の流れの全体像
ここまでの流れを整理します。
- 開発者が
composer updateを実行 - Laravel-Lang の新バージョン（感染済み）がダウンロードされる
- リクエストやコマンド実行の際、
vendor/autoload.php経由でhelpers.phpが発火 helpers.phpがホームディレクトリ配下の認証情報を片っ端から読む- 集めたデータを
flipboxstudio.infoに送信
影響を受けたかどうか確認する方法
感染したかどうかですが、5月22日 22:32 UTC（日本時間5月23日 7:32頃）から２３日以降に composer update をしていて、Laravel-Lang を使っているLaravelプロジェクトがある場合は、確認が必要です。
helpers.phpチェック
vendor/laravel-lang配下の各パッケージにsrc/helpers.phpというファイルが存在するかチェックします。正規版には含まれていないファイルなので、存在していれば感染の可能性が高いです。
通信ログの確認
サーバーやローカル端末の過去通信ログに flipboxstudio.info へのアクセスがないかを確認します。
侵害の可能性がある場合の対応
キー情報（AWS、GitHub、データベース認証情報、.env内の情報など）のローテーションが必要となります。
また、該当端末・サーバーを再構築したほうがよいでしょう。
今後の予防 ─ composer update との付き合い方
こういった事件はまた出てくる可能性があります。NPM Packageのように、一定期間たったもののみインストールできればよいのですが、今のところ、composerにはその仕組みがありません。
ただ検討はされているので、今後変わる可能性があります。
現段階では、下記が有効です。
更新内容をチェックする
更新候補のパッケージが見つかったら、GitHub上で変更内容を確認します。
数行のバグ修正だけなら安心して更新できます。一方で、説明できない大量の変更や、helpers.phpのような重要ファイルの書き換えがある場合は、慎重に判断します。
メジャーバージョンアップではない更新で、大量のファイルが書き換わっていたら要注意です。
必要なパッケージのみ更新する
全て一括ではなく、必要なパッケージのみ更新します。
パッケージ名を下記のように指定します。
|
1 |
composer update パッケージ名 |
更新範囲が狭いほど、攻撃に巻き込まれるリスクも狭まります。
なお本番ではcomposer updateではなく、composer installをした方が良いと考えています。理由は、本番環境にいきなり新しいパッケージが入らないようにするためです。
composer installは、composer.lockに記録されたバージョンをそのままインストールするコマンドです。テスト環境で動作確認したバージョンが、変わることなく本番に反映されます。
ただ、今回のように composer.lock 自体が汚染されていた場合は install でも影響を受けます。
わたし自身、本番でcomposer updateをすることはありません。具体的な手順は、下記の記事の中で説明しているので、ご興味あれば見てみてください。
さいごに
今回の攻撃は、かなり巧妙だったと思います。巧妙ポイントは次の3つです。
- リポジトリ本体のコードは変えず、バージョンタグだけを書き換えた
- autoloadの仕組みを利用し、Laravelアプリ起動時やコマンド実行時に自動実行される設計
- 通信先のドメインに、実在するLaravel系組織の名前を真似た
特に厄介なのは、「GitHubリポジトリ本体のコードが大きく変わって見えない」点です。
タグの参照先だけを書き換えることで、通常のコードレビューでは気づきにくくなっていました
完璧な対策は難しいですが、本番でcomposer updateを使わない、必要なものだけ指定して更新する、新リリースは少し寝かせる。そういった地道な工夫の積み重ねで、大惨事の確率を下げることはできます。
わたしのほうでは引き続き、記事と動画でセキュリティに関することも発信していきます。また情報を知りたいと思ってもらえたら、Xアカウントフォローしてくださいね。
