WordPressを更新しても直らない——2026年10月のPHP脆弱性問題を「ケーキ屋」に喩えて理解する

2026年10月21日、PHP本体に深刻度9.2（Critical）の脆弱性2件（CVE-2026-109618 / CVE-2026-109619）が公表され、同日に修正版が公開されました。ログインしていない第三者が細工した通信を送るだけで、サーバー上で任意のプログラムを実行できる可能性がある脆弱性です。世界のWebサイトの約7割がサーバー側でPHPを使っており、WordPressで作られたサイトはすべて対象になります。

この記事では、PHPとは何か、今回の脆弱性で何が問題なのか、WordPressを運用している人が今すぐ何をすべきか、そしてIDEA DESIGN®がなぜこの問題の影響を構造的に受けないのかを、ひとつのケーキ屋さんの物語に沿って説明します。技術の話をできるだけ技術の言葉を使わずに書きました。社内でこの問題を説明する必要がある方は、ケーキ屋さんの部分だけ読んでいただいても構いません。

---

ケーキ屋さんで読む、PHP問題の全貌

登場するもの

物語の中では	実際には
ケーキ屋「パティスリーWP」	WordPressで作られたサイト
店の土地	レンタルサーバー
厨房設備の規格（オーブン）	PHP本体
店の建物・看板	WordPress本体
内装・調理器具	テーマ・プラグイン
奥の棚のレシピ帳と顧客台帳	データベース（MySQL / MariaDB）
入口の警備員	Cloudflareなどのセキュリティサービス
厨房設備の業界組合	PHPの開発コミュニティ（The PHP Group）
セントラルキッチン方式の新店	IDEA DESIGN®（静的配信＋AIエージェント運用）

1. ふだんの営業

パティスリーWPは、客が注文するたびに店内の厨房でケーキを作って出す店です。厨房奥の棚にはレシピ帳と顧客台帳（DB）が置いてあります。客席と厨房は同じ建物の中。入口には警備員が立っていて、明らかに怪しい客は追い返します。

2. 2026年10月21日、リコール通知

厨房設備の業界組合から通知が届きます。「オーブンに設計上の欠陥がある。特定の書き方をした注文票を読み込ませると過負荷で誤作動し、注文票に書かれた指示をそのまま実行してしまう。改修キットを今日配布した。」

3. 看板を塗り直しても直らない

店主は慌てて店の看板（WordPress本体）を最新にし、内装（プラグイン）も入れ替えます。しかし欠陥はオーブンの規格そのものにあるので、何も変わりません。警備員（WAF）にも相談しますが、問題の注文票は見た目が普通の注文票なので、警備員には見分けられません。

4. 誰が改修するのか

改修キットを取り付けるのは、設備を貸している土地のオーナー（レンタルサーバー事業者）です。多くのオーナーはその晩のうちに取り付けました。しかし、自前で設備を持ち込んでいる店（VPS＝土地だけ借りて、設備の据え付けも改修も自分でやる契約）は自分でやらなければならず、「店の保守契約」には設備改修は含まれていないことが普通です。さらに、古い規格のオーブン（PHP 8.1以前）には改修キットが原則出ません。

5. ポストを開ける人がいない店

業界組合の通知は、すべての店のポストに届いています。問題は、ポストを開ける人がいるかどうかです。

毎日にぎわっているお店でも、店主はケーキを作るので手一杯で、設備の通知は「業者に任せている」つもりになっている。その業者（制作会社）は店を建てたときの契約が終わっていて、ポストの中身を見る義務はもうない。土地のオーナーは改修を終えたと案内を出しているが、その案内もポストの中。何年か前の催事の出店（期間限定のLPなど）に至っては、ポストがあることすら忘れられています。

営業が続いているかどうかは関係ありません。「通知を読んで、確認して、電話する役目を持つ人」が決まっていない店は、誤作動するオーブンのまま今日も注文を受け付けています。Webサイトなら、毎日更新されているコーポレートサイトでも、サーバーのPHPを誰が見るか決まっていなければ同じことです。

