PHPの重大な脆弱性、WordPressは大丈夫？影響・確認・その後の管理【2026年】（CVE-2026-109618）

2026年10月22日 09:48

10月21日の夕方、PHP公式のニュースを開いたら、その日の修正が2件並んでいました。認証なしで、サーバー側の命令を実行されうる、という書き方です。WordPressの画面の不具合ではありません。英語圏の通称は php2shell です。CISAがこの2件をまとめてそう呼んでいます。PHP公式の告知本文には、この通称は出てきません。

自分は宜野湾で、WordPressのホームページを作って、公開のあともPHPを見てきました。この種類の告知は、たまに出ます。今回は温度が違います。公式がリスクが最も高いと書いたApacheのmod_phpでは、認証のないリクエストが、アプリケーションのコードが動く前に通りうる、と実証の話まで書いています。深刻度はCVSS v4.0で9.2。直す本筋は、WordPressの「更新」ボタンではなく、PHPそのものです。

管理画面を最新にしても、サーバーのPHPが古ければ、今回の穴は開いたままです。HTMLだけのページでも、同じサーバーがPHPを外から動かしているなら、無関係とは言い切れません。先に知りたいのは、どのPHPがウェブのリクエストを受けているか、です。作り直しは、そのあとで足ります。自分は、この告知を読んだ週に様子見はしません。

突き合わせたのは、2026年10月21日の夕方から22日にかけてのPHP公式、CISA、英国NCSC、IPAの事前告知、PHP Foundation、Google Cloud、CERT-EU、ENISAです。攻撃のやり方は書いていません。確認できたことと、まだ追えていないことは、文中と末尾で分けています。

宜野湾市伊佐でホームページを見ている鈴木孝昌です。屋号は沖縄ホームページ制作工房WEBCRAFTS。1993年頃からの実務で、WordPressは宜野湾の現場で保守してきました。官公庁のサイトも、大手のサイトも、Astroで作ってきました。今回の番号は、その現場の話として書いています。

2026年のPHP脆弱性は、WordPressの更新では届かない

対象は、ウェブのリクエストを処理しているPHPです。直す本筋はPHPそのものの更新です。WordPressの「更新」ボタンは、別の層です。ここを取り違えると、管理画面は最新なのに穴だけ残ります。

2026年10月20日、PHPのセキュリティチームは、翌21日に重大な修正を出す、と事前告知しました。予定時刻は14:00 UTCで、深刻度は2件ともCVSS v4.0で9.2、と告知にあります。実際の修正版は2026年10月21日に公開されました。Google Cloudの同日の説明では、公表に関わった調査側としてWiz Researchの名前が出ています。発見の経緯の細部は、この記事では公式のセキュリティ告知以上には広げていません。分単位の時刻は、PHP公式のニュース一覧には書いてありません。CERT-EUは13:30 UTC、ENISAは13:40 UTCと書いていて、ここは出典がずれています。日付は10月21日、として扱います。

番号は次の2件です。

CVE-2026-109618（GHSA-w8hw-w9fx-j79w）。メモリ不足の処理の途中で、リクエストの内部データが中途半端なまま残り、あとからそれを正しいデータとして扱ってしまう、という問題です。
CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）。リクエストが使っていた内部状態が、メモリを解放したあとも残り、同じ作業プロセスが次のリクエストでその古い状態を使ってしまう、という問題です。

PHP公式は、どちらも認証なしの遠隔コード実行につながりうると書いています。攻撃が成立すると、そのPHPの作業プロセスの権限で、命令の実行、そのプロセスから見えるデータの読み取り、処理の停止が起きうる、という整理をAWSも出しています。Google Cloudは、コード実行に加えて、メモリ上の情報が見えてしまう可能性にも触れています。どこまでが実証で、どこからが影響の範囲の説明かは、ベンダーごとに書き方が違います。ログインがいらない、というのが今回の重さです。管理画面のパスワードが強いかどうかの前に、PHPがリクエストを受けた時点で通りうる、と公式はmod_phpについて書いています。日本国内の被害が確認された、という公的発表は、原稿をまとめている10月22日の時点では見つけられていません。被害の記事を待ってから動く週ではない、と自分は見ています。

