PHPの重大な脆弱性「php2shell」を見つけたのは、攻撃者でもPHPの開発者でもなく、AIを使った監査でした。セキュリティ企業Califが8月1日に見つけたとき、使ったのは誰でも契約できる一般公開のモデルだったと同社は書いています。同じ道具は攻撃する側も持っている、ということです。
WordPressをレンタルサーバーで運営している人がやることは、PHPのバージョンを確かめ、修正済みの版で動いているかをホスティング会社の告知で確認することです。OpenAIが公開した判定ツールは便利ですが、手元で試すと判定できない場面がはっきりありました。その限界と、管理画面だけで確かめる順番を書きます。
修正版は8.2.35以上。8.1以前は修正が出ない
PHP公式の10月21日の告知によると、修正版は8.5.12、8.4.27、8.3.36、8.2.35です。CVE-2026-109618と109619の2件で、どちらも認証なしでサーバー上のコードを実行される恐れがあります。
注意したいのは、サポートが終わった8.1以前には公式の修正版が出ないことです。告知では7.4・8.0・8.1向けに最小限の修正コードを出す予定とされていますが、レンタルサーバーで自分で当てられるものではありません。さらに8.2も2026年12月31日でサポートが終わります。いま切り替えるなら、8.3以上を選ぶほうが年明けにもう一度慌てずに済みます。
暫定策としてsession.upload_progress.enabled=0が紹介されていますが、GMO Flatt Securityの解説は効果が部分的だとしています。同社は10月21日時点で攻撃コードが出回っているとも書いており、設定変更だけで済ませるのは危険です。
発見から修正版まで81日。AIが作った「防御側の猶予」
Califの発見は8月1日、修正版の公開は10月21日です。この81日間、PHPの開発者、Califや、同時期に独自に見つけたWiz、OpenAI、Cloudflareなどが修正と防御策を準備していました。OpenAIはこの期間を「Defender’s Window(防御側の猶予)」と呼んでいます。
OpenAIの10月21日の発表によると、CalifはOpenAIの脆弱性対策プログラム「Patch the Planet」の中でGPT-5.6 Solを使って欠陥を見つけました。Wizの報告では、同社はGemini 4 ArgonとGPT-5.6 Solなどを使い、8月19日に独自に見つけています。WordPress、Drupal、Joomlaの最新版コンテナで、認証前にコードを実行できることも示しました。
OpenAIは同じ発表で、似たような発見が今後数か月で急増すると予想し、同じ能力が攻撃者の攻撃コード開発も速めると書いています。私はここがこの件のいちばん大事な点だと考えています。今回は防御側が先に見つけましたが、次も先に見つけられる保証はありません。修正版が出てから当てるまでの日数が、これまで以上に効いてきます。
OpenAIの判定ツールを試した。UNKNOWNは「安全」ではない
OpenAIはPHPのバージョン判定ツールをApache 2.0で公開しました。Node.jsだけで動き、追加のパッケージは要りません。攻撃用のリクエストは送らず、サイトの応答ヘッダー(X-Powered-ByとServer)か、サーバー上のphp -vの結果からバージョンを読み取って判定します。
私は10月21日時点のコードを取得し、付属のテスト31件がすべて通ることを確かめました。そのうえで、自分のPCに偽のサーバーを立て、ヘッダーの値を変えて判定を比べました。
- X-Powered-ByにPHP/8.3.36:OK
- X-Powered-ByにPHP/8.3.35:VULNERABLE
- X-Powered-ByにPHP/8.1.34(8.1系の最終版):VULNERABLE
- ヘッダーなし:UNKNOWN(PHP version not found)
- サーバー上で
php -vが「8.3.6-1ubuntu0.24.04.9」を返す想定:VULNERABLE
ここから分かる限界は3つあります。
1つ目は、ヘッダーでバージョンを出していないサイトはUNKNOWNになることです。当サイトに試してもUNKNOWNでした。バージョンを外に出さない設定のサーバーでは、URLを入れるだけでは判定できません。READMEにも、UNKNOWNは修正済みを意味しないと書かれています。
2つ目は、8.1以前は番号に関係なく必ずVULNERABLEになることです。判定表は系列ごとに「この番号以下は脆弱」と決めていて、サポート終了の系列は最終版がそのまま基準です。つまり、この系列から抜け出す以外にOKにはなりません。
3つ目は、OSの配布元が修正を取り込んだ(バックポートした)版でも、上流の番号が古ければVULNERABLEと出ることです。Ubuntuなどのパッケージで動かしているサーバーは、この判定だけで結論を出さず、配布元のセキュリティ情報と照らし合わせる必要があります。
自分のサーバーにSSHで入れる人は、ツールを取得してサーバー上で確かめるのが確実です。他人のサイトには使わず、自分が管理するサイトだけに使ってください。
git clone https://github.com/openai/php2shell-checker
cd php2shell-checker
node phpcheck.js --local
node phpcheck.js "https://自分のサイトのURL"
レンタルサーバーのWordPressで確認する順番
SSHを使えない共有サーバーでも、管理画面から次の順で確かめられます。
- WordPressの管理画面で「ツール」→「サイトヘルス」→「情報」を開き、「サーバー」の項目でPHPのバージョンを見る
- 8.1以前なら、ホスティング会社のサーバーパネルで8.3以上に切り替える。プラグインやテーマが新しいPHPに対応しているかを先に確かめ、切り替えたらトップページ、ログイン、投稿画面が動くかを確認する
- 8.2〜8.5なら、ホスティング会社の告知でPHPの修正版を適用したかを確かめる。番号が修正版より古いままでも、事業者が独自に修正している場合がある
- ログイン情報やプラグインの一覧を見て、見覚えのない管理者ユーザーやプラグインがないかを確かめる
3つ目は、事業者によって告知の書き方が違います。ITmediaの報道では、さくらのレンタルサーバやエックスサーバーなどが21日に緊急メンテナンスを告知しました。ただし、メンテナンスの告知と、自分のサイトが動いているPHPが修正版になったことは別の話です。PHPの更新が済んだかは、事業者の続報で確認するしかありません。
4つ目は、パッチ前に侵入されていないかの確認です。私が自分のサイトで見るなら、管理者ユーザーの一覧と、画像などを置くwp-content/uploadsの中にPHPファイルが紛れていないかの2点から始めます。怪しいものが見つかった場合は、自分で消して済ませず、ホスティング会社に相談してください。
AIが脆弱性を見つける速さに、更新の習慣を合わせる
PHP Foundationの発表によると、PHPの開発側も今後はAnthropicのClaudeやOpenAIのツールを使ったAI支援の検査を取り入れます。見つかる脆弱性はこれから増え、修正版が出る間隔も短くなると私は見ています。
小さなサイトの運営者にできるのは、修正版が出たらすぐ当たる状態を作っておくことです。WordPress本体とプラグインの自動更新を有効にし、PHPのバージョンを最新に近い系列にしておく。PHPの更新を自分でできない共有サーバーなら、告知が早く、更新状況をきちんと公表する事業者かどうかを、契約先を選ぶ基準に加えてもよいと思います。
AIを使った攻撃については、国内企業が標的になったARTEXの件で、先に点検すべき場所も書きました。今日やることは1つ、サイトヘルスを開いてPHPのバージョンを見ることです。5分もかかりません。

コメント