6. 厨房に入られると何が起きるか

客のふりをした侵入者は、まず奥の棚の顧客台帳を写真に撮ります。次にケーキに異物（ウイルス・マルウェア）を混ぜ、それを知らずに食べた客が体調を崩します。裏口に合鍵を作って隠すので、オーブンを改修しても何度でも戻ってこられます。同じ土地の隣の店（採用サイト・オウンドメディア・臨時LPなど）にも入ります。店主が気づくのは、保健所（Google）が店先に「危険」の貼り紙をしたときです。

被害者はこの店ではなく、この店の客です。つまり、パティスリーWPが加害者サイドになるのです。

7. セントラルキッチン方式

向かいに新しい店（IDEA DESIGN®︎）ができました。この店には厨房がありません。別の建物のセントラルキッチンで作り切ったケーキを運んできて、ショーケースに並べるだけです。客が店内で何をしても、厨房には届きません。誤作動するオーブンも、そもそも店内に存在しません。注文票を読み込む機械が店にないので、どんな注文票を渡されても何も起きません。

セントラルキッチンではAIエージェント（Octy）が働いていて、ポストを開けるのも通知を読むのも彼の仕事です。店主がケーキ作りで手一杯でも、担当者が異動しても、止まりません。そしてレシピ帳（Git）には、誰がいつ何を変えたかの履歴が全部残っています。

---

PHPとは何か

PHPは、Webサーバー上で「ページをその場で組み立てる」ためのプログラミング言語です。訪問者がURLを開くたびにサーバーでPHPのプログラムが実行され、データベースから記事を取り出し、HTMLに組み立てて返します。WordPressはこのPHPで書かれたCMSであり、PHPが動くサーバーの上でしか動作しません。

一言で言うなら、レンタルサーバーは「土地」、PHPは「厨房設備の規格」、WordPressは「店の建物」のようなもの。今回は設備の規格そのものに欠陥が見つかったので、店の看板や内装をいくら新しくしても意味がありません。

どこで動いているか

層	具体例	誰が管理するか
土地（サーバー）	エックスサーバー、さくら、ロリポップ、AWS	ホスティング会社 or 自社インフラ
設備の規格（PHP本体）	PHP 8.2 / 8.3 / 8.4 / 8.5	ホスティング会社が提供、利用者がバージョンを選択
建物（WordPress本体）	WordPress 6.x	サイト管理者（自動更新あり）
内装（テーマ・プラグイン）	Emanon、TCD、Contact Form 7 等	サイト管理者

誰が作っているのか

PHPは特定の企業の製品ではありません。1994年に生まれ、オープンソースのコミュニティ「The PHP Group」が開発を続けています。2021年に設立されたPHP Foundation（WordPressの運営元Automattic、JetBrains、Laravelなどが出資）が、コア開発者の雇用を資金面で支えています。Python、Ruby、Rustなど他の主要言語もコミュニティや財団の管理が多く、企業主導の言語（Go、Swift、Java）でもソースは公開されています。「コミュニティ開発だから危ない」という話ではなく、どの言語の実行環境にも脆弱性は起こり得ます。

MySQL / MariaDBとは

記事・ユーザー・設定を保存しておく「倉庫」です。WordPressは記事本文をHTMLファイルとして持たず、すべてこの倉庫に入れておき、PHPがアクセスのたびに取り出します。MySQLはOracleが所有する製品で、MariaDBはその分岐版。レンタルサーバーはどちらかを提供しています。今回の脆弱性との関係で言えば、PHPが乗っ取られるとこの倉庫の鍵（接続情報）が読めてしまう、という位置づけです。

PHPとJavaScriptは何が違うのか

PHPはサーバー側で動き、訪問者のブラウザには届きません。JavaScriptは主にブラウザ側で動き、届いたHTMLに動き（メニュー開閉、フォーム検証）をつけます。

