2026年10月21日、PHP本体に認証不要で任意のコードを実行される重大な脆弱性「php2shell」が公開され、国内でも200を超える企業・自治体がサービスを一時停止しました。「うちのサイトはWordPressだけど、制作会社と保守契約がない」「サーバーがどこにあるのか分からない」という状態で不安になった方も多いはずです。この記事では、技術担当がいない会社でも今日中にできる確認手順と、今回の騒動から見えてきた「サイトの持ち方」の見直しポイントを整理します。
結論：WordPressサイトの持ち主が今すぐやる3つのこと
やるべきことは3つだけです。WordPress本体やプラグインの更新ではなく、その土台であるPHPのバージョンを確認して上げることが対策の中心になります。
- PHPのバージョンを確認する：WordPress管理画面の「サイトヘルス」で見られます。サーバーにログインする必要はありません。
- PHP 8.1以下ならレンタルサーバーの管理画面で8.3系以上に切り替える：修正版が出るのは8.2以降だけで、8.1以下はいくら待っても直りません。
- 8.2以上なら、レンタルサーバー会社が修正版を適用したかを公式のお知らせで確認する：共用サーバーではPHP本体の更新は事業者側が行います。
静的化やヘッドレスCMSへの移行は、今回の脆弱性対応として必須ではありません。ただし、この機会にサイトの持ち方を見直す価値はあり、後半でその判断基準を解説します。
php2shellとは：PHP本体の欠陥で、WordPressを最新にしても防げない
php2shellとは、PHP本体のメモリ管理の不具合により、外部から細工したHTTPリクエストを送るだけでサーバー上で任意のプログラムを実行されうる脆弱性の通称です。CVE番号はCVE-2026-109618とCVE-2026-109619の2件で、PHPセキュリティチームによる深刻度はCVSS v4.0で9.2（Critical）とされています。
重要なのは、欠陥がWordPressやテーマ・プラグインではなく、それらを動かしているPHPそのものにある点です。WordPress本体を最新にしていても、PHPが古ければ無関係に危険です。逆に、PHPさえ修正版にすれば、WordPress側の操作は不要です。
2026年10月22日時点で公表されている主な事実は次のとおりです。
- 攻撃にログインやパスワードは不要で、サイトが公開されていれば誰でも試せる
- 該当するコードはPHP 5.4（2012年）から存在するとされ、現在稼働するほぼ全てのPHPサーバーが対象
- 修正版はPHP 8.2.35／8.3.36／8.4.27／8.5.12の4系統のみ。8.1以下には公式の修正版が提供されない
- 修正版の公開前に詳細が流出し、攻撃コードを名乗るものが複数出回っている。複数のセキュリティ企業が攻撃の試みを観測しているが、10月22日時点で侵害を公表した国内組織はない
詳細はGMO Flatt Securityの解説やpiyologのまとめが参考になります。
WordPressサイトで今すぐ確認する手順
サーバーの知識がなくても、WordPressのログイン情報さえあれば最初の確認はできます。順番に進めてください。
手順1：サイトヘルスでPHPバージョンを見る
WordPress管理画面にログインし、「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」を開くと「PHP バージョン」が表示されます。この数字が8.2以上か、8.1以下かで、やることが分かれます。
PHPバージョン | 状態 | やること |
|---|---|---|
8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以上 | 修正済み | 対応完了。念のため管理画面のアクセス制限を確認 |
8.2〜8.5系だが上記より古い | 修正待ち | レンタルサーバー会社のお知らせで修正版の適用状況を確認 |
8.1以下（7.4、8.0、8.1など） | 修正版なし | レンタルサーバーの管理画面でPHPを8.3系以上に切り替える |
手順2：レンタルサーバーの管理画面でPHPを切り替える
エックスサーバー、さくらのレンタルサーバ、ConoHa WING、ロリポップ!などの共用レンタルサーバーには、ドメインごとにPHPのバージョンを選ぶ機能があります（エックスサーバーなら「PHP Ver.切替」）。この操作に制作会社は必要ありません。必要なのはレンタルサーバーの契約者アカウントのログイン情報だけです。
切り替え後は、トップページ・下層ページ・お問い合わせフォームの表示と動作を一通り確認してください。古いテーマやプラグインを使っていると、PHPを一気に上げたときに表示が崩れることがあります。その場合は8.2→8.3のように段階的に上げるか、崩れる原因のプラグインを特定して対処します。
手順3：すぐに切り替えられない場合の暫定策
PHP開発チームは暫定的な緩和策として、session.upload_progress.enabled=0 などの設定変更を案内しています。レンタルサーバーの「php.ini設定」から変更できます。ただし、PHP公式自身が「これで安全になるわけではない」と明言しており、実証された攻撃経路の一部を塞ぐだけです。あくまでバージョン切替までのつなぎとして扱ってください。
なぜ多くの企業がサービスを止めたのか：本質は「把握できていない」問題
今回、銀行や省庁を含む多くの組織が丸一日サービスを停止しました。技術的にはPHPを1バージョン上げれば済む話だったにもかかわらず、停止を選んだ組織が多かった理由は、「自社の環境のどこでPHPが動いているか」を即答できなかったからです。
これは中小企業のコーポレートサイトでも同じ構図です。Cataly Designでは今回の公開直後、「自社サイトは大丈夫か」という相談を複数受け、稼働環境の調査を行いました。相談の中で見えてきたのは、WordPressそのものより「サイトがどこで動いているかを誰も把握していない」状態の多さです。典型的なパターンを例として挙げます。
- 制作会社の説明と実態が食い違っている例：「クラウド上で動いているので当社では触れない」と説明されていたが、DNSとサーバーのIPを調べると、実際には別のサイトと同じ共用レンタルサーバーに同居していた。レンタルサーバーの管理画面にログインできれば、自社で対応できる状態だった。
- 契約が分散して所在が分からない例：グループ会社や事業ごとにサイトが別々のレンタルサーバー契約に分かれており、それぞれのログイン情報を誰が持っているか、社内で誰も即答できなかった。
- 役目を終えたサイトが放置されている例：数年前に作ったきり誰も更新していないWordPressサイトが、古いPHPのまま公開され続けていた。使っていないサイトほど、こうした脆弱性の入口になりやすい。
いずれも「WordPressだから危ない」のではなく、「誰も中身を把握していないサーバーが公開され続けている」ことが問題です。DNSの設定やサーバーのIPアドレスを調べれば、どの事業者のどのサーバーで動いているかは外部からでも特定できます。制作会社の説明を鵜呑みにせず、まず事実を確認することが出発点になります。
WordPressと静的サイト（Next.js＋ヘッドレスCMS）を容量・運用・保守で比較
今回の騒動を受けて「WordPressをやめて静的サイトにしたほうがよいのでは」という声が増えています。結論から言えば、更新頻度の低いコーポレートサイトであれば、容量・運用・保守のいずれの面でも静的サイトのほうが有利なことが多いです。ただし万能ではありません。
比較軸 | WordPress（レンタルサーバー） | 静的サイト（Next.js等＋ヘッドレスCMS） |
|---|---|---|
容量 | 本体・テーマ・プラグイン・DBで数百MB〜GB単位。画像は複数サイズが自動生成され増え続ける | HTML・CSS・JS・最適化済み画像のみ。同じ内容で1/10以下になることも多い |
更新作業 | 担当者が管理画面から自分で更新できる | ヘッドレスCMSを組み合わせれば同等。CMSなしの場合は制作側に依頼が必要 |
保守の対象 | PHP・WordPress本体・テーマ・プラグインの4層を更新し続ける必要がある | ホスティング側のランタイムは事業者が管理。自社で見るのは依存パッケージのみ |
今回のような脆弱性 | PHPの修正版が出たら自分で確認・更新が必要 | サーバー上でPHPが動いていないため対象外 |
保守契約なしで放置した場合 | 数年で脆弱性が蓄積し、更新時に表示崩れが起きやすい | 公開済みのサイトは影響を受けにくい。ただし再ビルド時に依存関係の更新が必要 |
他社への引き継ぎ | 対応できる制作会社・フリーランスが多い | 対応できる会社が限られ、制作元への依存度が上がる |
注意したいのは、Next.jsやNode.jsが安全な技術だというわけではない点です。Next.jsにも2025年に認証をすり抜ける脆弱性（CVE-2025-29927）があり、npmパッケージのサプライチェーン攻撃も繰り返し起きています。静的サイトが有利なのは、公開されているサーバー上で実行環境を持たないため、脆弱性が出たときに「今すぐ全員更新」という事態が自分のところに降ってこないからです。
WordPressが適するケース・静的化が適するケース
どちらを選ぶかは、更新頻度・担当者・保守体制の3点で判断できます。
静的サイト（Next.js＋ヘッドレスCMS）が向くケース
- お知らせの更新が月1回以下など、更新頻度が低いコーポレートサイト
- 社内に技術担当がおらず、制作会社との保守契約もない
- 更新するのは非エンジニアの担当者で、文章と画像の差し替えが中心
- 表示速度やセキュリティへの説明責任を取引先・顧客に対して負っている
WordPressを続けてよいケース
- ブログやコラムを週単位で更新し、投稿者が複数いる
- 予約・会員・ECなど、プラグインに依存した機能を組み込んでいる
- 制作会社と保守契約があり、PHP・本体・プラグインの更新が定期的に行われている
- 社内にWordPressを扱える人がいて、将来の乗り換え先を広く確保したい
既存のWordPressサイトから移行する場合の進め方は、ヘッドレスCMSの仕組みと従来型CMSとの違いと、サイト移行時のURL設計とリダイレクトの手順も参考にしてください。
注意点・よくある誤解
今回の件で相談を受ける中で、判断を誤りやすいポイントがいくつかありました。
- 「WordPressを最新にしたから大丈夫」は誤り：欠陥はPHP本体にあります。WordPress 7.1.3が最新でも、PHPが7.4なら危険です。
- 「管理画面のパスワードが強いから大丈夫」も誤り：今回の攻撃に認証は不要です。公開されているページにリクエストを送るだけで成立します。
- 「制作会社が対応できないからサイトを閉鎖する」は早計：PHPの切替はレンタルサーバーの管理画面で数分で終わります。必要なのは制作会社ではなく、サーバー契約のログイン情報です。
- 「静的化すれば保守ゼロ」も言い過ぎ：保守の頻度と失敗時の被害が小さくなるだけで、数年放置すればビルド環境は古くなります。
- 対応後もログは残しておく：修正前に攻撃を受けていた可能性はゼロではありません。アクセスログの保全と、不審なファイルがないかの確認は、PHP切替後に行っておくと安心です。
まとめ：まず「どこで動いているか」を把握することから
php2shellへの対応で押さえておくべき要点は次のとおりです。
- 欠陥はWordPressではなくPHP本体にある。対策はPHPを修正版（8.2.35以降の各系統）にすること
- PHPバージョンはWordPressのサイトヘルスで確認でき、8.1以下ならレンタルサーバーの管理画面で切り替える
- 多くの企業が止まった本当の理由は「自社環境を把握できていない」こと。DNSとサーバーの所在を確認し、誰がログイン情報を持つかを明確にする
- 更新頻度の低いコーポレートサイトは、容量・運用・保守の面で静的サイト＋ヘッドレスCMSが有利。ただし更新体制や機能要件によってはWordPressが適する
Cataly Designでは、現在のサイトがどの環境で動いているかの調査から、PHPの切替対応、静的サイトへの移行設計までを一貫して支援しています。「サーバーがどこにあるか分からない」という段階からでも相談できますので、サービス一覧からお気軽にお問い合わせください。WordPressのセキュリティ対策の基本やホームページの保守・運用の内容と費用相場もあわせて確認しておくと、今後の判断がしやすくなります。