通称の php2shell（ピーエイチピー・ツー・シェル）は、CISAの10月21日の注意喚起が、この2件をまとめてそう呼んでいます。オランダNCSCの整理用リポジトリの名前にも使われています。PHP公式のセキュリティ告知の本文では、確認した範囲ではこの通称は出てきません。2件のうち片方だけを指す公式の別名、という対応表も、公式文からは読めていません。

普段のホームページに関係があるのは、PHPが「サーバーの中で、訪れた人のリクエストを受けてページを組み立てる」役だからです。会社案内、予約、お問い合わせ、WordPressの管理画面。動的なページの多くが、この層の上に乗っています。

技術的には、何が問題なのか

アプリケーションのPHPファイルを開くより前の、PHP本体の受け取り処理に問題がある、という指摘が公式側にあります。ただし、すべての動かし方で同じ、とまでは書かれていません。

一般の方向けに言い換えると、こうです。ホームページのプログラムは、訪問者がページを開いたとき、サーバーの中のPHPが「このリクエストを処理して」と仕事を始めます。今回の問題は、その仕事の開始や、エラーで途中終了したあとの片付けにあります。サイトに書いた文章や、WordPressのプラグインの善し悪しとは別です。建物で言えば、店舗の内装ではなく、電気の引き込みに不具合がある、という位置です。

技術者向けには、PHP公式の文を崩さずに置きます。

CVE-2026-109618は、メモリ不足の処理が、内部のリクエストデータが一部しか初期化されていないタイミングでPHPを中断しうる、という説明です。片付けの処理が、その不正なデータを妥当なものとして扱う、と公式は書いています。PHP Foundationは、Apacheのmod_phpでは、認証のないリクエストが、アプリケーションのコードが動く前にこの問題を起こし、初期設定のままで遠隔コード実行が示された、と書いています。同じFoundationの文章では、PHP-FPMでも遠隔コード実行は確認されたが、それはアプリケーション側の処理経路を通った、とも書いています。「どのサイトでも、プログラムが一行も動く前に必ず侵入される」とは、公式は言っていません。実証の話は、mod_phpの例と、FPMではアプリケーション側の経路、と分けて読む必要があります。

CVE-2026-109619は、解放済みのメモリを指したままの内部状態が残り、同じワーカーが処理する次のリクエストが、初期化でリセットされる前にその状態を使いうる、という説明です。PHP Foundationは、use-after-free（解放後のメモリ参照）とワーカーの停止は確認され、Apacheのmod_php上の実在アプリケーションに対して遠隔コード実行が示された、と書いています。

PHP公式がリスクが最も高いと考えるのは、Apache + mod_phpです。対象に名前が挙がっているのは、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedです。Nginxそのものに穴がある、という話ではありません。NginxがPHP-FPMへリクエストを渡しているなら、渡した先のPHPが対象です。

コマンドだけに使うPHP（CLI）について、公式の「誰が危険か」は「ウェブのリクエストを処理しているPHP」です。php -v の表示が、ウェブサーバーと同じ版とは限りません。CLIだけが古くて、ウェブにPHPを渡していないなら、この告知の主対象とはずれます。CLIに外部の入力を流しているバッチまで安全、とは書いてありません。そこは環境ごとの確認です。

実証コードが公開の場に出始めた、という記述はCERT-EUの10月21日の注意喚起にあります。それは「侵入の成功が日本で確認された」こととは別です。CISAは、公表時点ではこの脆弱性の悪用を観測していない、と書いています。攻撃通信の観測、実証コードの流通、実際の侵害。この三つは、別の事実です。原稿をまとめている10月22日でも、CISAの文面は10月21日公表の「観測していない」のままです。その後に悪用の観測が出ていないかは、公開のたびに公式を見る話です。観測されていないことと、通らないことは、別です。実証コードが出始めた週に、古いPHPをインターネットへ向けたままにする理由は、自分には見つかりません。

