女性ニュースで「PHPの重大な脆弱性でサーバー乗っ取り」と見ました。自社のホームページも危ないのでしょうか？
編集長:カナメWordPressを使っているならPHPも動いているため関係があります！まずはサーバー会社の対応状況を確認し、自社作業の要否を切り分けるのが鉄則ですよ。
企業のWeb担当者にとって、突然のセキュリティ報道は「自社サイトへの影響範囲」「自分が何をすべきか」「上司へどう説明するか」という焦りを伴うものです。今回の脆弱性はWordPressのプラグインではなく、基盤となるPHP本体に存在するため、WordPress本体の更新ボタンを押すだけでは根本解決になりません。
自社サイトの影響度判定からサーバー会社の対応確認、PHP 7.4の注意点、制作会社への問い合わせ文例まで分かりやすく整理しました。
この記事でわかること
- PHP重大脆弱性「PHP2shell」の脅威度と自社WordPressへの影響
- レンタルサーバー各社（エックスサーバー・さくら等）の対応パターンの見極め方
- WordPress管理画面から30秒で自社のPHPバージョンを調べる手順
- 「PHP 7.4でも対策済み」に潜む落とし穴とPHP 8.3移行の必要性
- 制作会社・保守ベンダーへそのまま送れる「確認メール文例」と社内報告フォーマット
自社のホームページも対象？PHPの重大脆弱性「PHP2shell」の影響とWordPressとの関係
女性自社のサイトは普通の会社案内ですが、本当に攻撃されるリスクがあるのですか？
編集長:カナメWeb上に公開されている以上、企業規模に関係なく機械的なスキャン攻撃の対象になります。PHPの仕組みから冷静に整理しましょう。
セキュリティ専門機関やニュースサイトで「PHP2shell」という名称が大きく報じられ、企業のWeb担当者の間で緊張が走っています（出典: IPA 重要なセキュリティ情報）。この脆弱性がどのような性質を持ち、なぜ自社サイトに関係するのかを客観的な事実に基づいて把握しましょう。
ニュースの「PHP2shell（CVE-2026-109618／CVE-2026-109619）」とは？何が危険なのか
CVSS 9.2の最高警戒レベル！未認証の第三者による遠隔コード実行（RCE）の脅威
オープンソース言語「PHP」のコア機能に見つかった2件の重大な脆弱性が今回の問題です。共通脆弱性識別子として「CVE-2026-109618」および「CVE-2026-109619」が採番されました。共通脆弱性評価システム（CVSS v4.0）における基本値は、どちらも「9.2（Critical: 緊急）」と極めて高いスコアが付けられています。
技術的要因として、CVE-2026-109618はメモリ不足（OOM）時の例外処理不備により内部データが破損する不具合です。一方のCVE-2026-109619は、リクエスト異常終了時に解放済みメモリを不正参照する欠陥となります。
これらが悪用された場合、管理者ログインの権限を持たない外部の攻撃者が、ネットワーク経由でサーバー内部に任意の命令を実行させる「リモートコード実行（RCE）」へ発展するリスクを孕んでいます。
| 項目 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| 通称 | PHP2shell（メモリ管理関連） | PHP2shell（解放後メモリ参照） |
| 深刻度 | CVSS v4.0: 9.2（Critical） | CVSS v4.0: 9.2（Critical） |
| 原因 | メモリ不足時の内部状態不整合 | リクエスト異常終了時のメモリ不正参照 |
| 被害リスク | 未認証の第三者による遠隔コード実行 | サーバー制御権奪取や情報漏洩の懸念 |
| 公式修正版 | PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 | PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 |
「WordPressを使っている＝PHPを使っている」自社サイトが影響を受ける仕組み
国内サイトの8割超を占めるWordPressはPHPスクリプトで駆動している
自社でプログラミング開発を発注した覚えがなくても、Webサイトが「WordPress」で構築されている場合は例外なくPHP上で動作しています。
WordPressは、PHPプログラムがサーバー上で実行され、データベースから記事や画像を取得してHTMLを生成する仕組みです。そのため、WordPress本体やプラグインを最新に保っていても、土台のPHP自体に脆弱性があれば侵入を許してしまうリスクが生じます。
一方で、動的プログラムを使わずHTMLと画像だけで配置された静的サイトであれば、PHPを経由しないため今回の直接的な影響は受けません。自社サイトの構築手法を確認することが初期対応の要となります。
| 構築手法 | PHP利用有無 | 今回の脆弱性の影響 | 主な確認事項と対応方針 |
|---|---|---|---|
| WordPressサイト | 必須（100%） | 直接影響を受ける（要対策） | サーバー会社の修正対応およびバージョン確認が必須 |
| 他CMS（MT等） | 構成による | PHP利用構成の場合は影響有 | 動的配信にPHPを用いているか制作会社へ確認 |
| 静的HTMLサイト | なし | 原則として直接影響なし | フォーム等でPHP単体利用がないか確認 |
| クラウド型（Wix等） | プラットフォーム管理 | 利用者の直接作業は不要 | 運営企業側インフラで自動防御されるため静観 |
すぐにサイトが改ざんされる？公表前の攻撃試行と現状のリスク評価
公開前の観測報道はあるがパニックは不要！冷静にサーバー対応を確認する
脆弱性が発表されたからといって、世界中の全サーバーが一瞬で自動的に侵入されるわけではありません。過度に焦る必要はないと言えます。
開発元のThe PHP Foundationは、当初日本時間の2026年10月21日23時に修正パッチを公開する予定でした。しかし、技術情報が事前にインターネット上で拡散したため、予定を前倒しして緊急公開する事態となりました。
また、Amazonのセキュリティ調査部門によると、公式発表前の10月17日時点で、おとりサーバーに対して今回の脆弱性を探る予備的な攻撃試行が観測されていたと報じられています。早期に検証を試みた形跡はありますが、一般企業サイトで実被害が多発している状況とは区別して捉える必要があります。
| 日時（日本時間） | 発生した事象 | セキュリティ上の評価 | 担当者が取るべき姿勢 |
|---|---|---|---|
| 2026年10月17日 | Amazonハニーポットで予備試行観測 | 一部攻撃者による事前探索の兆候 | 報道を冷静に注視し事前情報を整理 |
| 2026年10月20日 | SNS等でCVE情報が流出 | 協調的情報公開前のリーク発生 | 開発元が緊急対応フェーズへ突入 |
| 2026年10月21日 | PHP公式が修正版を緊急公開 | 正規パッチ（PHP 8.2〜8.5）提供 | サーバー各社のパッチ状況確認開始 |
| 2026年10月22日〜 | 主要事業者が順次対策完了 | レンタルサーバー各社で防御完了 | 自社サイトの稼働状態とバージョン確認 |
レンタルサーバー別対応状況と自社サイトのPHPバージョン確認・切り替えリスク
女性レンタルサーバーを使っていますが、自分たちでサーバーにパッチを当てる必要がありますか？
編集長:カナメ一般的な共有レンタルサーバーであれば、事業者側が自動でパッチを適用してくれます。ただし自社作業が必要なケースもありますよ。
企業のホームページの多くは共有型レンタルサーバー上で運用されています。こうした環境における今回の脆弱性対応は、利用者がコマンドを叩いて修正プログラムを導入する作業とは異なります。
サーバー会社が直してくれる？主要レンタルサーバー各社の対応パターン
共有サーバーは事業者がインフラ側でパッチ適用！自社作業の要否を見極める
レンタルサーバーを利用している場合、PHPのプログラム本体はホスティング事業者の管理領域に存在します。国内の主要レンタルサーバー事業者は2026年10月21日から22日にかけて、緊急メンテナンスやセキュリティパッチ適用を迅速に実施しました。
ここで担当者が把握すべきは、「事業者側で自動修正が完了したケース」と、「修正版が用意され利用者が切り替えるケース」の2種類がある点です。
例えばバリューサーバーでは、2026年10月22日にメンテナンスを実施し、提供中のPHP環境に対して今回の脆弱性を防ぐ修正を適用完了したと発表しました。該当環境の契約者は自らバージョン変更を行わなくても保護される状態になっています。契約先の公式告知を必ず確認しましょう。
| サーバー契約形態 | 事業者側の対応範囲 | 利用者側のアクション | 主な事業者例 |
|---|---|---|---|
| 共有レンタルサーバー | インフラ全体への緊急パッチ適用 | 公式告知の確認（自動防御が基本） | エックスサーバー、さくら等 |
| マネージドクラウド | OS・ミドルウェア保守 | 適用スケジュールの確認 | 各社マネージド専用サーバー |
| VPS・自社クラウド | インフラ提供のみ（自社管理） | 自社によるパッケージ更新 | AWS EC2、さくらのVPS等 |
| 制作会社・保守一任 | 保守契約に基づく巡回対応 | 保守担当者への完了確認 | Web制作会社、外部保守代行 |
WordPress管理画面から30秒で確認！自社PHPバージョンの調査手順
「ツール」→「サイトヘルス」で自社サイトの稼働バージョンを一発確認
自社サイトがどのバージョンのPHPで動作しているかは、専門ツールを使わなくてもWordPress管理画面から簡単に調べることができます。以下の4ステップで確認を行いましょう。
- WordPress管理画面へのログイン
- 左メニュー「ツール」＞「サイトヘルス」の展開
- 「情報」タブ内「サーバー」項目のクリック
- 「PHP バージョン」欄に記載された数値（例: 8.3.12等）の確認
なお、画面上に「7.4.33」と表示されていても、サーバー会社が独自パッチを適用している場合、数値自体は変わらないケースがあります。数字だけを見て未対応と決めつけず、サーバー会社の告知と照合することが大切です。
| 確認ステップ | 操作項目 | 確認すべき項目名 | 判定基準の目安 |
|---|---|---|---|
| ステップ1 | 左メニュー | ツール ＞ サイトヘルス | サイト健全性画面を開く |
| ステップ2 | 上部タブ | 情報タブ | システム環境情報を表示 |
| ステップ3 | リスト展開 | 「サーバー」項目 | Webサーバー情報を確認 |
| ステップ4 | 数値メモ | PHP バージョン | 8.3.x以上（推奨） / 7.4.x（要確認） |
| ステップ5 | 照合 | サーバー会社告知との照合 | 独自パッチ適用済み環境か判定 |
「PHP 7.4のままでも対策済み」の落とし穴とサイト破損を防ぐ移行手順
サーバー会社の独自パッチで目先は防げても、公式サポート終了のリスクは残る
「サーバー会社がPHP 7.4も対策完了と発表しているから、このままで大丈夫か」という疑問を抱く担当者の方は少なくありません。
結論として、今回の緊急防護としては安全ですが、今後もPHP 7.4を使い続けるのはセキュリティ上非常にリスクが高いと言えます。PHP 7.4は公式サポートが2022年に完全終了（EOL）しているためです。
今後の未知の脆弱性リスクとバージョン更新の注意点
- 新たな脆弱性が発見されてもPHP公式から修正版は出ません。
- 広く使われているPHP 8.2も2026年12月31日に公式サポートが終了します。
- 更新時の画面真っ白（500エラー）を防ぐため、事前の全データバックアップが不可欠です。
バックアップ3-2-1ルール（3つのコピー、2種類のメディア、1つのオフサイト保管）に基づき、「All-in-One WP Migration」等で外部退避を行った上で、PHP 8.3以上へ計画的に移行することが推奨されます。
| PHP系列 | 公式サポート状況 | 今回の脆弱性への対応 | 今後の維持リスクと移行手順 |
|---|---|---|---|
| PHP 7.4以前 | 完全終了（EOL） | 公式パッチなし（サーバー独自修正） | 極めて危険（PHP 8.3へ計画移行を推奨） |
| PHP 8.2 | セキュリティサポート中 | 公式修正版（8.2.35）提供 | 注意（2026年末にサポート終了予定） |
| PHP 8.3 / 8.4 | 通常サポート中（推奨） | 公式修正版（8.3.36 / 8.4.27）提供 | 安全（WordPress推奨環境・動作テスト実施） |
制作会社・保守会社への確認文例と社内・上司へのセキュリティ報告テンプレート
女性サイト管理を制作会社に任せています。何をどう伝えれば失礼なく正確に確認できますか？
編集長:カナメ「PHPのバージョンを教えて」だけでは不十分です。今回のCVE対策の完了と、自社作業の有無を明確に尋ねるテンプレートを使いましょう。
多くの企業では、ホームページの構築や保守を外部のWeb制作会社やITベンダーに委託しています。社内に技術者がいない場合、委託先に対して的確な確認を行うことが実務上の重要な役割です。
そのままコピペで使える！制作会社・保守ベンダーへの状況確認メール文例
「脆弱性への対応完了」「自社作業の有無」「今後のバージョン更新」の3点を網羅する
制作会社へ問い合わせる際、曖昧に尋ねると認識の齟齬が生じる恐れがあります。
脆弱性番号（CVE-2026-109618／CVE-2026-109619）を明記し、自社サイトへの影響、サーバー側の対応状況、そして今後必要となる作業費用やスケジュールの有無までを過不足なく確認できるように構成しました。
制作会社向け確認メールの構成項目
- 件名：【至急確認のお願い】PHPの重大な脆弱性（CVE-2026-109618/19）に関する当社サイトの対応状況について
- 確認点1：当社Webサイトのサーバー環境において、本脆弱性への対策（パッチ適用または修正済みバージョンへの更新）は完了しているか。
- 確認点2：本脆弱性への対応に伴い、当社側で承認や設定変更などの実務作業が必要となるか。
- 確認点3：現在稼働中のPHPバージョンについて、サポート終了（EOL）に伴う今後のアップデート計画や改修が必要となる見込みがあるか。
| 問い合わせ項目 | 制作会社に確認すべき具体的な意図 | 回答を受けた後の担当者のアクション |
|---|---|---|
| ① パッチ適用状況 | 今回の緊急CVEに対してすでに防御措置が取られているか | 「対応済み」であれば直近の侵入リスクは解消と判断 |
| ② 自社作業の要否 | 追加費用が発生する作業や自社の意思決定が必要か | 費用発生時は社内稟議の準備、不要なら完了確認 |
| ③ 今後の更新計画 | PHP 7.4や8.2などのEOLに伴う将来の改修計画の有無 | 見積もりや改修スケジュールの策定を年内目標に設定 |
「被害がないこと」をどう確認する？不審なファイル・改ざんの簡易トリアージ
パッチ適用だけでなく「すでに侵入されていないか」の簡易点検を実施する
修正パッチを当てたからといって、過去の安全が完全に保証されるわけではありません。万が一、パッチ適用前に侵入を試みられていた場合、バックドアとなる不正ファイルが残されている懸念があります。
Web担当者自身が数分で実施できる初期点検として、以下の4項目を重点的に点検することが有効です。
- 管理者ユーザー一覧：管理画面の「ユーザー」を開き、見知らぬ管理者アカウントが勝手に追加されていないか確認
- ファイル更新日時：サーバー上で「index.php」「wp-config.php」等の更新日時が意図せず直近になっていないか調査
- Google検索表示：ブラウザで「site:自社ドメイン」と検索し、海外通販等の不審なページが表示されないか確認
- フォーム送信挙動：お問い合わせフォームから機械的な不正コードの送信が急増していないか点検
| トリアージ項目 | 調査場所・ツール | 正常な状態の目安 | 異常兆候（侵害の疑い） |
|---|---|---|---|
| 管理者アカウント | 管理画面「ユーザー」 | 社員・委託先のみ | 見知らぬメールアドレスの管理者登録 |
| 重要ファイル更新日時 | ファイルマネージャー | リリース当時の日時 | 意図しない直近数日以内の更新日時 |
| Google検索結果 | 「site:自社URL」検索 | 自社公開ページのみ | 海外通販や怪しい日本語ページが表示 |
| 送信フォーム挙動 | お問い合わせ受信箱 | 通常の顧客連絡のみ | 機械的な不審プログラムコードの送信 |
経営陣・上司へ「対策完了」を報告する社内向け報告書の書き方
「現状のリスク」「実施した対策」「今後の課題」をA4一枚で端的に報告する
上司から「うちのサイトは大丈夫か？」と問われた際、専門用語ばかりを並べると不安を与えてしまいがちです。ビジネスの報告としては、「影響度」「対策内容」「安全宣言」「今後の課題」を明確に整理して伝えるのが賢明です。
社内向けの報告書やメール報告として活用できる標準フォーマットを以下に整理しました。
社内報告書の記載骨子
- 結論サマリー：ホームページはWordPress（PHP環境）を利用しているため潜在的影響を受ける構成でしたが、サーバー会社の緊急パッチ適用を確認し、現時点で不正侵入等の実被害は確認されておりません。
- 実施済み対策：サーバーのパッチ適用完了の確認、全データの外部バックアップ取得、管理者アカウントおよび重要ファイルの更新日時点検の完了。
- 中長期対応：緊急対策により目先の安全性は確保されましたが、将来の公式サポート終了（EOL）を見据え、PHP 8.3以降への計画的更新を推奨いたします。
| 報告書の記載ブロック | 経営陣・上司の関心事 | 記載ポイントとトーン＆マナー |
|---|---|---|
| 結論（サマリー） | ホームページは今、安全なのか？ | 「現時点で実被害なし・防御完了」を冒頭で明言 |
| 実施済み対策 | 誰が何をやって解決したのか？ | サーバー会社のパッチ確認と社内点検の事実を記述 |
| 現状のリスク評価 | すぐに問題が起きる可能性はあるか？ | 直近の攻撃経路は遮断された旨を冷静に報告 |
| 中長期の改善策 | 今後追加で費用や作業が必要か？ | PHP 8.3移行の必要性を計画的に提示（先手を打つ） |
まとめ：PHP脆弱性対応は「緊急パッチ確認」と「計画的バージョン更新」の2段構えで進めよう
目先の火消しで終わらせず、サイト全体のセキュリティ耐性を底上げする
今回のPHP脆弱性「PHP2shell」騒動は、企業サイトが常にインターネット上の脅威に晒されている事実を改めて示しました。
Web担当者が取るべき行動は、まず「レンタルサーバー会社の対応完了を確認して目先の侵入を防ぐ（緊急対応）」こと、そして次に「古いPHP環境から脱却し、最新のPHP 8.3環境へ計画的に移行する（恒久対策）」ことの2段構えです。
正しい知識と手順を持って一次情報と向き合えば、過度に恐れる必要はありません。本記事のチェックリストと問い合わせ文例を活用し、自社サイトの安全性を強固に維持していきましょう。
| フェーズ | アクション項目 | 実施目的とゴール | 連携相手 |
|---|---|---|---|
| 【緊急】即日〜3日 | サーバー告知確認＆制作会社問い合わせ | 目先のRCE脆弱性に対する防御完了の確認 | レンタルサーバー会社、制作会社 |
| 【緊急】即日〜3日 | サイトヘルス確認＆バックアップ取得 | 自社バージョンの把握と復旧手段確保 | 社内担当者、管理画面 |
| 【短期】1〜2週 | 社内報告書の提出＆初期トリアージ点検 | 経営陣への安全報告と痕跡確認 | 直属上司、セキュリティ責任者 |
| 【中長期】1〜3ヶ月 | PHP 8.3移行テストと本番バージョンアップ | サポート切れ（EOL）リスクの根本解消 | 制作会社、情シス、外部専門家 |
よくある質問
Q1: WordPress本体やプラグインを最新に更新していれば、今回のPHP脆弱性は防げますか？
いいえ、防げません。今回の脆弱性はWordPressのプログラムそのものではなく、WordPressを動かしている土台である「PHP言語の処理系本体」に存在します。家で例えるなら、建物のドアや鍵を頑丈にしても、基礎の土台に穴が開いている状態です。WordPressの更新と並行して、サーバー上のPHPに対するパッチ適用やバージョン更新を確認する必要があります。
Q2: 静的なHTMLサイトやペライチ等で作ったLPも今回の脆弱性の影響を受けますか？
サーバー上でPHPが実行されていない純粋なHTML・CSSファイルのみで構成された静的サイトや、クラウド側がインフラを完全管理しているノーコードツール（ペライチ、Shopify、Wix等）で作成されたLPは、今回のPHP脆弱性の直接的な影響を受けません。ただし、静的サイトであっても「お問い合わせフォーム」の送信処理部分だけPHPプログラムを別途動かしているケースがあるため、フォームプログラムの有無を制作会社に確認することをお勧めします。
Q3: レンタルサーバーのお知らせに「対応完了」と書いてあれば、自分は何もしなくて良いですか？
目先の緊急セキュリティ対策としては、サーバー側で防御が完了しているため安全です。ただし、自社サイトが利用しているPHPが「PHP 7.4」などの公式サポート終了（EOL）バージョンである場合、今回の穴は塞がれても、将来見つかる新たな脆弱性に対しては無防備な状態が続きます。また、PHPの切り替えが利用者の手動設定に委ねられているサーバープランもあるため、アナウンスをよく読み、「自社で切り替え作業が必要かどうか」を必ず確認してください。
Q4: 社内にエンジニアや情シスがいません。Web担当者一人で対応できない場合はどうすればいいですか？
無理に自力でサーバー設定やPHPバージョンを変更しようとすると、画面が真っ白になるなどのサイト障害を引き起こす恐れがあります。まずは本記事で紹介した「制作会社向け問い合わせメール文例」をそのままサイトの制作・保守会社に送信し、プロの判断を仰ぐのが賢明な選択肢です。保守契約を結んでいない場合や制作会社と連絡が取れない場合は、単発のWordPress保守サービスやIT代行サービスに相談して安全な移行を依頼するのが安心できる手段となります。
本記事に掲載されている情報は、2026年10月時点の公的機関（IPA、JPCERT/CC、The PHP Foundation等）および各ホスティング事業者の公式発表に基づき、一般的なセキュリティ運用の知見を整理したものです。Webサーバーの仕様、WordPressの構成、導入されているプラグインやテーマの状況によって最適な対応手順は異なります。PHPのバージョン変更や設定変更を行う際は、必ず事前にバックアップを取得した上で、ご契約中のサーバー会社またはWebサイト保守管理会社にご相談ください。本記事の情報を基に生じた直接的・間接的な損害について、当サイトは一切の責任を負いかねます。
コメント