ただしJavaScriptはNode.jsという仕組みでサーバー側でも動かせます。Node.jsを公開サーバーで常時動かしているサイトも世の中には多く、その場合はPHPと同じ構造です。つまり「言語」では今回の論点を区別できません。区別すべきは、「訪問者のアクセスを受けてからプログラムが動くか、受ける前に動き終えているか」です。

• アクセスを受けてから動く（動的生成）：WordPress＝PHP、Node.jsのSSR、Rails など
• アクセスを受ける前に動き終えている（静的生成）：IDEA DESIGN®＝ビルド時に一度だけ動く

なぜPHPがこれほど使われているのか

世界のWebサイトの約7割がサーバー側でPHPを使っています。この数字は、PHPという言語が技術的に優れているから生まれたものではありません。歴史と経済の積み重ねです。

2000年代、「訪問者ごとに違うページを出す」には、サーバー上で毎回プログラムを動かす以外の方法がありませんでした。PHPはそれを最も簡単に書ける言語で、月数百円の共用レンタルサーバーが標準で動かせる唯一の選択肢でもありました。そこに2003年、PHPで書かれたWordPressが登場し、やがて世界のサイトの4割を占めるまでになります。テーマ、プラグイン、制作会社、教材がすべてPHPを前提に育ち、「乗り換える理由」より「乗り続ける理由」のほうが多い状態が20年続きました。

一方で、公開サーバー上でプログラムを動かさない構成が現実的になったのは2010年代後半です。Gitで原稿を管理し、ビルドツールで一括生成し、CDNがほぼ無償で全世界に配信する。この3つが揃ってはじめて、「実行環境を公開面に置かない」という設計が、専門家でなくても選べるものになりました。

技術的には10年前から可能だったことが、なぜ広がらなかったのか。WordPressのエコシステムが強すぎて、変える動機がなかったからです。今回の脆弱性は、その動機をはじめて、エンジニアではない経営層に与えました。

ケーキ屋さんで例えるなら：PHPは「厨房設備の規格」。オーブンはこの規格で作られていて、店主が自分で選んだわけではなく、土地を借りたら最初からそれが入っていた。規格を決めているのはメーカーではなく業界組合で、どの店も同じ組合の規格を使っている。だから組合がリコールを出すと、全国の店が同時に対象になる。

---

今回の脆弱性で何が問題か

2026年10月21日（日本時間）、PHP開発元はCVSS 9.2（Critical）の脆弱性2件を修正しました。どちらも、ログインしていない第三者がサーバー上で任意のプログラムを実行できる可能性（RCE）があります。対象は「Webリクエストを処理するすべてのPHP」で、PHPで動くWordPressはすべて確認対象です。

2件の仕組み

	CVE-2026-109618	CVE-2026-109619
通称	OOM corruption	stale global state
何が起きるか	メモリ不足で処理が途中で止まり、初期化が終わっていないデータが「正常なもの」として使われる	前のリクエストで解放したメモリへの参照が残り、次のリクエストでそれが使われる
引き金	細工したファイル送信でメモリ上限に到達させる	致命的エラーやタイムアウトで参照が残り、次の処理で使われる
追加の影響	—	メモリ内容の漏えい

2件目は、窓口の担当者が前の来客の書類を片付け損ねたまま、次の来客の対応にその書類を使ってしまう状態にたとえられます。

なぜ「WordPressの更新では直らない」のか

1. 修正されたのはPHP本体であり、WordPress側をいくら更新してもサーバーのPHPは変わりません。WordPress公式も、本体の更新は不要で予定もないと明記しています。
2. Apacheのmod_php環境では、WordPressのコードが動く前の「開始処理」の段階で攻撃が成立する実証例があります。PHP上で動くセキュリティプラグインは、その時点でまだ動いていません。
3. 攻撃対象がログイン画面に限られません。PHPが処理するあらゆるページへのリクエストが入口になり得ます。