一時的な設定変更は、PHP公式が「特定の経路への露出を下げるが、安全にはしない」と書いています。メモリ上限の扱い、送信サイズの上限、セッションのアップロード進捗を止める設定、PHP 8.5では致命的エラーのバックトレースに関する設定、が告知に並びます。公式は同時に、「完全な対策は更新だけ」とも書いています。設定名と適用の注意は、PHP公式の2026年ニュースに揃えます。WAF（ウェブアプリケーションファイアウォール。不審な通信を手前で落とす仕組み）も、CISAは更新までの一部の保護にはなりうる、と書いています。WAFを入れただけで直った、とは扱いません。

影響を受けるPHPのバージョン

いまサポート中の8.2、8.3、8.4、8.5は、それぞれ指定の版以降に上げる話です。8.1以前は、PHPプロジェクトの通常の修正リリースはありません。

PHP公式が「これに更新する」と書いた版は、8.5.12、8.4.27、8.3.36、8.2.35です。AWSのセキュリティ掲示は、各系統の影響範囲を次のように整理しています。Google Cloudも、影響をPHP 5.4から8.5.11まで、修正版を同じ4つ、としています。

系統影響として整理されている範囲公式の修正版8.58.5.0〜8.5.118.5.128.48.4.0〜8.4.268.4.278.38.3.0〜8.3.358.3.368.28.2.0〜8.2.348.2.358.1以前PHPプロジェクトの通常リリースはなし下記

8.2は、PHP公式が「2026年12月31日でサポート終了となり、その後はこの系統のセキュリティ修正を出さない」と、8.2.35のリリース文に書いています。今回の修正は入っても、この系統に居続ける判断は、年末までの話です。

8.1以前について、公式は二段に書いています。通常の更新は出さない。そのうえで、深刻さゆえに、ソースから自分でビルドする人や、長期サポートのベンダーがいない人向けに、7.4、8.0、8.1の最小のソース差分を出した、とあります。これは公式の新バージョン番号とは別物です。Linuxディストリビューションや、長期サポートの事業者がパッケージに取り込み直した修正（バックポート）も、また別です。公式は、ディストリビューションとLTS事業者には事前にパッチを渡した、と書いています。UbuntuやRed Hat、Debian、国内のレンタルサーバーが、原稿をまとめている10月22日の時点でどのパッケージを配り終えたかは、一件ずつ確認できていません。配り終えた連絡が来るまで「うちは大丈夫」にはしません。サーバー会社の案内か、契約中の管理画面が、その確認先です。Amazon Linuxは、AWSが10月22日を目安に更新パッケージを出す、と10月21日の掲示に書いています。出てからの適用状況は未確認です。

ボランティア運営の rpms.remirepo.net は、公開当日には更新がない、とPHP公式が警告し、ディストリビューションのパッケージかソースビルドへの切り替えを勧めています。

WordPressを使っているサイトは危険？

WordPressを使っていること自体が、今回の欠陥ではありません。それでも、そのWordPressを動かしているPHPが古く、外からリクエストを受けているなら、対象の真ん中です。管理画面の本体とプラグインが最新でも、PHPが8.5.11まで、8.4.26まで、8.3.35まで、8.2.34までなら、今回の修正は入っていません。8.1以前は、PHPプロジェクトの通常の修正リリースそのものがありません。

WordPressは、記事も設定もデータベースに置き、ページを開くたびにPHPが組み立てます。テーマもプラグインも、そのPHPの上で動きます。だから、PHP本体の脆弱性は、WordPressの利用者に届きます。一方で、これはWordPress本体の脆弱性番号ではありません。プラグインの放置は、別の入口として昔からあります。今回の話と、プラグイン未更新の話は、同じ「WordPressが悪い」にはまとめません。両方あり得ますが、直す場所が違います。

WordPressの管理画面で本体やプラグインを更新しても、サーバーに入っているPHPのプログラムは入れ替わりません。管理画面の更新は、WordPressのファイルの話です。PHPの更新は、サーバー会社の管理画面か、自分でサーバーを持っている場合はそのOSのパッケージの話です。

バージョンの見え方は、次の場所です。

WordPressの管理画面なら、「ツール」→「サイトヘルス」→「情報」→「サーバー」に、PHPのバージョンが出ます。ここは、ウェブとして動いているPHPに近い表示です。サーバーにSSHで入って php -v を打った結果は、コマンド用のPHPであることがあります。数字が二つあるときは、ウェブ側が優先です。

