Symfonyの脆弱性CVE-2026-118515｜ファイル漏えいなどと修正版

CVE-2026-118515は、Serializerがリクエストの値からUploadedFileを作る問題です。アプリの処理次第で、PHPが読めるファイルを外へ返したり、移動したりするおそれがあります。Symfonyの評価は「高」で、この告知にCVSSの数値は記載されていません。[1]

同時公表のCVE-2026-118513は証明書認証のなりすましで、Symfonyの評価はCVSS 4.0で7.7（高）。YAMLの処理時間が急増するGHSA-hwfg-qwvh-2wfxは同8.7（高）です。以下ではファイル、認証、サービス停止の影響を先に確認します。[2][5]

• ファイル受信：#[MapRequestPayload]などで、外部入力をUploadedFile型のプロパティを持つオブジェクトへ変換する場合。Assert\Fileだけでは防げません。[1]
• data URI：DataUriNormalizerを使い、外部入力をSplFileObject・SplFileInfo・Fileに変換する場合。大文字を含むスキームがローカルパスとして開かれる別件があります。[3]
• パスの検査：Path::isBasePath()やcanonicalize()で利用者の入力を検査してからファイルを開く場合。Symfony 6.4以降のAssetMapperでは、不正な配布パッケージのCSS参照から保存先の外へ書き込まれる経路もあります。[4]
• 証明書認証：信頼する認証局が発行した証明書のCNを攻撃者が指定でき、DN全体から利用者名を抽出する場合。認証局がSubjectを生成・検証する構成や、属性別の値を直接渡す構成は、この問題の対象外です。[2]
• YAML：信頼できないYAMLを解析する処理。7.4以降ではYamlコンポーネントがあり、#[MapRequestPayload]のacceptFormatを制限していないAPIも含みます。6.4ではアプリによるYAML形式の登録が条件です。[5]

確認した提供元の告知には、実際の攻撃を観測したとの記載はありません。告知には再現条件や入力例があり、YAMLでは小さな入力でもPHPの処理を長く占有できることが示されています。実運用への攻撃が確認されたという意味ではありません。[1][2][3][4][5]

上記のSerializer・証明書認証・YAMLの告知が示す対象は、5.4.56未満、6.0以上6.4.50未満、7.0以上7.4.23未満、8.0以上8.1.11未満です。Filesystemのパスの問題は5.4.0以上が対象です。現在の系列に対応する5.4.56・6.4.50・7.4.23・8.1.11を修正版の基準にします。[1][2][4][5]

今回の修正番号と、将来を含む系列全体のサポート状況は別です。互換性を確かめずにメジャー版を飛び越すのではなく、まず影響する依存関係を修正版へそろえます。個別コンポーネントを使うアプリも対象です。

1. プロジェクトで次を実行し、導入済みコンポーネントと版を記録します。実行環境が別のコンテナなら、その環境でも確認します。

   composer show 'symfony/*'
   composer audit

2. Serializer、SecurityHttp、Filesystem、Yamlと、それらを使うリクエスト処理を調べます。独自のSerializerを組み立てている場合は、DataUriNormalizerがObjectNormalizerより先に登録されているかも確認します。今回のUploadedFile対策は、この並びを欠くSerializerには効きません。[1]

3. 依存関係の制約を確認し、検証環境でSymfonyの対象パッケージを更新します。

   composer update 'symfony/*' --with-all-dependencies

   解決結果が修正版に達したかを確認し、更新したcomposer.lockを使って本番へ配置します。コマンドの成功だけで、必要な版へ上がったと判断しません。

4. 正規のファイル送信・証明書ログインと、許可している入力形式をテストします。認証のないリクエストからファイル型のプロパティを書き換えられないことも検証環境で確かめます。[1][2][5]

証明書認証について提供元は、曖昧な旧形式のDNを渡す構成からRFC 2253形式へ切り替えるか、メールアドレスなど属性別の値を直接渡す構成を示しています。対象となるWebサーバーと証明書の設定を確認して適用します。[2]

ファイル変換・YAML・パスの問題について、確認した告知に更新の代わりとなる一般的な回避策の保証はありません。更新まで外部入力を対象処理に渡す機能を制限し、YAMLが不要なAPIでは受け付ける形式を明示します。ファイルサイズ制限だけでYAMLの問題を解消したとは判断できません。[1][3][4][5]

UploadedFileなどの派生型には、想定した型の実体以外を渡すと例外が出るようになります。#[MapRequestPayload]では422レスポンスになります。正規のファイル受信まで失敗していないか確認します。[1]

7.4以降では、#[MapRequestPayload]はacceptFormatに明示しないYAML・CSVを受け付けなくなります。これまで暗黙に受け付けていたAPIでは、不要な形式を閉じたままにし、必要な形式だけを明示します。[5]

同日の修正には、GETだけに制限したaccess_controlやファイアウォールをHEADで通れる問題、IPの公開・非公開判定の不備、HtmlSanitizerのURL制限の回避も含まれます。HEADでは本文がなくてもコントローラーは動き、ヘッダーや副作用が残る点に注意します。[6][7][8]

修正後はGET向けのルールにHEADも含まれます。HEAD専用ルールが必要なら順序を確認します。IPのフィルターも厳しくなり、これまで通った予約アドレスなどが拒否されるため、更新後のテストに含めます。[6][7]