#99 公表前から攻撃されていたPHPの穴。AWS WAFで慌てて塞ぎ、アップロードまで止めた話

対象読者: 実務層

「公表日には、もう攻撃が始まっていた」

木曜の朝、Amazonの脅威インテリジェンス部門の報告に、血の気が引きました。PHPの重大な脆弱性「PHP2Shell」を狙う試みが、公表の4日前の10月17日には観測されていたのです。

前回の記事で私は、2024年の前例をもとに「修正の2日後には攻撃が来た」と書きました。今回の猶予は2日どころか、ゼロでした。修正版を当てていないPHPは、もう狙われている前提で動くしかありません。

最優先はPHPの更新です。ただ、すぐには更新できないサーバーもあります。そこでAWSが公開した「AWS WAFで露出を減らす方法」を、個人の学習用AWSアカウントの検証環境で急いで実装しました。そして、焦りから失敗しました。

この記事では、AWS WAFの限界と私の失敗、今日中にやる手順を整理します。

※本記事は2026年10月23日時点の公開情報にもとづいています。

1. 公表の4日前から、もう狙われていた

PHP2Shellは、前回取り上げた2件の脆弱性（CVE-2026-109618とCVE-2026-109619）の総称です。ログインなしで、外からサーバー上のプログラムを動かされるおそれがあります。

見つけたのは、Amazonのハニーポット網「MadPot」でした。ハニーポットは、攻撃者をおびき寄せて手口を記録する、おとりのサーバーのことです。10月17日、商用の匿名化ネットワークから悪用の試みが届いていました。情報がまだ公開制限（エンバーゴ）中の時期です。攻撃者が情報を得た経路は、わかっていません。

公表後は数時間で新しい概念実証コード（攻撃が成立することを示すコード）が現れ、すぐにAWSのセンサーへ使われました。AWSは、原文の公開時点でPHP2Shellがすでに実環境で広く悪用されていたと書いています。

…前回「IPAは悪用を確認していない。今のうちに更新できるかが分かれ目」と書いた私。その「今のうち」は、とっくに終わっていたんです。

AWSは、公開システムの重大な脆弱性には「時間単位」で対応するよう求めています。7日や30日の猶予は、もう存在しないという警告でした。

痕跡の調査も、10月17日までさかのぼるよう求めています。公表より前に侵害が起きていた可能性があるからです。

2. AWS WAFだけでは守りきれない：防げることと防げないこと

AWS WAFは、Webアプリの手前で怪しいリクエストを止めるサービスです。AWSは今回のAWS WAFを「多層防御のための制御」と位置づけ、PHPの更新の代わりにはならないと明言しています。IPAの続報も、暫定対策が難しければ、外部からのアクセス遮断やサービスの一時停止まで判断するよう求めていました。

PHP2Shellは、アプリのコードが動く前に起きます。PHPがファイルアップロード用の形式（multipart/form-data）のリクエストを処理する段階です。AWSのルールは次の4つです。

• アップロード進捗の機能を狙うリクエストを止める：POSTで、PHPのセッションIDと「PHP_SESSION_UPLOAD_PROGRESS」を含むもの

• アップロード形式そのものを止める：アップロード機能がないアプリに限る

• 大きすぎる本文を止める：メモリ不足を起こす経路を減らす

• 同じIPからのPOSTの連打を抑える：レート制限

防げないものも明記されています。サイズ上限の内側で、本文の中に小さなパートヘッダーを大量に並べ、メモリを膨らませる手口は見えません。PHP 8.5の「fatal_error_backtraces」のような、サーバー側の設定が絡む経路もAWS WAFの外側です。

…つまり、WAFだけ入れて「対応済み」と報告したら、穴を開けたまま安心することになります。

3. 焦って、自分でアップロードまで止めた

私の検証環境は、ALB（Application Load Balancer：通信を振り分けるAWSの入口）の後ろでWordPressを動かすものです。