レンタルサーバーの場合、利用者がPHPを自分でコンパイルする契約は少ないです。コントロールパネルに「PHPのバージョン」という切り替えがある会社もあれば、会社側がまとめて上げる会社もあります。原稿をまとめている10月22日の時点で、国内のどの社が上げ終えたかの一覧は、この記事では未確認です。見るものは、サーバー会社からのメール、管理画面のお知らせ、サイトヘルスのバージョン、の三つです。「レンタルサーバーだから自動で上がった」は、その三つが揃うまで置きません。沖縄の会社サイトでも、ここが空欄のまま週末に入るケースを、自分は何度も見ています。

制作会社に聞くときは、次を一文ずつで足ります。ウェブで動いているPHPのバージョンは何か。誰がそれを更新する契約か。今回の8.5.12、8.4.27、8.3.36、8.2.35、またはベンダーのバックポートを、いつ入れるか。入れたあとに、管理画面とフォームと予約が開くかを誰が見るか。ログイン情報をチャットで全部送る必要はありません。バージョンと、更新の担当と、日付が返ってくれば、会話は前に進みます。

自社のサイトが、このPHPの上に乗っているか分からないときは、画面をいじる前に、制作会社かサーバー会社へ聞く方が安全です。PHPの更新状況も、誰がサーバーを見ているかも曖昧なまま、管理画面のボタンを押す必要はありません。相談の窓口は、お問い合わせ・無料相談です。セキュリティの完全な検査を約束するページではありません。現状のPHPと、更新の担当が誰かを、一緒に切り分ける入口です。宜野湾が拠点で、県内は対面、県外はオンラインで話しています。

WordPressを長く載せるときの保守の話は、沖縄の社長さんのためのWordPress保守に、更新とバックアップの見え方を書いています。作り方そのものは、WordPress制作です。

PHPを使っていないサイトも危険なのか

「PHPというソフトがパソコンのどこかにある」ことと、「インターネットから、そのPHPにリクエストが届く」ことは別です。届かないなら、今回の告知の主対象ではありません。届くなら、サイトの見た目がHTMLでも対象になりえます。

並べると、こうなります。

状態今回の告知との距離PHPがインストールされているだけウェブに渡していなければ、公式がいう「リクエストを処理しているPHP」ではない。ただし置き忘れの .php が公開ディレクトリに残っていないかは別確認PHP-FPMが動いていて、ウェブサーバーがそこへ渡している対象。NginxでもApacheでも、渡した先がPHPなら同じApacheでmod_phpが有効公式がリスクが最も高いと書いた構成。アプリケーションのコードの前に成立しうる、という実証の話がここにあるHTML・CSS・JavaScriptだけで、PHPへ渡す設定がないその配信経路については、今回のPHPの穴を踏まない。ホスティングの別設定でPHPが有効なら、そちらは残るWordPressを静的HTMLに書き出したが、元のWordPressが同じサーバーで生きている見た目のHTMLはPHPを踏まないことがある。管理画面や xmlrpc.php などが残っていれば、PHP側は残っているPHPを実行しない静的ホスティングリクエストがPHPに届かないなら、今回の主対象外。フォームの送信先が別のPHPなら、その送信先は別途

静的サイトにすれば今回の件が消える、とは書いていません。配信の仕方がPHPを外しているか、です。

今すぐ実施したい対策

更新が本筋です。設定変更とWAFは、更新までの時間を稼ぐだけで、穴は塞がりません。自分なら、今日中に版を見て、上げられるなら上げて、上げられないなら「誰が、いつ上げるか」を今日返します。権限がない人が、管理画面を勘で触って直した気になる順番にはしません。

一般の方の順番は、次です。