悪用された場合に起こり得ること

• データベース接続情報・認証キーの読み取り
• バックドア設置（PHPを更新してもファイルは残る）
• 管理画面を経由しないデータベース改ざん（ログイン履歴に残らない）
• 同じ実行ユーザーで動く他サイトへの波及

対策の結論

唯一の完全な対策はPHP本体の更新（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35以降）です。設定変更による応急措置について、開発元は「すべての経路を塞ぐものはない」と明言しています。PHP 8.1以前は通常サポート終了済みで、今回は例外的に最小限の修正が出ましたが、今後の保証はありません。PHP 8.2も2026年12月31日でサポートが終了します。

---

WordPress運用者が今すぐやるべきこと

結論から言うと、まずは自分のサーバーのPHPが修正版になっているかを確かめてください。

確認手順

1. WordPress管理画面 →「ツール」→「サイトヘルス」→「情報」タブ →「サーバー」で PHPバージョン と PHP SAPI（実行方式）を見る
2. バージョンが修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）以上なら対応済み。それ未満でも、配布元が修正だけを取り込んでいる場合があるので断定しない
3. サーバー事業者または保守担当者に3点を問い合わせる：修正は適用済みか／実行方式は何か（mod_php か PHP-FPM か）／未適用の場合の応急措置は何か
4. もしPHP 8.1以前なら、修正の有無に関わらずサポート中の系列への移行を急ぐ

誰が更新するのか

サーバーの種類	更新するのは誰か
共用レンタルサーバー	事業者（利用者が管理画面で系列を選ぶ場合あり）
マネージドWordPress	事業者（自動か手動かはサービス次第）
VPS・専用サーバー	自社または保守委託先。契約範囲の確認が必要

一般的なWeb制作・WordPress保守契約では、PHP本体の更新は対応範囲外のことが多くあります。「誰も担当していない」サイトが生まれる構造的な理由がここにあります。

更新に技術知識は必要か

作業は2段階に分かれます。

同じ系列内の修正版へ上げる（8.3.35 → 8.3.36）なら、事業者が適用するか管理画面のボタンひとつで済み、プログラミングは不要です。

古い系列から新しい系列へ移る（8.1 → 8.3）場合は、PHPの仕様変更で古いテーマやプラグインが動かなくなることがあり、互換性の確認、テスト環境での検証、コード修正が必要になります。制作会社に有償で依頼するのが一般的です。8.2も年末でサポート終了なので、来年には後者が必要になる人が増えます。

「WordPressはずっと更新が必要」の正体

更新対象はPHPだけではありません。

層	更新頻度	誰が気づくか
PHP本体	年に数回＋系列ごとのサポート終了	サーバー事業者からの通知を自分で読む
WordPress本体	月1回前後（自動更新あり）	ほぼ自動
テーマ・プラグイン	週単位。脆弱性の件数は圧倒的にここが多い	管理画面を開いて気づく

実はセキュリティ事故の大半はプラグイン由来です。今回のPHP脆弱性が注目されたのは、「WordPress側では一切対処できない」「ログイン不要で乗っ取れる」という組み合わせが珍しく、深刻だったからです。公開サーバー上で動く部品が3層あり、どれか一つでも放置すれば入られる、というのがWordPressの構造です。

やってはいけないこと

• WordPressのメンテナンスモードに切り替えて安心する：PHPがWordPressを読み込んだ後に動く仕組みなので、mod_phpの攻撃経路は止まりません。止めるならWebサーバー側でPHPに届く前に遮断します
• セキュリティプラグインやWAFで対応済みとみなす：開始処理で成立する経路には効きません
• エラーログが空だから安全だと判断する：PHPがログを書く前に失敗する場合があります

この手順が示していること

上の手順はすべて「人が気づき、人が問い合わせ、人が判断する」工程で成り立っています。担当者が異動したサイト、保守契約が切れたサイト、制作会社が廃業したサイトでは、この工程が誰にも回りません。脆弱性そのものより、この運用構造が放置サイトを生み続けていることが本質的な問題です。

