2026年5月20日、Symfony から大量のセキュリティ脆弱性（CVE）が一斉に公開されました。同時に修正版もリリースされています。
Laravel は内部で Symfony のコンポーネントを大量に使っているため、Laravel アプリを運用している方も無関係ではありません。
一部表現を変更しました。
当初は「動作が変わる可能性があるので、ライブラリを指定して composer update を行う方法」を推奨していました。
ただ記事公開後、Composer で「更新そのものが攻撃対象になる」事件が発生しました。それを受け、セキュリティ面でもライブラリを指定した方法を推奨する、という表現を追記しています。
Laravel公式アカウント
Laravel 公式アカウントもこの件について次のように伝えています。
「アプリケーションの依存関係を最新かつ修正済みに保つために、 composer update および composer audit を実行してください」
We are reviewing the CVEs announced and patched by @symfony today.
In the meantime, run and to keep your application’s dependencies up-to-date and patched.
— Laravel (@laravelphp) May 20, 2026
Symfony とは
Symfony は PHP の Web フレームワークの 1 つ。
Laravel が内部で部品として使っています。Laravel アプリを動かすと、裏で Symfony のコードがたくさん動いている、というイメージです。
何が起きたのか
Symfony 公式が Security Advisories ページで、5月20日付で10件以上の脆弱性アドバイザリを一斉に公開しました。同日に修正版もリリースされています。
リリースされた修正版バージョン：
- Symfony 5.4.52（旧 LTS）
- Symfony 6.4.40（LTS）
- Symfony 7.4.12（現行 LTS）
- Symfony 8.0.12（最新）
- Twig 3.26.0
これは攻撃を受けたわけではない
今回は「Symfony が攻撃を受けた」という話ではありません。
セキュリティ研究者が脆弱性を発見して Symfony に報告し、Symfony 側が修正版を準備してから、CVE と修正版を同時に公開した、という流れです。
Laravel ユーザーが特に気にすべき脆弱性 2 つ
今回 10 件以上の CVE が公開されましたが、通常のLaravelアプリ開発で重要なのは下記２点と考えられます。
1. CVE-2026-46626（環境設定の切り替え）
攻撃者が特殊な形のクエリ文字列を送ることで、本番アプリの APP_ENV や APP_DEBUG を勝手に切り替えられてしまう脆弱性です。デバッグモードに切り替えられると、エラー画面から内部情報が漏れる可能性があります。
発動条件の1つとして、php.ini の register_argc_argv が On になっている必要があります。こちらはデフォルトで Off ですが、環境差もあるためアップデート推奨です。
2. CVE-2026-45067（メールアドレスの改行で攻撃可能）
メールアドレスの中に改行文字を入れることで、追加のメールヘッダーを注入できる脆弱性です。攻撃シナリオはこんな感じです。
- お問い合わせフォームの「メールアドレス」欄に、攻撃者が改行付きの文字列を入れる
- システムがそのアドレスでメールを送信しようとする
- 改行のあとに書かれた「Bcc: 攻撃者のアドレス」などが本物のヘッダーとして処理される
- 結果としてスパム送信の踏み台にされたり、情報漏洩につながる
Laravelの email バリデーションなどで通常のメールアドレス形式に制限していれば、悪用される可能性はかなり下がります。ただし、依存パッケージ自体は更新しておくのが安全です。
今やったほうがいいこと
Laravel 公式が推奨している手順は、シンプルにこの 2 つです。
|
1 2 |
composer update composer audit |
- composer update：依存パッケージを最新版に更新。今回の Symfony 修正版も自動的に入る
- composer audit：インストール済みパッケージに既知の脆弱性がないか確認
ただ composer update をすると、他のパッケージも一緒に更新されて動作が変わる可能性があります。
また最近は、よく使われているライブラリが攻撃者に乗っ取られて、更新したタイミングで感染するという事件も起きています。
そのため、すべてをまとめて更新するのではなく、必要なものだけを指定して更新する方が安心です。具体的には、次のような流れにします。
本番環境への影響を最小限にしたい場合
1.ローカル/ステージング環境で composer audit を実行
2.脆弱性のリスクがあるパッケージ確認
3.表示されたパッケージを指定してコマンド実行（下記は例。パッケージは続けて指定してもOK）
|
1 |
composer update symfony/mailer |
4.composer audit を再実行（更新後も脆弱性が残っていないか確認）
5.テストを実行して動作確認
6.更新されたcomposer.lock を Git にコミット & プッシュ
7.本番環境では composer install を実行
本番環境ではcomposer updateを行いません。
テスト環境でしっかり動作確認し、問題なければ composer.lock を本番に反映、本番では composer install で同じバージョンを再現する、という流れです。
なお、３でエラーになった場合は、依存パッケージの更新日や内容をチェックした上で、インストールすることをおすすめします。
こちらはClaude Mythosが発見した！
今回のメールの脆弱性について、クレジットの欄にこんな一文が
We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
Claude Mythosは、Anthropicが未公開のまま提供している、セキュリティ特化のフロンティアモデル。Project Glasswingという取り組みで、限られた組織にだけアクセスが提供されています。これまでにOpenBSDの27年もの間見つかっていなかった脆弱性なども発見しているそうです。
今回はこちらのプロジェクトを利用したのではないかと推測されます。
さいごに
今回は攻撃を受けたわけではなく、自発的な動きです。
ただ最近はいつ何が起こるか分からない状況。早めの対策がおすすめです。