自社のホームページが、WordPressか、それ以外のPHPか、HTMLだけかを、制作会社かサーバー会社に聞く。
ウェブで動いているPHPのバージョンを、サイトヘルスか、サーバー会社の案内で知る。
8.2〜8.5なら、公式の修正版以上か、サーバー会社の「対応済み」案内があるかを見る。8.1以前なら、バックポートがあるのか、PHPを上げるのかを聞く。
自分でサーバーを触れる人だけが、不要なPHPの実行を止める判断をする。ログインできない人は、ここで止まって任せる。
お問い合わせフォームや管理画面のURLが、意図せず公開のままになっていないかを、知っている人に見てもらう。
サイトが急に見慣れない広告や、自分の書いていないページを出していないかを見る。見た目が普通でも、侵入していない証明にはなりません。
バックアップが、いつ、誰の、どの世代で残っているかを聞く。
WAFは、更新までの補助としてサーバー会社に有無を聞く。入れて終わりにしない。
更新のあと、トップ、フォーム、予約、管理画面のログインを開いて見る。
今月直して終わりにせず、誰が毎月バージョンを見るかを一人決める。

サーバーを自分で見ている人の作業は、公式の対象SAPI（PHP-FPM、mod_php、CGI、FrankenPHP、LiteSpeed）の棚卸しと、インターネットに出ているものから先の更新です。修正は、PHP公式の版と、OSベンダーのパッケージを混ぜずに読みます。php -v と、ウェブの phpinfo やサイトヘルスが違うなら、ウェブ側です。暫定の設定は、プールやApacheの設定で、アプリケーションから上書きできない場所に置く、と公式が書いています。ワーカーの再起動までして、初めて効く項目があります。すぐ上げられない場合、暫定策も間に合わないなら、直るまでインターネットから外す判断もありうる、という温度でNCSCも書いています。止めるかどうかは、売上と告知の影響を見て、権限のある人が決める話です。

すでに侵害されたかもしれない、という判断は、この記事だけではできません。見慣れない管理者ユーザー、知らないファイル、夜間の大量のPOST、PHPのプロセスがシェルを起動している、といった兆候は、CISAも「不審な動きとして見てほしい」と書いています。兆候があるときは、先にバックアップを上書きしない方が安全です。消す前に、見られる人に残す。全部消して「直った」にすると、入り口が残ります。

ホームページを長期間放置すると、何が積み重なるか

今回のPHPだけの話ではありません。放置は、入口が何段にも増える、ということです。

WordPress本体の更新が止まると、本体側で直った不具合が残ります。プラグインとテーマは、作者が更新をやめた瞬間に、直す人がいないコードになります。PHPのサポート終了は、言語そのものに修正が来なくなる、という段です。今回の8.1以前が、まさにその段にいます。

管理者アカウントを、退職した担当者のメールのままにしておくと、パスワードのリセットも、サーバー会社への本人確認も止まります。バックアップが「どこかにあるはず」だと、壊したあとに戻す先がありません。不正アクセスに気づくのが遅れると、改ざんが検索に載ります。検索エンジンは、危険なページに警告を出すことがあります。顧客の問い合わせ内容や、予約の個人情報が同じサーバーにあるなら、漏えいの相談先は、サイトの見た目を直す人とは別に、個人情報の窓口になります。ここは一般論です。今回の2件で、日本の顧客情報が漏れた、という確認は取れていません。

今回の脆弱性に固有なのは、PHPをウェブに出している限り、WordPressをどれだけきれいにしていても、本体の受け取り処理が古いと届く、という点です。固有でないのは、放置したプラグイン、弱いパスワード、バックアップなし、です。両方を、同じ恐怖の文章には混ぜません。

格安で納品したあとに更新の責任が空欄になる構造は、WordPressの格安制作と、あとからかかる費用に書いています。

ホームページの管理者がいないときは

権限のない人が、復旧のつもりでログインを繰り返す話ではありません。最初に集まるのは、操作ではなく、契約の所在です。

よくあるのは、制作会社と保守契約を結んでいない、担当者が退職した、制作会社が閉じた、WordPressに入れない、サーバーの契約番号が分からない、ドメインの更新メールが誰の受信箱か分からない、PHPの上げ方が分からない、何年も記事を書いていない、です。この状態で「とりあえず管理画面のパスワードを何回も試す」は、ロックされるだけで、PHPは古いままです。

先に紙かメモに残すものは、次です。ドメイン名。サーバー会社の名前（請求メール、クレジットカードの明細に残っていることが多いです）。ドメイン管理会社の名前（サーバー会社と違うことがあります）。WordPressに入れた最後の人の名前。FTPや管理画面のメモが、退職者のPCに残っていないか。サイトの目的（名刺代わりか、予約か、採用か）。

