CVE-2026-109618 と CVE-2026-109619 は、PHP 本体のメモリ管理に関する脆弱性です。WAF は HTTP リクエストの特徴しか見られないため、ルールを追加しても PHP 自体は修復されません。この記事では、ルールの書き方ではなく、本番環境でルールを有効にする前に確認したいことを整理します。
1. まず PHP の修正版を確認する
仮想パッチは、修正版を適用するまでの時間を稼ぐものです。PHP の更新が可能なら、WAF の設定より先に更新計画を決めた方が確実です。
WAF を通過しない通信は、ルールの対象外です。オリジンへの直接アクセス、内部通信、CLI、HTTP 以外の経路が残っている場合、入口のルールだけでは閉じられません。
2. 最初から遮断しない
ファイルアップロードを扱うサイトでは、最初から拒否すると正常な通信まで止めることがあります。まずは監視モードで一致した通信を記録し、送信元、頻度、対象 URL を見てから遮断するかどうかを判断します。
SafeLine では、この監視モードを拒否ルールに設定できるのは 9.4.3 以降です。それより前のバージョンで同じルールを遮断モードのまま入れるのは、誤検知の影響を確認できないため推奨されません。
3. 一致したログを3つに分ける
ログは「脆弱性が悪用された」とは限りません。少なくとも次の3つに分けて見ます。
- 同じ送信元から短時間に繰り返される探索
- 普段からファイルをアップロードしている利用者の通信
- WAF を経由していない、または送信元を特定できない通信
探索と判断できるものだけを遮断候補にします。業務上のアップロードが一致している場合は、条件を狭めるか、監視のままにします。
4. このルールがカバーしない範囲を明示する
CVE-2026-109618 は、multipart 解析中のメモリ不足からリクエスト単位のメモリ状態が壊れる問題です。Content-Length の欠落、大量のパートヘッダー、空のファイル入力、ネストしたフィールド名などがきっかけとして知られています。
CVE-2026-109619 は、ワーカーに残ったグローバル状態が原因の use-after-free です。セッションのアップロード進捗以外にも、INI の診断情報や致命的エラーのバックトレースなど、複数の経路が示されています。
公開されている観察用ルールは、セッションのアップロード進捗に関係する既知のリクエスト特徴を見るためのものです。メモリ破壊そのものや、すべての亜種をカバーするルールではありません。
5. 遮断へ切り替える条件を先に決める
「ログが出たから遮断する」では判断がぶれます。たとえば次の条件を事前に決めておきます。
- PHP の修正版を入れる日時が決まっている
- 監視ログで、業務通信との切り分けが完了している
- オリジンへ直接届く経路を確認済みである
- 遮断後に誤検知を戻す担当者と手順がある
この4つが揃わないうちは、監視と PHP の更新を優先した方が安全です。
まとめ
WAF ルールは、既知の探索や再現済みの攻撃チェーンを見つける応急処置です。脆弱性の原因は PHP プロセスの中にあり、リクエストの外側からは修復できません。ルールの有無にかかわらず、修正版の PHP へ更新し、WAF を迂回できる経路が残っていないかを確認してください。