ケーキ屋さんで例えるなら：店主がやるべきことは、まず自分の店のオーブンの規格番号を見て（サイトヘルス）、土地のオーナー（サーバー事業者）に「改修キットは付けたか」と電話すること。番号が古く見えても、オーナーが独自に改修済みのこともあるので、番号だけでは判断できない。「臨時休業」の貼り紙（メンテナンスモード）は、店員がレシピを開いてから出す仕組みなので、オーブンの誤作動を止められない。本当に止めるなら、オーナーに頼んで建物の入口を閉めてもらう。

---

「厨房に入られる」の何が問題か

厨房に入られると、客に出す料理そのものを好きに変えられます。

厨房でできること	実際に起きること
金庫の鍵を見る	wp-config.php からデータベースの接続情報を読み、会員情報・問い合わせ内容・注文履歴が丸ごと抜ける
料理に異物を混ぜる	全ページにマルウェアを仕込み、訪問者のPCを感染させる。被害者は自社の客
メニューを書き換える	ページ改ざん、偽の振込先、違法サイトへのリンク大量埋め込み（SEOスパム）
合鍵を作って隠す	バックドア設置。PHPを更新しても合鍵は残り、何度でも戻ってこられる
隣の店にも入る	同じサーバーの別サイトへ波及
店を人質に取る	データを暗号化して身代金を要求

本人は気づかないことが多いです。発覚するのは、Googleが「このサイトは危険です」と警告を出したとき、客から「おたくのサイトを見たら感染した」と連絡が来たとき、個人情報が闇市場で売られていたときです。

経営に翻訳すると、信用（検索結果に警告が付き流入が止まる。復旧後も再評価に数週間から数か月）、法的責任（個人情報漏えいは個人情報保護委員会への報告義務と本人通知が発生する）、コスト（調査・復旧・再発防止で数十万から数百万円）、取引先（大手との取引ではセキュリティ事故が契約解除や入札除外の理由になる）の4つです。

つまり自社が被害者になるのではなく、自社が加害者になります。マルウェアを配るのも、個人情報を漏らすのも、名義上は自社のサイトです。

---

IDEA DESIGN®のWeb構築体制

IDEA DESIGN®は「安全に更新する」のではなく「更新すべき実行環境を公開面に置かない」という設計です。訪問者が触れられるのは事前生成した静的HTMLだけで、PHPランタイム・データベース・管理画面はどこにも公開されていません。

非公開面と公開面

「非公開面で動く」とは、わかりやすく言えば「お客さんが入れない場所で作業が終わっている」ということです。

	どこで動くか	誰がアクセスできるか
非公開面	AIエージェント、Gitリポジトリ、ビルド環境	運用者とAIエージェントだけ。URLが公開されていない、または認証で守られている
公開面	Cloudflareのグローバルネットワーク	世界中の誰でも。ただし置いてあるのは完成済みのHTMLファイルだけ

各層の役割

層	使っているもの	セキュリティ上の意味	ケーキ屋さんで例えると
配信	Cloudflareのグローバルネットワーク（静的HTML）	公開サーバーに実行環境がない。PHPのRCEは前提が成立しない	店のショーケース。完成品を並べるだけで、店内に厨房はない
生成	Astro（ビルド時にHTMLを事前生成）	本番で動くコードがない	セントラルキッチン。店には完成品しか運ばない
変更管理	Gitリポジトリ	誰が何をいつ変えたかが全件残る。差し戻しも即時	レシピ帳。誰がいつどこを書き換えたかが全ページに残り、前の版にすぐ戻せる
運用	AIエージェント	更新・構造維持を継続。担当者不在でも放置状態にならない	セントラルキッチンで働くスタッフ。ポストを開け、通知を読み、作り続ける
管理画面	認証で保護された閲覧専用ダッシュボード	公開URLに管理画面を置かない。書き込み機能を持たない	店主だけが入れる事務所の窓。中の様子は見えるが、そこから厨房は操作できない
動的機能	サーバーレス関数／外部サービス	必要な機能だけを最小の権限で切り出す	注文受付だけを外注の窓口に任せる。窓口の人は厨房にも事務所にも入れない