一刻も早く塞がなきゃ、と焦った私は、ウェブACL（AWS WAFのルールをまとめた設定）に4つのルールを足しました。アップロード形式を止めるルールまで、最初からBlock（遮断）です。試しに管理画面から画像を上げると、エラーで止まりました。WordPressのメディア追加も、まさにmultipart/form-dataだったんです。

公開中のサイトなら、攻撃者より先に自分で機能を止めていたことになります。背筋が冷えました。

AWSのブログには、注意書きがありました。すべてのルールはまずCountモードで始め、正当な通信に一致しないと確かめてからBlockに切り替える。Countは、止めずに「一致した回数」だけを数えるモードです。

もう一つの勘違いが、本文の検査サイズです。CloudFrontやAPI Gatewayでは上限を引き上げられますが、ALBは8KBで固定。8KB超の本文を止めるルールをそのまま入れると、ふつうの画像アップロードまで止まります。

結局、アップロード形式のルールは外し、本文サイズのルールはアップロード先のパスを対象外にしました。

4. 今日中にやるAWS WAFの実装手順：Countで始めてBlockへ

今日中に終わらせたい順番です。

1. 棚卸しする：PHPのバージョン、動かし方（mod_php、PHP-FPMなど）、公開の入口を確認します

2. アップロードの有無を確かめる：使うなら、アップロード形式を止めるルールは使えません

3. ログを有効にしてCountで追加する：サンプルとCloudWatchで、正当な通信が一致しないか見ます

4. Blockに切り替える：進捗のルールは、サイズやレート制限より先に評価させます

5. テストする：PHPSESSIDをCookieか本文に、PHP_SESSION_UPLOAD_PROGRESSを本文に含めたPOSTを送り、403と該当ルールのメトリクスを確かめます

6. サーバー側も設定する：`session.upload_progress.enabled=0` にして全ワーカーを再起動します。PHP 8.5なら `fatal_error_backtraces=0` も

マネージドルール（AWSが用意したルールのセット）にも、8KB超の本文を止めるSizeRestrictions_BODYがあります。PHP向けのルール群にも、CVE-2026-109619への保護が加わりました。

検証環境のPHPは修正版に更新し、ログも10月17日までさかのぼりました。迷っているのは更新後のルールの扱い。AWSは「削除するか、補助として維持」としていて、まだ決めきれていません。

まとめ

• PHP2Shellは公表の4日前から狙われ、公表時点ですでに広く悪用されていました。修正版を当てていないPHPは、狙われている前提で今日中に動きます

• AWS WAFは、PHPを更新するまでのつなぎにすぎません。4つのルールで露出は減らせても、サーバー側の設定が絡む経路は防げません

• ルールはCountで始めてからBlockへ。ALBは本文の検査が8KB固定なので、アップロードのあるアプリでは対象のパスを絞ります

更新を終えた今も、10月17日からの間に何か入り込んでいなかったか、ログを見るたびに落ち着きません。ワーカーを毎回作り直す `pm.max_requests=1` は、性能への影響が読めず、まだ試せていません。

最後に…ちょっとだけ宣伝です：一緒に働く仲間を探しています！

この記事を書いているアクシスNWチーム広報部をはじめ、当社では現在、新しいメンバーを積極的に採用しています。 最先端のAIをパートナーに、ワクワクするような挑戦ができる環境が整っています。まずはカジュアルにお話ししませんか？ 新卒の方も、キャリア採用の方も、ぜひお気軽にチェックしてください！
⇒株式会社アクシス人事採用担当(note)
⇒株式会社アクシス求人情報(私の仲間の取材がいっぱいあります)
⇒株式会社アクシス中途採用サイト
⇒株式会社アクシスホームページ

#アクシス　#セキュリティ　#AI　#エンジニア　#スキしてみて　NWチーム広報部　#ゼロトラスト　#サイバーセキュリティ　#IT　#AI#脆弱性#PHP#WordPress　 #php2shell