FortiWebがPHP2Shell署名を公開｜Alert Onlyから遮断へ切り替える手順

Fortinetは2026年10月22日、FortiWebでPHP2Shell（CVE-2026-109618、CVE-2026-109619）を検知・遮断するための署名と適用手順を公開しました。FortiGuard FDSの署名ビルド0.00438に専用署名が含まれます。ただし、データベースを更新しただけでは新しい署名が既定で「Alert Only」になる構成があり、通信を記録しても遮断しない点に注意が必要です。

本稿は2026年10月23日6時00分（日本時間）までに、FortinetのPSIRT、Fortinet Communityの技術情報、FortiWeb管理ガイド、PHP公式情報を確認した続報です。PHPの修正版そのものや旧版PHPの移行方法ではなく、FortiWebを利用している組織が署名を受信し、誤検知を確認し、必要なポリシーで遮断を有効にするまでの運用手順に焦点を絞ります。

新たに公開されたのは署名と適用確認の具体策

Fortinet Communityの技術情報「How to block PHP2Shell on FortiWeb」によると、CVE-2026-109618とCVE-2026-109619を対象とする署名はFortiGuard FDS更新0.00438に収録されました。分類はKnown Exploit配下のSignatures for Common Web Applicationsで、署名IDは090502648、090502651、09052654です。

FortiWebのGUIでは「System → Config → FortiGuard」で更新を実行し、同画面のLicense InformationからSecurity ServiceのSignature Build Numberが0.00438以上であることを確認します。CLIを使う場合、Fortinetはexecute update-nowで更新し、get system upd-db-versionでWAF署名版を確認する手順を示しています。

確認項目	確認する値・状態	見落とした場合
FDS署名ビルド	0.00438以上	専用署名がまだ端末へ届いていない
署名ID	090502648、090502651、09052654	別の汎用署名だけを確認して完了と判断する
適用アクション	対象ポリシーで意図した遮断状態	Alert Onlyのまま検知だけして通過させる
保護対象	外部公開PHPサイトを通るポリシー	署名は存在しても対象通信へ適用されない

最重要ポイントはAlert Onlyを確認すること

FortiWeb 8.0.8管理ガイドの署名適用説明では、Signature Update Managementを新規・更新署名の評価場所として扱います。新しい署名は、既存ポリシー側で以前に別の動作を選んでいた場合でも、まずAlert Onlyとして置かれることがあります。これは誤検知で正規通信を止めないための安全設計ですが、緊急脆弱性への防御を期待する側から見ると「更新成功」と「遮断有効」は別工程です。

したがって、更新後の確認をデータベース版だけで終えてはいけません。Signature Update Managementで今回の署名を特定し、テスト対象のポリシーでアラートが発生するかを確認したうえで、業務上許容できる範囲から遮断へ切り替えます。複数のWebサイトを一つのFortiWebで保護している場合は、全体へ一斉適用するより、PHPを使用する公開サイトと重要度の高い管理画面から段階的に適用する方が、誤検知時の影響を限定できます。

実施順序は更新・評価・遮断・監視

1. 対象を棚卸しする：FortiWebの背後にある公開ホスト、PHPの実行方式、アップロード機能、利用ポリシーを一覧化します。WAFを経由しない直通経路や管理用FQDNも確認します。
2. 署名データベースを更新する：GUIまたはCLIで更新し、ビルドが0.00438以上であることを端末ごとに記録します。HA構成では全ノードの同期状態も確認します。
3. 署名とポリシーの関係を確認する：三つの署名IDが存在し、保護対象サイトへ適用されるシグネチャーポリシーに含まれることを確認します。
4. Alert Onlyで正規通信を試す：ログイン、ファイル添付、CSV取込、画像アップロードなどmultipart/form-dataを使う主要機能をテストし、今回の署名が正常な要求を検知しないか確認します。
5. 遮断へ切り替える：評価結果を残し、対象ポリシーでFortinetの管理ガイドに従って強制適用します。変更日時、担当者、対象FQDN、旧設定を記録し、すぐ戻せる状態にします。
6. 適用後を監視する：署名ID別の検知、送信元、対象URI、HTTPステータス、誤検知の申告を継続して確認します。遮断件数だけで侵害の成否を判断しません。

専用署名が届かない場合はカスタム署名が選択肢

Fortinetの技術情報は、専用署名を利用できない場合の代替としてカスタム保護ルールも掲載しています。multipart/form-data、セッションアップロード進捗、特定のリクエスト構造などを組み合わせて疑わしい要求を拒否する内容です。ただし、記事のコードをそのまま全環境へ投入するのではなく、利用中のFortiWeb版と構成で構文を確認し、ステージングまたは限定ポリシーで評価してください。

特にファイルアップロード、インポート、フォーム生成ツールを使うサイトでは、攻撃と正規通信が同じmultipart形式を通ることがあります。カスタム署名は緊急時の到達経路を減らす手段であり、アプリケーションの仕様を無視した広い正規表現を全サイトへ適用すると可用性を損ないます。専用署名が利用できるなら、まず公式データベースを更新し、カスタム署名は未対応版・隔離環境・補助制御として位置付けます。

FortiWeb自体の影響と保護機能を混同しない

Fortinet PSIRTのFG-IR-26-186は10月21日の初版後、10月22日に調査中製品の一覧を更新しました。FortiWebは同アドバイザリで影響を受けないことが確認された製品側に含まれます。一方、今回公開されたFortiWeb署名は、FortiWebの背後で稼働するPHPサイトを守るための防御機能です。「FortiWebが脆弱だから署名を入れる」のではありません。

また、Fortinet製品のうち調査中とされた製品については、FortiWebのWAF署名を受信したことをもって製品自体の調査完了や修正済みとは判断できません。PSIRTの製品別判定と、FortiWebによる外部PHPサイトの保護は、別の管理項目として追跡する必要があります。

WAFは更新の代わりにならない

PHP公式の2026年10月21日セキュリティ情報は、CVE-2026-109618とCVE-2026-109619が認証不要のリモートコード実行につながり得ると説明し、PHP 8.5.12、8.4.27、8.3.36、8.2.35への更新を求めています。設定変更は一部の攻撃経路を減らすだけで、完全な解決は更新だと明記しています。

WAF署名も同じです。既知の要求パターンを入口で落とせても、暗号化終端の位置、別ポート、内部経路、署名が想定しない変形、WAFを経由しない通信には効きません。FortiWebの遮断を有効にした後も、バックエンドPHPの修正版適用、ワーカー再起動、実行版の確認を完了させます。PHP 8.1以下の扱いは、関連記事のバックポート確認とPHP 8.3以降への移行手順で整理しています。

適用後も10月17日以降の記録を確認する

署名の導入は将来の要求を減らす対策であり、過去に侵害されていないことの証明にはなりません。Amazon Threat Intelligenceは公表前の10月17日に攻撃試行を観測しています。FortiWebログだけでなく、Webサーバー、PHP、EDR、クラウド監査ログを同じ時刻帯で照合してください。確認範囲と観測事実は、関連記事のAWSが報告した公表前の攻撃試行で整理しています。

実務上の完了条件は、署名ビルドの受信、対象ポリシーへの割り当て、Alert Onlyから意図した動作への切り替え、正常系テスト、バックエンドPHPの修正、過去ログの確認がそろうことです。どれか一つだけでは「対策済み」とは言えません。