WordPressとの対比

WordPressは「公開サーバーの上で、毎回ページを組み立てる」。IDEA DESIGN®は「非公開の場所で先に組み立て、完成品だけを公開する」。攻撃者が触れられる面積が根本的に違います。

---

よくある懸念と、それに対する答え

AIエージェントにWebサイトの運用を任せることに、不安を感じる方は少なくありません。その懸念は正しいと考えています。だからこそ、こう設計しています。

「AIが勝手にサイトを書き換えるのが怖い」
→公開面に直接触る経路はありません。変更は必ずGitを経由し、履歴に残り、差し戻せます。公開前に人の承認を挟む運用設計も可能です。

「AIエージェントがハッキングされたら全部やられるのでは？」
→AIエージェントは非公開面で動き、公開面は静的HTMLのみです。AIエージェントの権限は最小化し、Gitの履歴で異常な変更は検知できます。「常時公開されている管理画面」よりも攻撃面は狭くなります。

「社内のセキュリティポリシーでAIツールが使えない」
→AIエージェントが扱うのは公開前提のWebコンテンツで、顧客データや社内機密は扱いません。学習利用の有無、データ保存先、処理リージョンは文書で提示できます。規程との照合は診断の中で一緒に行います。

「担当者の仕事がなくなるのでは？」
→置き換えるのは「更新作業」であって「判断」ではありません。担当者は指示と承認に集中できます。

「自社で触れなくなるのが不安（ベンダーロックイン）」
→コンテンツはMarkdown、コードはGit上にあり、標準技術（Astro、Cloudflare）で構成されています。契約終了後も全資産を持ち出せます。

「フォームや会員機能（動的機能）はどうなるのか？」
→必要な機能だけをサーバーレス関数や外部サービスで切り出します。公開面に実行環境を置かない原則は維持したまま実現できます。

「静的サイトなら自社でもできるのでは？」
→できます。ただ、静的化自体はあくまで手段であって、IDEA DESIGN®の価値の本質は「放置状態を生まない継続運用」と「AI検索から推奨される構造の維持」にあります。静的化だけで十分なら、それで構いません。

IDEA DESIGN®を選ばない場合でも

もしWordPressをお使いの場合には、次の3点だけはご確認ください。

1. 「WordPress運用者が今すぐやるべきこと」の確認手順（PHPバージョン・実行方式・修正適用の問い合わせ先）
2. PHP 8.2が2026年12月末でサポート終了になる事実と、移行計画の必要性
3. 「誰がPHPを更新する契約になっているか」を保守契約書で確認すること

次に脆弱性が出たとき、この記事を思い出していただければ十分です。

---

おわりに

今回の脆弱性が示したのは、PHPやWordPressが悪いということではありません。「公開サーバーの上で、訪問者のアクセスを受けてからプログラムを動かす」という20年来の構造が、人の注意力に依存しすぎているということです。ポストを開ける人がいない店は、今日もどこかで営業しています。

IDEA DESIGN®チームでは、WordPressサイトの移行相談と無料診断を受け付けています。診断は、サイトURLを送っていただくだけで、PHP・WordPress依存の状況、放置リスク、AI検索対応状況を確認して結果を返送します。

---

参照

• PHP公式 News Archive 2026 — https://www.php.net/archive/2026.php
• GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」 — https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp「RCE via stale global state」 — https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」 — https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
• wp.geek「2026年10月のPHP脆弱性でWordPressに何が起きる？仕組みと懸念点を解説」 — https://wpmake.jp/contents/security/php-vulnerability-wordpress/