専門家に頼む作業は、そのあとです。ログインの回復、PHPのバージョン確認、更新の可否、バックアップの有無、不要なPHPの停止、フォームが動くかの確認。管理権限がない状態で、外部の人間が魔法のように中へ入れるわけではありません。契約者本人の確認が、サーバー会社から求められます。そこを飛ばす依頼は、受けても前に進みません。

制作会社との保守がないサイトも、相談自体は受けています。管理の所在を整理し、更新できる状態に戻すところまでが、WEBCRAFTSの作業の範囲です。窓口はお問い合わせ・無料相談です。料金は、ログインできるか、サーバーの契約が分かるか、予約機能があるかで変わるので、この記事では金額を書きません。宜野湾の事務所で、請求書とドメイン名だけ持って話に来る形でも足ります。

WordPressをやめて、静的サイトへ移すべきか

移した方がよいサイトと、WordPressのまま保守した方がよいサイトが、両方あります。今回の脆弱性を、静的化の強制理由にはしません。

セキュリティだけを見ると、ページを開くたびにPHPとデータベースが動かない構成の方が、今回のような言語本体の穴は踏まない方向です。維持費は、更新の手間が減るかわりに、記事を出す手順が変わることがあります。表示は、できあがったHTMLを渡すだけなので速くしやすいです。SEOは、URLとタイトルと本文と、検索向けの案内文を移せば維持できることが多いです。移すときにURLを変える、本文を薄くする、だと落ちます。速さそのものが順位を保証するわけではありません。

フォームは、静的HTMLだけではメールを受け取れません。外部のフォームサービスか、別の小さな受け口が要ります。ブログを週に何本も出す、会員だけが見るページがある、在庫と連動している、なら、管理画面が残るWordPressの方が楽なことが多いです。初期費用は、静的への作り直しの方が、保守を続けるより先に出ます。長い運用では、プラグインの衝突が減るかわりに、フォームや予約のつなぎを自分たちで持つコストが残ります。

静的サイトを組み立てる道具には、Astro、Hugo、Eleventyなどがあります。Astroは、必要なページだけを先にHTMLへ組み立て、必要なところにだけプログラムを載せる考えの道具です。自分は、官公庁のサイトも、大手のサイトも、Astroで作ってきました。庁名や社名は、公開してよいものだけが外に出ます。ここでは、その実績がある、という事実だけ置きます。HugoとEleventyも、先にHTMLを作る系統です。自分が納品している静的の土台はAstroです。HugoとEleventyを、いつでも同じ条件で納品している、とは書きません。

三つの選び方を、同じ条件で置きます。

WordPressを続けて、PHPと本体とプラグインとバックアップを見る。更新担当が社内か社外に残っていて、予約や会員があるなら、こちらが素直です。今回の件は、PHPを上げれば足ります。上げる人がいないなら、保守の契約が先です。

いまのWordPressを、静的なHTMLに書き出す。見た目とURLを大きく変えたくないときの途中案です。書き出したあとに、元のWordPressを同じ公開領域に残すと、PHPは残ります。止めるところまでが作業です。

静的サイトとして、構成から作り直す。ページ数が読めて、更新はお知らせ程度、速度と更新漏れを減らしたい、というときに候補です。初期の作り直し費用はかかります。移行の考え方は、WordPressとAstroの役割分担に、売り込みではなく条件で書いています。宜野湾での制作の入り口は、ホームページ制作宜野湾です。

静的サイトなら、もう見なくてよいのか

見なくてよい、にはなりません。減るのは、PHPとデータベースを毎回動かす攻撃の面です。残る管理は、別にあります。

ホスティングの公開設定を誤ると、テスト中のページが外から見えます。ドメインとDNSの更新を止めると、サイトは健全でも名前が期限切れになります。外部のJavaScript（アクセス解析、予約ウィジェット、チャット）は、その提供元が変わると、自分のHTMLが正しくても表示や情報の扱いが変わります。フォームサービスは、送信先のアカウントが退職者のまま、という事故が起きます。Astroなどで作る場合、部品のライブラリに不具合が出ます。サイトの本体が静的でも、部品の更新は残ります。GitHubなどのアカウント、公開権限、バックアップ、改ざんや落ちていないかの見回り。ここは静的にしたあとも、誰かの仕事です。

