
文系でもわかる、なぜレンタルサーバーのPHPバージョンを確認する必要があるのか
こんにちは。前回の「.htaccessが8,641行になって500エラー」の記事では、WordPressの外側(Apache)でサイトが落ちる怖さを書きました。
今回はその続編です。2026年10月21日夜、ウマ娘、グラブル、シャドバWB、プリコネ、チュウニズム、厚生労働省の介護サイト、静岡銀行など、日本だけで50団体以上が一斉にサイトを停止しました。
原因はWordPressのプラグインではありません。その下で動いているプログラミング言語 PHP本体 に2件の致命的な脆弱性が見つかったからです。
YouTubeで話題の動画「〖文系も〗今話題のPHPの「致命的」脆弱性を落ち着いて理解しよう」が、この事件を5つの視点でとても冷静に解説していました。この記事ではその動画をベースに、WordPress専門家視点で「なぜWordPressを最新にしても意味がないのか」まで深掘りします。
なぜ一斉停止が起きたのか?タイムラインで見る異常事態
この事件が異例だったのは、パッチが出る前に情報が漏れたことです。
- 10月20日 昼: 海外掲示板Hacker NewsでPHPの深刻な脆弱性情報がリーク
- 10月20日 夜: セキュリティ企業watchTowrが「未認証RCEの可能性がある」と検証、PHP公式が緊急で「10月21日14:00 UTCに修正版を出す」と異例の事前告知
- 10月21日 21時頃 (日本時間): 国家サイバー統括室が注意喚起、さらに高市早苗首相のXアカウントから「今夜11時に修正パッチが公開、速やかに適用準備を」と投稿
- 10月21日 23時: Cygamesが「PHPの脆弱性対応のため」と明記してウマ娘、グラブルなど4タイトルを一斉緊急メンテ。厚労省も介護サービス情報公表システムを停止
つまり、修正版がまだ存在しない段階で「今夜危険なものが出ます」と国までが言ったため、企業側はパッチを待たずに予防的にサイトを落とすしかなかったのです。これは2024年のPHP-CGI脆弱性(CVE-2024-4577)の時にはなかった動きです。
そもそもPHPとは?「70%」は誇張なのか?
動画が指摘していた「影響70%は誇張」という点は重要です。
W3Techs(2026年10月21日時点)によると、サーバー言語が判明しているサイトのうち69.3%がPHPを使っています。WordPress、Drupal、Joomla、Magento、EC-CUBE、みんなPHPで動いています。数字自体は間違いではありません。
ただ、今回の2件はこう評価されています。
- CVE-2026-109618: RCE via OOM corruption
- CVE-2026-109619: RCE via stale global state
- どちらも CVSS v4.0で9.2 (Critical)。10点満点ではありません。動画が言う通り「スコアはいつもの」です。
影響範囲は PHP 5.4以降の全バージョン で、Apache mod_php、PHP-FPM、CGI、FrankenPHP、LiteSpeedなど、Webリクエストを処理する全ての形態が対象。修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 として10月21日に緊急リリースされました。
「70%のサイトが一撃で乗っ取られる」わけではなく、攻撃条件はサーバーの設定に依存します。でも「WordPressを使っているなら、ほぼ確実にPHPを使っている」ので、WordPressサイト運営者は全員当事者です。
ここが最も誤解されるポイントです。
WordPress本体を7.1.3に更新しても、サーバーのPHPが8.2.35未満なら直りません。 WordPressはアプリ、PHPはその下の土台です。土台に穴が空いていたら、上の家をいくら補強しても意味がない。前回の.htaccess事件と同じく、WordPressの外側の問題なのです。
動画の核心 – 作業台と付箋でわかる脆弱性の中身
動画が秀逸だったのが「作業台と付箋」の例えです。専門用語を意訳して再現します。
あなたのサーバーを「パン屋の作業台」だと想像してください。
通常、PHPはお客さん(リクエスト)が来るたびに作業台を綺麗にして、付箋(内部状態)に「この生地はAさん用」と書いて作業します。終わったら付箋を剥がして台を拭いて次のお客さんへ。
今回のバグは2パターンです。
1. OOM corruption (CVE-2026-109618)
生地をこねている途中で小麦粉が切れた(メモリ不足)。本来なら「すみません、今日はここまで」と作業台をリセットすべきなのに、慌てて別の作業に飛んだ(longjmp)ため、前の人の生地が乗ったままの作業台を次のお客さんに出してしまう。前の人の生地に毒(攻撃者のデータ)が混ざっていれば、それを次の人が食べてしまう。
2. stale global state (CVE-2026-109619)
使い終わった付箋をゴミ箱に捨てたのに、壁の「次の作業はこの付箋を見て」という貼り紙が古いまま。次のお客さんが来た時に、もう捨てたはずの付箋(解放済みメモリ)の場所を見に行ってしまう。ゴミ箱に攻撃者が別の付箋を入れておけば、それを信じてしまう。
どちらも「前のリクエストの残骸を次のリクエストが使ってしまう」メモリ管理の欠陥で、結果として未認証の第三者がサーバー上で任意のコードを実行できる(RCE)可能性があります。
過去の脆弱性と何が違うのか
2024年6月に話題になった CVE-2024-4577 は、Windows + Apache + PHP-CGIという限られた環境でのみ起きる「引数インジェクション」でした。
今回のPHP2Shellは違います。
- Windows限定ではない、Linuxでも起きる
- CGI限定ではない、mod_phpでもFPMでも起きる
- プラグインやテーマは関係ない、PHPコアのバグ
だからこそ、WordfenceやCloudflareのようなWAFでも「完璧に防げる」とは言えず、公式も「外部のWAFは応急処置、必ずPHPを上げてください」と強調しています。
前回の記事で書いた Advanced IP Blocker のように、.htaccess に8,000行のIPを書く防御は、この種のメモリ破壊には完全に無力です。
WordPress運営者が今日やるべき4つのこと
1. まずPHPバージョンを確認する
WordPress管理画面 > ツール > サイトヘルス > 情報 > サーバー で確認できます。8.2.35未満、8.3.36未満、8.4.27未満、8.5.12未満 ならアウトです。
レンタルサーバーの場合、あなた自身では上げられません。
- Xserver: サーバーパネル > PHP Ver.切替
- ConoHa WING: コントロールパネル > PHPバージョン
- さくらのレンタル: コントロールパネル > PHPバージョン
共用サーバーならサポートにこの文面で依頼してください。
2026年10月21日公開のPHP脆弱性 CVE-2026-109618 / CVE-2026-109619 (CVSS 9.2) 対応のため、PHPを 8.3.36 または 8.2.35 以上にアップデートしてください。サーバーは [あなたのドメイン] です。
2. WordPress側の基本防御を再確認
PHPを上げた上で、過去の事件の教訓を活かします。
/wp-content/uploads/.htaccess にこれだけ置いてください。Bricksforgeのようなアップロード経由のRCEを止めます。
<FilesMatch "\.php$">
Require all denied
</FilesMatch>wp-config.php には
define('DISALLOW_FILE_EDIT', true);管理画面からのファイル編集を止めるだけで、万が一管理者が乗っ取られても被害が拡大しません。
3. プラグインの棚卸しは今も有効
今回のPHPバグと直接関係はありませんが、同時期に Bricksforge 3.1.8.9以前 (CVSS 10.0) や Essential Plugin系31種のサプライチェーン攻撃 も起きています。PHPを上げるついでに、不要なプラグインは削除してください。
4. バックアップを外部に
PHPが乗っ取られると、サーバー内のバックアップも一緒に暗号化・削除されます。UpdraftPlusなどでGoogle DriveやS3に日次で逃がしてください。
アップデート競争 – 5時間ルールはPHPでも同じ
動画の最後のポイント「公開後に始まるアップデート速度競争」は、WordPressの世界では 5時間ルール と呼ばれています。
Patchstackの観測では、WordPressの脆弱性は公開から平均5時間で悪用が始まります。今回のPHPも、Censysの観測で公開当日の夜から全世界でスキャンが始まりました。
企業がサイトを一斉停止したのは「5時間以内に上げられないなら、先に閉める」という判断です。あなたのサイトも、週末まで待つと手遅れになる可能性があります。
まとめ:土台から守るという発想へ
今回の事件で学ぶべきは3つです。
- 「満点10点」は誇張だが、9.2は十分に緊急。50団体が止めたのは正しい判断だった
- WordPressを最新にしても、PHPが古ければ意味がない。WordPressとPHPは別物
- .htaccessにIPを8,000行書くような防御は、PHPコアのバグには効かない。防御はCloudflareのような手前と、PHP本体の更新の両方が必要
前回の .htaccess 8,641行事件 は、あなたがプラグインを外して最小構成に戻したことで解決しました。今回はサーバー会社に連絡してPHPを上げてもらうだけで解決します。やることはシンプルです。
あなたのサイトのPHPバージョンはいくつでしたか? サイトヘルスで確認してください。
もし「8.2.34だった、どうしよう」という方がいれば、サーバー会社への依頼文面を置いておきます。
日本語版 – Xserver / ConoHa / さくら / ロリポップ向け
件名: PHP緊急セキュリティアップデートの適用依頼 – CVE-2026-109618 / CVE-2026-109619
お世話になっております。
[あなたのドメイン名] を利用しています。2026年10月21日に公開されたPHPの緊急脆弱性 CVE-2026-109618 / CVE-2026-109619 (CVSS 9.2 / PHP2Shell) について、サーバー側のPHPバージョンを確認させてください。
現在のバージョンが 8.3.36未満 / 8.2.35未満 の場合は、修正版へのアップデートとPHPプロセスの再起動をお願いいたします。
共用サーバーのためこちらで更新できないため、ご対応をお願いできますでしょうか。よろしくお願いいたします。
英語版 – Cloudways / Kinsta / DigitalOcean / 海外ホスティング向け
バンコク関連のサーバーや、英語サポートしかない海外ホスティングを使っている場合にどうぞ。
Subject: Urgent Request: PHP Security Update for CVE-2026-109618 / CVE-2026-109619 (PHP2Shell)
Hello support team,
I am writing regarding my domain [your-domain.com].
On October 21, 2026, The PHP Group released critical security fixes for CVE-2026-109618 and CVE-2026-109619 (CVSS 9.2, known as PHP2Shell) – unauthenticated RCE in PHP core.
Could you please confirm the PHP version currently running for my site, and if it is below 8.3.36 / 8.2.35 / 8.4.27 / 8.5.12, please upgrade to the patched version and restart PHP-FPM / web server?
The fixed versions are: 8.2.35, 8.3.36, 8.4.27, 8.5.12
Thank you for your urgent support.
Best regards,
[Your Name]
Wordpress サイト構築・管理 プラグインとテーマの試行錯誤