GHSA-m7v2-7gxm-vc2v / CVE-2026-45077
この脆弱性で確認すること
- 対象製品
- symfony/monolog-bridge / symfony/symfony
- WATRIXで確認できる範囲
- 利用製品・バージョン・設定を確認し、影響調査や対策の進め方をご相談いただけます。掲載だけで自動診断や復旧の対応を保証するものではありません。
- 情報の作成方法
- 収集した原典情報
情報整理：WATRIX合同会社。影響の確定や侵害の有無は、実際の版・設定・ログ等を確認して判断します。
- CVSS
- 8.1
- 公開元の公表日時
- 2026/05/28 6:13
- 公開元の更新日時
- 2026/05/28 6:13
- 当サイトの収集処理
- 2026/11/07 0:00
原典の説明
公開元の記載です。日本語での確認手順・対処の解説が付いていない項目も含まれます。
Symfony has Unauthenticated PHP Object Deserialization in MonologBridge server:log Listener
### Description `Symfony\Bridge\Monolog\Command\ServerLogCommand` (the `server:log` console command) is a development-time helper that opens a TCP listener and displays log records pushed to it by the application's logging pipeline. Two unsafe defaults combine into a remotely reachable PHP object-deserialization sink: 1. The listener binds to `0.0.0.0:9911` by default; it accepts connections on every interface, not only loopback. 2. Each received frame is processed as `unserialize(base64_decode($message))` without an `allowed_classes` allowlist, without authentication, and without any integrity check. The decoded value is then passed to `displayLog(..., array $record)` which assumes (without validating) that the result is an array. Any host that can reach TCP port 9911 on a machine running `server:log` can therefore submit attacker-chosen serialized PHP payloads. The minimum impact is an unauthenticated denial of service (sending a non-array, e.g. `serialize(new stdClass())`, crashes the listener with a type error). Object injection with magic-method side effects (`__wakeup()` / `__destruct()` / etc.) is reachable before the array type-check fires; full remote code execution is environment-dependent and contingent on usable gadget chains in the autoload set of the target process. ### Resolution The `server:log` command no longer binds to all interfaces by default: the default `--host` is now `127.0.0.1:9911`, requiring explicit opt-in to accept off-host traffic. Message decoding is gated by an `unserialize()` allowlist restricted to the `Symfony\Component\VarDumper\Caster\*` and `Symfony\Component\VarDumper\Cloner\*` classes that legitimately appear inside dumped log records; any other class is rejected and the record discarded. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/0891b2f293896c488e26943dc034334364b77fc4) for branch 5.4. ### Credits Symfony would like to thank Toàn Thắng and Sam Sanoop for reporting the issue and Nicolas Grekas for fixing it.
公開元の対処情報
個別の対処手順は未記録です。開発元の最新の案内と、対象の製品・系列に合う修正版を確認してください。
出典・著作権・ライセンスを確認する
- 出典
GitHub Advisory Database
- 利用許諾
CC-BY-4.0
- 利用条件
当サイトでの保存履歴
当サイトが取得した原本の履歴です。公開元での過去の改訂日時とは異なります。
初回保存のみです。訂正前の版はまだありません。
現在の保存内容2026/10/31 17:00
掲載中修正版あり
このページは公表情報を確認するためのデータです。製品を使っているだけで被害や脆弱性への該当が確定するものではありません。現在のバージョン、設定条件、開発元の更新情報を確認してください。