PHPの脆弱性予告は危険？AI時代のゼロデイ攻撃と備えを考える

前の記事では、PHPの脆弱性をめぐるConoHa WINGとエックスサーバーの対応を、利用者の立場から書きました。気になったのは、修正版が出たあと、契約先がいつ対応を終え、その状況を知らせてくれるのかということでした。

今回は、それより前の話です。PHPはWordPressなどを動かすためにサーバー側で使われるプログラミング言語ですが、開発元は修正版の公開前に「重大な脆弱性がある」と予告していました。

更新に備えてほしいという意図は分かります。でも、それは攻撃する人へのヒントにもなりませんか。今はAIもあります。「このソフトに重大な穴がある」と分かれば、集中的に探し、修正版が出る前に見つけてしまう人がいるのではないでしょうか。

修正版がある攻撃と、まだない攻撃

この違いを考えるために、ゼロデイ攻撃とNデイ攻撃を、この記事では修正版が一般に提供される前か後かで整理します。

ゼロデイ攻撃は、修正版がまだ一般に提供されていない段階で、脆弱性を突く攻撃。Nデイ攻撃は、修正版が出ているのに、まだ適用されていない環境を狙う攻撃です。公開当日がゼロデイで、翌日からNデイ、という意味ではありません。

修正版の一般提供前のゼロデイ攻撃と、提供後も未適用の環境を狙うNデイ攻撃を左右に比較。この記事の整理の軸を示す。

前の記事で書いた「私のサーバーは対応済みなのか」という心配は、主にNデイ攻撃への備えです。

今回は、予告を手掛かりに穴が見つかり、修正版が出る前に悪用される、ゼロデイ攻撃につながらないかという心配です。

ただ、以前から開発側は公開前に修正を進めていますし、攻撃者が別の経路で先に穴を知る場合もあります。AIが初めて作る問題ではなく、以前からある問題を大きくするかもしれない、という話です。

穴の場所を教えなくても、「探す価値」は伝わる

PHPの公式予告には、重大な脆弱性が2件あること、その深刻度、修正版の公開予定日時、更新準備の呼びかけが書かれていました。弱点の具体的な場所や、影響を受けるバージョンなどの詳細は、予告文にはありませんでした。

PHPの予告に書かれた重大度や公開予定と、予告には書かれていない弱点の場所や影響する版を、二つの書類で対比した図。

攻撃方法を配っていたわけではありません。それでも、探す対象と、そこに重大な問題があるという情報は伝わります。闇雲に探すより、攻撃する側が関心を向けやすくなるのではないかと思います。

存在を知ることと、実際に穴を見つけて悪用することには隔たりがあります。気になるのは、AIが探索や検証の手間を減らし、その隔たりを縮める可能性です。「詳しい場所までは教えていない」というだけで、予告の危険を小さく見積もってよいのでしょうか。

Anthropicには、公開された修正前後の違いなどをAIに渡し、未修正版の実験環境で悪用手段を作らせた研究があります。ただし、修正版公開後の話で、Firefoxの実行エンジン単体など、限定された条件での評価です。今回の「予告だけでも危ないのか」という疑問への答えにはできません。

守る側もAIを使って穴を発見し、修正を進めています。AIの能力だけを見て、ゼロデイ攻撃がどれだけ増えるかまで言い切ることもできません。

それなら、予告をやめればいいのでしょうか

「修正版ができるまで黙っていればいいのでは」とも考えますが、予告があれば、運用者は担当者や作業予定を調整できます。PHPの予告も、修正版が利用可能になったら速やかに更新できるよう、準備を呼びかけていました。

一般向けの予告をなくせば、攻撃者がそこから得る手掛かりは減るかもしれません。一方、その知らせを頼りに準備する運用者の機会も失われます。関係者だけに非公開で伝える方法でも、共有相手に入っていない運用者には、その経路の合図は届きません。誰に、どこまで知らせるかという問題が残ります。

さらに今回のPHPでは、公式予告より前に脆弱性の識別番号が外部で流通していたと、PHP Foundationが説明しています。AWSも、予告より前の10月17日に、攻撃者の動きを観察するためのおとりのシステムで、攻撃の試行を観測したと報告しています。

これは「予告を見たAIが攻撃を始めた」という証拠ではありません。情報の入手経路や、攻撃者がAIを使ったかも分かっていません。ただ、公式が予告を出さなくても、攻撃者が何かを知っている場合はあります。予告を消すだけで安全になるとは、簡単に決められません。

準備の時間は、守る側だけのものではない

修正予告を中心に、更新を準備する運用者とAIによる探索の手掛かりになる懸念を配置。後者は「可能性・未検証」と明記している。

私は、今回のPHPの予告が間違いだったと言いたいわけではありません。この予告によって攻撃が増えたという根拠も、確認できていません。

それでも、「守る側の準備のために知らせる」という従来のやり方が、もしかしたらリスクを高めるのでは？と思うようになりました。同じ知らせを、攻撃する側も読めるからです。

予告をするかしないかの二択より、守る側の準備にどんな情報が必要で、それを何時間前に出す必要があるのか。AIの能力も踏まえて、そこを見直してほしいと思います。予告が早ければ早いほどよいとも、黙っていれば安全だとも思いません。

「更新の準備をしてください」という知らせを、攻撃する側は「今のうちに探してみよう」と読むかもしれない。その「今のうちに」が、AIによってどこまで現実的になるのか。予告から公開までの時間が、誰の準備に使われるのか。

AI時代のセキュリティってどうなっていくんだろう…そう思わずにはいられない出来事でした。

参考資料

PHP公式：Upcoming Critical PHP Security Release（2026年10月20日付）
https://www.php.net/archive/2026.php

Google Threat Intelligence Group：A 2024 Zero-Day Exploitation Analysis（2025年4月29日）
https://cloud.google.com/blog/topics/threat-intelligence/2024-zero-day-trends

Anthropic：Measuring LLMs’ impact on N-day exploits（2026年6月8日）
https://www.anthropic.com/research/n-days

PHP Foundation：Today’s PHP Security Release, and How We’re Strengthening PHP Security（2026年10月21日）
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

AWS：Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot（2026年10月21日）
https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/

PHPの修正予告は攻撃者へのヒントになる？ AI時代に気になったこと