「静的にしたからセキュリティは終わり」は、PHPの話を別の放置にすり替えただけ、になります。

Webサイトの確認では、何を見るのか

外から見えるものと、管理者しか見れないものは、混ぜません。料金表はこの記事にはありません。メニューとして定価を公表しているページも、いまのWEBCRAFTSにはありません。

外から、ログインなしで見られるのは、HTTPSになっているか、証明書の期限が切れていないか、管理画面のURLが簡単に見つかるか、明らかに古いWordPressの画面が出ていないか、不要なインストール用ファイルが残っていないか、くらいです。PHPの正確な版は、エラー画面に出てしまうこともありますが、出ていないことの方が多いです。出ていないことを、新しい、とは判断できません。

管理者の権限がないと分からないのは、PHPの正確な版、プラグインとテーマの一覧と更新日、管理者ユーザーの人数、バックアップの世代、サーバーのログ、WAFの有無、です。セキュリティヘッダー（ブラウザに「このサイトはこう読んで」と伝える応答の付属情報）も、応答を見れば外から分かりますが、直すのはサーバー側です。

軽い確認は、「版がいくつで、誰が更新担当か」を切り分ける会話です。詳しい確認は、ログ、アカウント、バックアップ、公開してはいけないファイルまでを、権限をもらって見る作業です。後者を、前者の値段で約束はしません。完全に安全、とも言いません。見た範囲と、見ていない範囲を、紙に残すのが確認の仕事です。

直したあとに、残る仕事

今回のPHPは、修正版に上げれば、この2件については公式の修正が入った状態になります。その翌月に、別のプラグインの不具合は普通に来ます。ホームページは、公開した日に完成して、その後は看板として置いておくものではありません。看板の裏で、PHPと、証明書と、ドメインと、問い合わせの届く先が、毎月だれかに見られている必要があります。

自分は、宜野湾でホームページを作って、公開のあとに「更新は誰がしますか」が空欄のまま戻ってくる現場を、何度も見ています。今回は、その空欄が言語の本体まで届いた週です。すでに日本中がやられている、とは書きません。CISAは公表の時点では悪用を観測していない。一方で、実証コードは出回り始めた、とCERT-EUが書いています。観測の見出しを待ってから動く週ではない、と自分は見ています。全部を静的にする必要はありません。静的が合うサイトは、合います。WordPressのまま、PHPを上げて、毎月見る人を決める方が合うサイトも、多いです。どちらでも、今週のPHPを空欄のままにしない、が先です。

安全性の確認、その後の保守、必要なら静的な作りへの切り替え。この三つは、別の商品を三つ売る話ではなく、同じサイトの「誰が来月も見るか」の答えです。いまのサイトを残す方がよいか、管理の手数を減らす構成に変える方がよいかは、予約と更新の頻度を聞いてから決めます。窓口はお問い合わせ・無料相談です。県外でも、画面を共有しながらバージョンの読み方から話せます。

よく聞かれること

今回のPHPの脆弱性とは何ですか

2026年10月21日に公開された、PHP本体の2件です。番号はCVE-2026-109618とCVE-2026-109619で、どちらもCVSS v4.0で9.2と告知されています。ウェブのリクエストを受けるPHPで、認証なしの遠隔コード実行につながりうると、PHP公式が書いています。

WordPressは危険ですか

WordPress本体の欠陥、という発表ではありません。WordPressが動いているPHPが古く、外からリクエストを受けているなら、対象に入ります。新しいPHPの上なら、今回の2件については公式の修正が入った状態です。プラグインの放置は、別の問題として残ります。

WordPressを最新にすれば安全ですか

今回の2件については、足りません。WordPressの更新は、WordPressのファイルを入れ替えます。PHPのプログラムは、サーバー側の更新です。両方を、担当が違う作業として分けます。

PHPを使っていなければ問題ありませんか

