2026年10月21日夜、サーバー側の言語が判明しているWebサイトの約7割で使われているプログラミング言語「PHP」に、深刻度が最も高い「緊急(Critical)」と評価された脆弱性が2件見つかり、修正版が緊急公開されました。国内でもネット通販、保育、動画・イラスト投稿などの大手サービスが攻撃への備えとして予防的に一時停止やメンテナンスに入り、IPA(情報処理推進機構)や首相もXで注意を呼びかけています(Impress Watch)。
「サーバー会社が直してくれているのか、自分で何かすべきなのか分からない」
今回の問題は、サイトのプログラム(コード)の不備ではなく、サイトを動かす土台である「PHP」そのものの欠陥です。そのため、WordPressなどのアプリを最新にしても防げず、PHP公式の修正版、またはOS・サーバー事業者が提供する修正済みパッケージの適用が必要です。確認すべき要点は次の3つです。
- いま使っているPHPのバージョンと、実際に動いているPHPはどれか
- サーバー会社や保守担当が、修正を適用済みか
- 公式サポートが終了した古いPHP(8.1以前)で動かし続けていないか
この記事では、2026年10月22日時点の公開情報をもとに、事実関係、環境別の確認ポイント、更新時の注意点、自力での対応が難しい場合の進め方を整理します。状況は日々変わるため、最新情報はIPAやPHP公式、サーバー会社の案内もご確認ください。
1. 何が起きたのか:「PHP2Shell」の概要
PHPは、Webサイトの裏側でフォームの処理やデータベースとのやり取りなど、利用者の操作に応じた処理を担うプログラミング言語です。Web技術の調査サービスW3Techsによると、2026年10月22日時点で、サーバー側の言語が判明しているサイトの69.3%がPHPを使っており(W3Techs)、WordPressもPHPで動いています。
PHPの開発チームは10月20日に重大なセキュリティ更新を予告し、21日(日本時間の夜)に修正版を公開しました。公表された脆弱性は次の2件で、通称「PHP2Shell」と呼ばれています。
- CVE-2026-109618:メモリ不足(OOM)のエラー処理の際にデータが中途半端な状態で残り、後続の処理で不正なコード実行につながる問題
- CVE-2026-109619:解放済みのメモリを指す情報がPHP内部に残り続けることで起きる問題
どちらも、脆弱性の深刻度を示す国際指標CVSS v4.0で9.2(Critical)と評価されています。ログインなしで外部から任意のコードを実行されるおそれがあり、米CISAは、Webリクエストを処理するPHP環境全般が対象だとして、直ちに更新するよう促しています。
サーバーを乗っ取られると、サイトの改ざんやウイルス配布への悪用、他システムへの攻撃の踏み台にされるといった被害につながり得ます。
動かし方別に見ると、PHP-FPM、Apacheのモジュール版(mod_php)、php-cgiなどが対象です。なかでもmod_phpは、アプリケーションのコードが動く前の段階で、認証なしのリクエストにより攻撃を引き起こせることが実証されているとして、最も警戒が必要とされています(ITmedia NEWS)。一方、PHP-FPMも更新が必要で、条件次第でコード実行が実証されたと報告されています(Qualys)。
攻撃の状況は、分けて見る必要があります。PoC(概念実証コード)の出回りは報告されています(CERT-EU)。CloudflareのCEOは10月22日、同社のネットワークで悪用を試みる通信が、公表前の10時間の数千件から、公表後は数百万件規模に増えたとXで報告しました(ASCII.jp)。IPAは10月21日の事前告知の時点では、悪用した攻撃を確認していないとしていました(IPA)。ただし、攻撃の試みの増加と、実際に侵入されたことは別です。
修正版は次のとおりです。
| PHPの系統 | 修正版 | 補足 |
|---|---|---|
| 8.5/8.4/8.3/8.2系 | 8.5.12/8.4.27/8.3.36/8.2.35 | 各系列の公式の修正版 |
| 8.1以前(7.4・8.0を含む) | 公式の通常サポート対象外 | 7.4・8.0・8.1向けには例外的に最小限の修正ソースが公開されている。OSやサーバー事業者が修正を提供する場合もあるが、すべての旧バージョンに提供されるとは限らない |
2. 自社サイトは影響を受ける?環境別の確認ポイント
PHPで動いているサイトは、まず確認が必要です。そのうえで、修正を行う主体は「サイトをどこに置いているか」によって変わります。
| サイトの置き場所 | 修正を行う主体 | まず確認すること |
|---|---|---|
| 一般的なレンタルサーバー | サーバー会社がPHP環境を修正。利用者は適用状況と設定を確認 | 契約中のサーバー会社の公式案内、管理画面で選択中のPHPバージョン、8.1以前を選んでいないか |
| VPS・クラウド・コンテナ | 管理する側(自社または委託先) | OSのパッケージ更新(コンテナは修正済みイメージの再ビルドと再配備)、サイトが実際に使っているPHP(コマンドラインで見えるPHPと異なる場合がある)、再起動の有無 |
| 自社・社内サーバー | 利用者(情シス・保守会社) | 同上に加え、アクセスログと不審なファイルの有無 |
| 保守会社・管理サービスに委託 | 委託先 | 委託先に適用状況と、実施日時の報告を依頼する |
| 製品・機器の内部でPHPが動いている | メーカー | メーカーの案内。機器内でPHPが使われていないかも棚卸しの対象 |
PHPのバージョンは、サーバー会社の管理画面(コントロールパネル)で確認できます。WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でも確認できます。ただし、表示されるバージョンだけでは、対策済みかどうかを判断できない場合があります。
大手レンタルサーバー各社は、22日にかけて修正の適用や案内を順次出しています。ただし、サーバー会社ごと、PHPのバージョンごとに対応状況や案内内容が異なり、古いバージョンは暫定的な対応にとどまる例もあります。必ず、ご契約中のサーバー会社の公式案内で、対象と対応日時を確認してください。
「どの環境に当てはまるのか、そもそも分からない」という場合は、対応の要否の確認から相談できます。
3. 「サーバー会社が直したから大丈夫」とは言い切れない3つのケース
レンタルサーバーの多くは、サーバー会社側で修正が進んでいます。それでも、次の3つのケースでは追加の確認が必要です。
ケース1:サポートが終了した古いPHP(8.1以前)で動いている
PHPプロジェクトが通常の修正版を出したのは8.2〜8.5系だけです。8.1以前は、例外的な修正ソースやOS・サーバー事業者の対応に頼る状態になります。サーバー会社の対応も「暫定的な修正」とされる場合があり、本筋は、サポート対象の新しいバージョンへの移行です。
ここで注意したいのが、バージョン番号の見方です。OSやサーバー事業者が修正を取り込んだパッケージでは、表示上のバージョン番号が古いままでも、修正済みであることがあります。番号だけで安全・危険を判断せず、事業者の案内とあわせて確認してください。
ケース2:VPS・クラウド・社内サーバーを自分で運用している
VPSやクラウドを自分たちで管理している場合、PHPの更新、再起動、適用結果の確認は、自社または委託先の管理範囲です。マネージドサービスでは、提供事業者との責任分担を確認してください。設定変更による「緩和策」や、WAFなどの遮断ルールも、修正版を適用するまでの時間稼ぎとしては有効ですが、完全な防御にはなりません。
すぐに更新できない場合は、首相やCERT-EUなども、一時的な停止やアクセス制限を選択肢に挙げています。
ケース3:修正が公開される前に侵入されていた可能性がある
更新は「これからの攻撃」を防ぐ手段で、すでに侵入されていた場合の被害までは消してくれません。更新後は、アクセスログやエラーログ、見覚えのないファイル、身に覚えのない管理ユーザーがないかを確認します。ただし、この簡易確認だけでは侵入の有無を断定できません。
不審な兆候が見つかった場合は、必要に応じて外部からのアクセスを制限して被害の拡大を防いだうえで、ログやファイルを保全し、専門のセキュリティ担当に相談してください。削除や再更新を先に進めると、調査に必要な痕跡が失われるおそれがあります。
4. PHPアップデートの基本手順と注意点
一口に「PHPの更新」といっても、作業は2種類に分かれます。8.3.35から8.3.36のように、同じ系列の中で修正版へ上げる作業は、一般に互換性への影響が小さいとされます。一方、8.1以前から8.3などの新しい系列へ移る場合は、古いPHPを前提に作られたテーマ・プラグイン・自作のフォームなどがエラーになり、改修が必要になることがあります。
なお、一般的な共有レンタルサーバーでは、PHPそのもののパッチ適用はサーバー会社が行います。利用者側の作業は、選択中のバージョンの確認と、更新後の動作確認が中心です。自分たちで更新する場合の基本手順は次のとおりです。これは侵入の兆候がない場合の手順で、侵入が疑われる場合は、ケース3のとおり、証拠の保全や専門担当者への相談を優先してください。
- バックアップ:サイトのファイル一式とデータベースを取得し、保存先と復元手順も確認して、戻せる状態にする。侵入が疑われる場合は、バックアップ自体が安全とは限らない点にも注意する
- 検証環境での確認:ECサイトや会員サイトなど止められないサイトは、可能なら検証環境で先に動作を確認する。ただし、確認に時間をかけすぎて、脆弱な状態を長引かせない
- PHPの更新と適用確認:管理画面での変更やOSパッケージの更新など、環境に合った方法で修正版を適用し、必要なサービスの再起動やコンテナの再展開を行う。サイトが実際に修正済みのPHPで動いていることまで確認する
- 動作確認:トップページ、下層ページ、お問い合わせフォームの送信結果とメールの到達、会員ログイン、決済、外部サービス連携、定期実行の処理などを確認し、PHPのエラーログも点検する
- 不具合の切り分け:エラーが出たら、テーマ・プラグイン・独自コードの互換性を確認する。脆弱なPHPへの切り戻しは原則避け、復旧が難しい場合は、一時的なアクセス制限なども検討する
- ログとファイルの確認:更新の前後で、不審な動きがないかを確認する(ケース3のとおり、簡易確認だけでは断定できない点に注意)
作業をほかの会社に任せる場合は、サーバーの管理画面やFTP・SSHのログイン情報が必要になることがあります。契約や守秘義務を結んだ相手にだけ渡し、可能であれば作業用の専用アカウントを発行して、完了後に削除するかパスワードを変更してください。
5. 今回だけの話ではない。この機会に見直したい保守体制
今回のような「土台のソフトウェア」の脆弱性は、PHPに限った話ではありません。2026年7月にはWordPress本体でも、リモートコード実行につながる重大な脆弱性が修正され、公式が7.0.2などを公開して強制的な自動更新を有効にしました(WordPress公式)。WordPress本体とPHPは、別々に更新管理が必要です。
重大な脆弱性は、これからも起こり得ます。そのたびに慌てなくて済むよう、この機会に次の点を点検しておくことをおすすめします。
- PHPのバージョン:公式サポート対象のバージョンで動いているか。今回の修正版(8.2.35)に上げても、PHP 8.2の公式セキュリティサポートは2026年12月末で終了する予定のため、中長期的な移行先も確認しておく(PHP公式のサポート期限)
- CMS・プラグイン・テーマ:更新が止まっていないか、更新が止まった部品を使い続けていないか
- バックアップ:定期的に取得できているか、実際に復元できるか
- 担当者と連絡経路:サーバーや管理画面のログイン情報、契約名義、障害時の連絡先を、誰が把握しているか
- サイトの棚卸し:使っていない古いサイトやサブドメイン、キャンペーンページが残っていないか。IPAも、今回の件で対象システムの棚卸しを呼びかけています
- 保守の契約範囲:納品後の更新作業が、誰の責任で、いつ行われる契約になっているか
6. 対応を依頼する場合の流れ|コーディングコネクションにできること
コーディングコネクションは、HTML・WordPressのコーディングを中心に、他社が制作したサイトの修正・改修にも対応しています。今回のPHPの件についても、まずは「対応が必要かどうか」と「どこまでが誰の担当か」の確認からご相談を承ります。
ご依頼の流れ
- ご相談:フォーム・お電話・Chatworkから、サイトのURLと、分かる範囲のサーバー情報をお知らせください
- 現状の確認:サーバー環境とPHPのバージョン、サーバー会社や事業者による修正の適用状況などを確認し、今回の脆弱性について対策が必要な状態かを調べます
- ご提案とお見積り:対応が必要な場合は、作業内容と費用をお見積りします
- 作業:バックアップの取得、PHPの利用状況の調査、テーマ・プラグインの互換性確認、PHP変更に伴うサイト側の改修と動作確認などを、環境と権限に応じて行います。サーバーOSの更新や専門的な侵入調査など、弊社で対応できない作業は、サーバー管理者や専門事業者との連携をご案内します
調査の結果、今回の脆弱性について対策済みと確認できた場合は、その結果をご報告します。なお、この調査は今回の脆弱性に関する確認で、サイト全体の安全性を保証するものではありません。また、侵入の疑いがある場合の専門的な調査は、別途のご相談・お見積りとなることがあります。
過去に弊社でサイト制作をご依頼いただいたお客様には、確認可能な範囲でPHPの利用状況などを調べる簡易調査を、無償でご案内しています。サーバーへのログインを伴う調査が必要な場合は、事前に作業範囲と費用をご案内します。ほかの会社が制作したサイトについても、まずは無料のお見積り・ご相談から承ります。費用は環境によって異なるため、確認結果をもとにお見積りします。
制作会社・代理店の皆さまへ
クライアントサイトの確認と更新が一度に重なり、社内の工数が足りないという場合は、貴社名義でのご対応も可能です。クライアントとの窓口は貴社に一元管理いただき、弊社は裏方の技術支援に徹します。貴社からご指示いただいた作業を行い、完了後に貴社へご報告します。事前に作業範囲、サーバーの管理権限、緊急時の連絡・判断方法を確認し、役割分担を明確にしてから進めます。
継続的な保守を任せたい場合
今回のような更新対応を、今後も継続的に任せたい場合は「WordPress保守プラン」(月額30,000円〜・税別、初期費用0円、最低契約期間3ヶ月)もご用意しています。他社が制作したサイトにも対応でき、貴社名義でのご提供もご相談いただけます。保守プランに含まれるPHP更新の範囲は、サーバー環境やサイトの構成によって異なります。サーバーOSの管理、専門的な侵害調査、PHPの新しい系列への移行に伴うテーマ・プラグインの改修、緊急対応などは、別途お見積りとなる場合があります。詳しくは専用ページをご覧ください。
よくあるご質問
サーバー会社が「対応済み」と案内しています。それでも依頼は必要ですか?
サーバー会社が修正を適用した範囲では、追加の作業が不要な場合も多くあります。ただし、PHPが8.1以前になっていないか、自分で運用しているサーバーが含まれていないか、侵入の痕跡がないかは、別に確認が必要です。確認の結果、追加の作業は不要とお伝えする場合もあります。
個人情報を扱わない小さなサイトでも、対応は必要ですか?
影響を受ける環境であれば、対策が必要です。個人情報がなくても、サーバーが乗っ取られれば、改ざんや踏み台にされるおそれがあります。
PHPの更新が必要かどうかの確認から、実際の作業まで、サイトの状況に合わせてご相談いただけます。お気軽にご連絡ください。
この記事のまとめ
- PHPに「緊急」レベルの脆弱性2件(CVE-2026-109618・109619)が見つかり、10月21日に修正版(8.5.12/8.4.27/8.3.36/8.2.35)が公開された
- レンタルサーバーはサーバー会社が対応を進めているが、8.1以前のPHP、自分で運用するサーバー、侵入済みの可能性は別途の確認が必要
- 更新前にバックアップを取り、更新後は再起動と適用の確認、動作確認まで行う。更新できない場合は、一時的なアクセス制限なども検討する
- これを機に、PHPのバージョン、更新が止まった部品、バックアップ、担当者を点検しておく
- 自力での対応が難しい場合は、対応の要否の確認からでも相談できる
参考情報
- PHP公式:Security advisory(2026年10月21日)
- W3Techs:PHP Usage Statistics
- IPA:PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619)
- IPA:【事前準備のお願い】PHPのセキュリティリリース公開予定について
- ITmedia NEWS:PHPの「緊急」レベルの脆弱性、開発元が修正バージョン公開
- CERT-EU Security Advisory 2026-018
- CISA:Critical Vulnerabilities in PHP Require Immediate Patching
- Qualys:PHP Announces Critical Security Release for Two Vulnerabilities
- ASCII.jp:PHPの脆弱性を狙う攻撃、数百万件に急増 公表からわずか2時間で数十万件、Cloudflareが報告
- Impress Watch:国内大手サービスで緊急メンテやサービス停止 PHP脆弱性で対策
コーディングコネクションのサービス詳細はこちら