そのサイトへのリクエストがPHPに渡っていないなら、今回の告知の主対象ではありません。同じ契約のサーバーでPHPが有効、書き出したあとのWordPressが残っている、フォームの受け先がPHP、なら、そこは別です。

PHPがインストールされているだけでも危険ですか

公式が危険としているのは、ウェブのリクエストを処理しているPHPです。入っているだけで、外から実行できない状態は、同じ危険度とは書いていません。公開フォルダにPHPファイルが残っていないかは、別の確認です。

HTMLだけの静的サイトなら安全ですか

PHPへ処理を渡していない配信なら、今回の穴は踏みません。絶対に安全、とは言えません。証明書、ドメイン、外部のスクリプト、フォーム、アカウント、バックアップは残ります。くわしくは「静的サイトなら、もう見なくてよいのか」に書きました。

PHPのバージョンはどこで確認できますか

WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」です。コマンドの php -v は、ウェブと違うことがあります。レンタルサーバーは、会社の管理画面とお知らせを合わせます。

レンタルサーバーの利用者も対策が必要ですか

必要です。利用者が手を入れる範囲は、会社によって違います。お知らせを読み、サイトヘルスの版が修正版未満なら、会社か制作会社に「いつ上がるか」を聞く段階です。自動で上がった、と思い込むのは早いです。

ホームページの管理者がいない場合は、どうすればいいですか

パスワードの連打は、ロックされるだけでPHPは古いままです。先に残るのは、ドメイン名、サーバー会社、ドメイン管理会社、最後に触った人です。契約者の確認ができないと、中の更新は始まりません。整理からの相談は、お問い合わせで受けています。

WordPressを静的サイトに変更できますか

できるサイトと、やめた方がよいサイトがあります。会員や予約や、頻繁な記事更新があるなら、WordPressを保守する方が素直なことが多いです。お知らせ程度なら、静的への移行が候補です。元のPHPを残したまま書き出すだけでは、今回の対象は残ります。

静的サイトでもSEOは維持できますか

URL、タイトル、本文、案内文を保てば、維持できることが多いです。順位の保証はしません。移行のときにアドレスを変えるなら、旧アドレスからの引き継ぎが要ります。速さだけを上げても、中身が薄ければ評価は別に動きます。

Webサイトのセキュリティ診断では何を調べますか

外からは、HTTPS、証明書、明らかな古い画面、残っている設置ファイルです。中は、PHPの版、プラグイン、管理者、バックアップ、ログです。WEBCRAFTSは、この記事の時点では診断の定価を出していません。見る範囲を先に決めて、見積は個別です。

ホームページの保守を外部に委託できますか

できます。委託すると、更新の担当が空欄でなくなる、というのが本体です。何を毎月やるかを書かない契約は、安いだけで中身が見えません。バックアップ、PHPと本体とプラグイン、フォームの到達、この三つが最低です。

今回の脆弱性で、実際に被害は出ていますか

CISAは、10月21日の公表時点では悪用を観測していない、と書いています。CERT-EUは、実証コードが流通し始めた、と書いています。観測、実証コード、侵害の確認は別です。日本での被害確認は、原稿をまとめている10月22日の時点では未確認です。未確認は、急がなくてよい、という意味ではありません。

今後、どのような情報に注意すべきですか

PHP公式の修正版、自分のサーバー会社の「対応済み」、CISAなどが出す「悪用を観測した」という更新、です。8.2は2026年12月31日でセキュリティ修正が終わる、と公式が書いています。そこも、今年中の会話に入ります。

参照した公開情報

確認日は2026年10月22日です。

未確認のまま残しているもの。NVDの個別ページのスコア内訳、JPCERT/CCとJVNのこの2件の個別掲載、国内レンタルサーバー各社の対応完了、10月22日以降の悪用観測、WordPress.org自身の声明、です。掲載を見つけられなかったことを、「存在しない」とは書きません。

対象の限界。この記事は、自社サーバーの侵入調査の手順書ではありません。個別のサイトが侵害されたかどうかは、ログと権限がないと判断できません。

沖縄ホームページ制作工房WEBCRAFTS
沖縄県宜野湾市伊佐2-20-15 伊佐ビル2F
お問い合わせ・無料相談
 プロフィール（鈴木孝昌）