2026年10月20日、プログラミング言語「PHP」の開発チームが、深刻度の高い脆弱性(=システムの安全上の欠陥)2件を直す修正版を、日本時間10月21日(水)23時に公開すると予告しました。報道では、この2件は「CVE-2026-109618」「CVE-2026-109619」という番号で伝えられています。
PHPは、WordPressやEC-CUBE、Laravelをはじめ、多くのWebサイトや業務システムの土台として使われている言語です。
「うちのホームページはWordPress、社内システムはLaravelで作ってもらったはず。これって関係あるの?何をすればいい?」
先に結論をお伝えします。WordPressやEC-CUBE、Laravelなどで作ったシステムは、ほぼすべてPHPの上で動いているため、関係がある可能性が高いと考えて準備しておきましょう。今やるべきことは、「自社のシステムがどのバージョンのPHPで動いているか」「PHPの更新は誰が行うか」を確認し、修正版が出たらすぐ更新できるよう開発会社やサーバー会社と段取りを決めておくことです。あわせて、修正版を当てるまでの間にサイトを一時停止するか、アクセスを制限するかも、今日のうちに開発会社と決めておきましょう(追記:10月21日 18時時点)。
【追記:10月21日 23時時点】PHPの開発チームは日本時間21日22時40分ごろ、修正版(PHP 8.5.12・8.4.27・8.3.36・8.2.35)を公開しました。2件とも、ログインしていない第三者から遠隔でプログラムを実行される(RCE)脆弱性だと正式に発表されています。PHP公式は「完全な緩和策はなく、更新だけが安全な選択肢」としています。修正版にすぐ更新してください。PHP 8.1以前には公式の修正版が出ないため、更新できないシステムは一時停止も含めて開発会社と相談しましょう。
この記事では、公式発表と報道の要点を分けて整理し、PHPと代表的なフレームワークの関係、発注者が開発会社に確認したいことを、チェックリストと質問例つきで解説します(内容は2026年10月21日午後、修正版の公開前の時点の情報に基づきます)。
PHPの脆弱性2件、公式発表と報道の要点
まず、PHPの開発チームが公式に発表している内容を確認します。
📰 出典:PHP「Upcoming Critical PHP Security Release」(2026年10月20日)
| 項目 | 公式発表の内容(10月20日) |
|---|---|
| 内容 | 緊急度の高い(critical)脆弱性2件を直すセキュリティリリースを行う |
| 深刻度 | 2件とも CVSS v4.0 で 9.2 |
| 公開予定 | 2026年10月21日 14:00 UTC(日本時間 23:00) |
| 補足 | 脆弱性の詳細が公になった場合や、実際の悪用が確認された場合は、予定より早く公開することがある |
| 影響を受けるバージョン・修正版 | 修正版の公開時にあわせて発表する |
CVSS(=脆弱性の深刻さを0〜10点で表す世界共通の指標)で9.2は、最も高い「緊急」の区分に入ります。PHPの開発チームは、すべての利用者に今のうちから準備しておくよう呼びかけています。
修正版の公開(10月21日 22時40分ごろ・日本時間)
(追記:10月21日 23時時点)PHPの開発チームは、予定より少し早く修正版を公開し、脆弱性の内容を発表しました。
| 項目 | 公式発表の内容(10月21日) |
|---|---|
| 修正版 | PHP 8.5.12/8.4.27/8.3.36/8.2.35 |
| 影響を受けるバージョン | 8.2・8.3・8.4・8.5 系の、上の修正版より前のもの(CVEの公式記録による。サポートが終わった8.1以前は公式の修正対象外) |
| CVE-2026-109618 | メモリ不足の処理の途中で、内部のデータが不完全なまま扱われることによる遠隔からのプログラム実行(RCE) |
| CVE-2026-109619 | 前の通信で使ったデータが不正に残ることによる遠隔からのプログラム実行(RCE) |
| 深刻度 | 2件とも CVSS v4.0 で 9.2(緊急) |
| 危険がある構成 | Webのリクエストを処理するすべてのPHP(PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど)。mod_phpの構成が最も危険で、ログインなしの通信で、アプリの処理が始まる前に攻撃が成立することが実証されている |
| 設定変更による緩和策 | 一部の攻撃経路を減らせるが、安全にはならない。完全な対策は更新だけ |
| PHP 8.1以前 | PHPプロジェクトからの更新は出ない。Linuxディストリビューションや長期サポート事業者が独自に修正を出す場合がある。自分でPHPを組み立てている利用者向けに、7.4・8.0・8.1用の最小限の修正(ソースコード)も公開 |
📰 出典:PHP「Security advisory: Critical remote code execution vulnerabilities, update now」(2026年10月21日)
報道で伝えられていること(公式には未確認)
公式発表では、脆弱性の番号や中身は明かされていません。一方、海外のIT媒体BleepingComputerは、セキュリティ企業watchTowrの話として次のように報じています。
📰 出典:BleepingComputer「PHP warns admins of two critical flaws, emergency patches coming tomorrow」
- 2件は「CVE-2026-109618」「CVE-2026-109619」という番号で、遠隔から任意のプログラムを実行される(RCE=リモートコード実行)種類の脆弱性とされる
- PHP 5〜8という幅広いバージョンが影響を受けると見られている
- 情報は予定より早く漏れたとされるが、実際に悪用された形跡はまだ確認されていない(追記:10月21日14時には、悪用できると主張するコードが出回り始めたとの報告も出ています)
ただし、報道では深刻度を「CVSS 10.0」としており、公式発表の「9.2」と食い違っています。また、執筆時点では、CVEの公式データベース(CVE.org)や米国の脆弱性データベース(NVD)に、この2つの番号の記録はまだ公開されていません。(追記:10月22日 0時時点:その後、CVE.orgとNVDに2件の記録が公開され、CVE番号が公式に確認されました。深刻度はどちらもCVSS v4.0で9.2です)影響を受けるバージョンや修正の範囲は、日本時間21日23時の公式発表で確定する(追記:10月21日 23時時点:公式発表の内容は、上の「修正版の公開」を参照してください)と考えてください。
CVE番号やCVSSの点数の読み方は、次の記事で解説しています。


PHPとは?WordPress・EC-CUBE・Laravelなど代表的なフレームワークとの関係
PHPは、Webサイトやシステムを動かすプログラミング言語の1つです。画面を表示したり、フォームの入力を受け付けたり、データベースとやり取りしたりする処理を、サーバーの上で行います。
WordPressもEC-CUBEもLaravelも「PHPの上」で動いている
WordPressのようなCMS(=ホームページを管理画面から更新できる仕組み)や、Laravelのようなフレームワーク(=システムを効率よく作るための部品と決まりごとの集まり)は、どれもPHPで書かれています。つまり、どのCMS・フレームワークを使っていても、土台のPHP本体に欠陥があれば影響を受けるということです。
ここで大事なのは、今回のように報道でPHP本体の欠陥とされる場合、WordPressやLaravelのアップデートだけでは対応になりません。サーバーに入っているPHPそのものを修正版に更新する必要があります。
しかし、使用しているCMSやフレームワークのバージョンによってはPHPのバージョンをあげることで動かなくなる場合があり、脆弱性への修正を取り込めない可能性があります。
PHP 8.1までしか動かない古いCMSやフレームワークのバージョンに注意(WordPress 6.0以前・Laravel 8以下など)
次のバージョンのCMSやフレームワークは動かせるPHPの上限が8.1以下です。PHPのサポートが続いているのは8.2〜8.5なので、これらのバージョンのままでは、サポート中のPHPに上げられません。数年前に作ったシステムでは、サポートが切れたバージョンがそのまま動いていることも珍しくないので、自社のシステムが当てはまらないか確認しておきましょう。
| 名前 | 対応するPHPの上限が8.1以下のバージョン | 補足 | 目安(このころまでに作られ、その後更新していないシステム) |
|---|---|---|---|
| WordPress | 6.0以前 | 6.1でPHP 8.2に対応。5.8以前は8.0まで、5.5以前は7.4まで | 2022年ごろまで(6.1は2022年11月公開) |
| Laravel | 8以下(Laravel 9未満) | 8は8.1まで、6・7は8.0まで、5.x は7系のみ | 2021年ごろまで(9は2022年2月公開) |
| CakePHP | 3.x以前 | 3.x は7.4まで。2.x は7系まで | 2019年ごろまで(4.0は2019年12月公開) |
| CodeIgniter | 3.x の全バージョン/4.2.10以前 | 3.x は3.1.12で8.1に対応したのが最後。4.x は4.2.11以降で8.2に対応 | 3.x は2019年ごろまで(4.0は2020年2月公開)、4.x は2022年ごろまで(4.2.11は2022年12月公開) |
| EC-CUBE | 4.2以前 | 4.2は7.4〜8.1、4.0・4.1は7系まで、3.0は5.3.9〜7.1 | 2024年前半ごろまで(4.3は2024年7月公開) |
| Symfony | 公式に上限の記載なし | 古いバージョンでどのPHPまで動くかは、開発会社に確認が必要 | ― |
「目安」は、PHP 8.2に対応したバージョンが公開された時期から逆算した、おおよその年です。その後にバージョンアップしていれば当てはまりませんし、新しいバージョンが出たあとも、しばらく古いバージョンで作られることがあります。正確なところは、開発会社に実際のバージョンを確認してください。
📰 出典:WordPress「PHP Compatibility and WordPress Versions」
📰 出典:WordPress「Releases」(各バージョンの公開日)
📰 出典:Laravel「Release Notes」(サポートポリシー)
📰 出典:CakePHP「Installation」(3.x)
📰 出典:CakePHP「Installation」(2.x)
📰 出典:CodeIgniter「Change Log」(3.x)
📰 出典:EC-CUBE「システム要件」(3.0)
📰 出典:PHP「Unsupported Branches」
つまり、表に当てはまるバージョンで作られたシステムは、PHPの修正版を当てる前に、WordPressやフレームワーク自体を新しいバージョンに上げる必要がある可能性が高いということです。フレームワークのバージョンアップは1つずつ段階を踏んで行うのが一般的で、プラグインや追加した機能の対応も含めて、作業と動作確認に時間と費用がかかります。修正版を「当てるだけ」で済むと考えず、早めに開発会社と相談しましょう。
また、表の上限より新しいバージョンでも、WordPressやフレームワーク自体のサポートが終わっている場合があります。たとえばLaravelは、12より前のバージョンのセキュリティサポートがすでに終わっています(12は2027年2月まで)。今回はPHPの更新で乗り切れても、近いうちにバージョンアップを計画しておくと安心です。フレームワークのバージョンアップの費用の考え方は、次の記事も参考にしてください。


サポートが終わったPHPには、修正版が出ない可能性が高い
PHPは、バージョンごとにサポート期間が決まっています。執筆時点でセキュリティ修正の対象になっているのは、次の4つです。
| PHPのバージョン | セキュリティ修正の提供期限 |
|---|---|
| 8.2 | 2026年12月31日 |
| 8.3 | 2027年12月31日 |
| 8.4 | 2028年12月31日 |
| 8.5 | 2029年12月31日 |
PHPの公式サイトでは、サポートが終わったバージョン(8.1以前)は「修正されない脆弱性にさらされるおそれがあり、できるだけ早く更新すべき」と説明されています。今回の修正版も、通常はサポート中のバージョン向けに出ると考えられます(正式な対象は21日の発表で確認が必要です)。PHP 8.1以前や7系で動いているシステムは、修正版を当てるだけでは済まず、PHPのバージョンアップが必要になる可能性があります。
(追記:10月21日 23時時点)PHP公式の発表で、8.1以前にはPHPプロジェクトからの修正版は出ないことが確定しました。深刻さを踏まえて7.4・8.0・8.1向けの最小限の修正(ソースコード)も公開されましたが、これは自分でPHPを組み立てて(ビルドして)いる人向けです。Linuxディストリビューションや長期サポートの事業者が独自に修正を出している場合もあるので、サーバー会社や開発会社に確認してください。いずれにしても一時しのぎで、サポート中のPHP(8.2以上)へのバージョンアップが必要なことは変わりません。
📰 出典:PHP「Security advisory: Critical remote code execution vulnerabilities, update now」(2026年10月21日)
発注者にとって何が変わるか/変わらないか
ここからは、公式発表と報道をもとにした筆者の見解です。
修正版を当てるまで、止めるか・制限するかを今日のうちに決める
(追記:10月21日 23時時点)修正版が公開されたため、いま最優先でやることは「修正版を当てる」ことです。PHP公式は、設定の変更などの緩和策は攻撃の一部を減らすだけで、安全にはならないとしています。WordPressの公式ブログは、PHP 8.2より前のバージョンを自社で管理している場合、更新の準備が整うまでサーバーをオフラインにすることを検討するよう呼びかけ、同様の助言を出している英国の国家サイバーセキュリティセンター(NCSC)の言葉を引用しています。修正版をすぐに当てられないシステムは、一時停止を前提に開発会社と相談してください。
📰 出典:WordPress「Critical PHP Security Release」
当初この記事では、実際に悪用された形跡が報告されていないことから、修正版を待たずにシステムを止める必要はないとお伝えしていました。その後、状況が変わってきています(追記:10月21日 18時時点)。
- セキュリティ企業のGMO Flatt Securityは、この脆弱性を悪用できると主張するコードがインターネット上に出回り始めていると報告しています(真偽は未確認)。また、修正版が出る前に試せる設定の変更だけでは、攻撃を防ぎきれない見込みだとしています
- CMS「PowerCMS」を提供する会社は、影響範囲が明らかになるまで、対象サイトの一時停止なども検討するよう案内しています(追記:10月21日 20時時点では、同社のWebサイト自体がこの脆弱性への対策として19時から緊急メンテナンス中で、案内ページは表示できない状態です)
- 報道では、ログインしなくても攻撃できる種類とされています(公式には未確認)。そのため、管理画面へのログインだけを止めても、十分な対策にならない可能性があります
- Laravelの公式ブログは、サーバー管理サービス「Laravel Forge」の利用者に向けて、修正版をすぐに当てられない場合は、当てられるまでサーバーを停止するよう案内しています(追記:10月21日 22時時点)
- 国内でも、保育園向けサービス「コドモン」、ゲーム「Shadowverse: Worlds Beyond」、ネットショップ作成サービス「BASE」、「さくらのレンタルサーバ」など、有名なサービスが相次いで緊急メンテナンスに入ったり、予告したりしていると報じられています。報道によると、日本の国家サイバー統括室も、できるだけ早い対応を求めています(追記:10月21日 23時時点)
📰 出典:GMO Flatt Security「PHPの重大な脆弱性「php2shell」(CVE-2026-109618、CVE-2026-109619)の概要と対応指針」
📰 出典:PowerCMS「PHP の重大な脆弱性(CVE-2026-109618、CVE-2026-109619)に関する注意喚起」
📰 出典:Laravel「PHP Critical Vulnerability Response Updates」(10月21日 13:17 UTC更新)
一方で、PHPの公式発表では、実際の悪用が確認されたとはされていません(追記:10月21日 23時時点:公式発表では、mod_phpの構成で攻撃が成立することが実証されているとしています。実際に攻撃された被害の公式な報告は、執筆時点では確認していません。追記:10月22日 0時時点では、CVEの記録に付いた米国CISAの評価でも、悪用は「確認されていない」とされています)。止めるかどうかは、扱うデータ(個人情報・決済情報など)の重さ、止めたときの業務やお客様への影響、修正版をすぐ当てられるか(サポート中のPHPか)によって変わります。次の選択肢から、開発会社と今日のうちに決めておきましょう。
| 対応 | 内容 | 向いているケース |
|---|---|---|
| 一時停止(メンテナンス表示) | サイトやシステム全体を止める | 個人情報・決済情報を扱う/サポートが終わったPHPで、修正版をすぐ当てられない |
| アクセス制限 | 社内やVPNなど、決まった場所からしか使えないようにする(IP制限) | 社内向けの業務システムや管理画面 |
| 管理画面へのログイン停止 | 管理画面だけ使えなくする | 改ざんの被害を小さくする一時的な予防策。ただし、上のとおり十分とは限らない |
| 監視しながら公開を続ける | 不審なアクセスを監視し、修正版が出たら最速で当てる | 止めたときの影響が大きく、修正版をすぐ当てられる体制がある |
変わること1:PHPの更新を「急ぎ」で行う段取りが必要になる
CVSS 9.2の脆弱性は、通常の定期メンテナンスを待たずに対応するのが一般的です。PHPの更新を誰が行うかは、サーバーの種類によって変わります。
| サーバーの種類 | PHPを更新するのは主に誰か |
|---|---|
| レンタルサーバー・マネージドサーバー | サーバー会社(管理画面でPHPのバージョンを選ぶ形式なら、自社や開発会社が切り替える場合もある) |
| VPS・クラウド(AWSなど) | サーバーを管理している開発会社、または自社の担当者 |
| 社内のサーバー | 社内の情シス担当、または保守を任せている開発会社 |
自社のケースがどれに当たるかは、保守契約の範囲とあわせて確認しておきましょう。
(追記:10月21日 22時時点)Laravelが提供するサービスでも、更新する人が分かれています。Laravel Cloudと、Laravel Vapor(標準の実行環境でPHP 8.3以上)は、提供側が修正版を自動で当てると案内しています。一方、Laravel Forgeでは利用者が管理画面から自分でPHPを更新する必要があり、Vaporでも独自のDockerイメージを使っている場合は、自分でイメージを作り直して入れ替える必要があります。
📰 出典:Laravel「PHP Critical Vulnerability Response Updates」(10月21日 13:17 UTC更新)
(追記:10月21日 23時時点)WordPressの公式ブログによると、今回はWordPress本体の更新は不要で、予定もありません。必要なのはPHP本体の更新です。サイトがどのPHPで動いているかは、WordPressの管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。なお、Laravelによると、23時の時点ではUbuntu向けのPHPの配布元にまだ修正版が届いておらず、Laravel Forgeで更新しても修正版にならない状態です。サーバーの種類によっては、修正版が使えるようになるまで時間差がある点にも注意しましょう。
📰 出典:WordPress「Critical PHP Security Release」
📰 出典:Laravel「PHP Critical Vulnerability Response Updates」(10月21日 13:54 UTC更新)
変わること2:古いPHPのままのシステムは、作業と費用が大きくなりうる
サポート中のPHPなら、多くの場合は同じ系列の新しい版に入れ替えるだけで済みます。一方、サポートが終わった古いPHPで動いているシステムは、PHPのバージョンを上げる必要があり、それにあわせてWordPressのプラグインやフレームワーク本体の更新、動作確認が必要になることがあります。見積もりやスケジュールの判断のしかたは、次の記事も参考にしてください。


「まずは『今どのPHPで動いているか』だけでも分かれば、更新で済むのか、バージョンアップが必要なのかの見当がつきます。21日の発表が出たら、すぐに照らし合わせましょう。」
今やるべきこと・まだ様子見でいいこと
| 区分 | 内容 |
|---|---|
| 今すぐ | 公開された修正版(8.5.12・8.4.27・8.3.36・8.2.35)に更新する。レンタルサーバーの場合は、サーバー会社の更新状況を確認する(追記:10月21日 23時時点) |
| 今やること | 自社のWebサイト・システムごとに、PHPのバージョンと、使っているCMS・フレームワークを開発会社に確認する |
| 今やること | PHPの更新を誰が行うか(サーバー会社・開発会社・自社)と、保守契約の範囲内かを確認する |
| 今やること | 日本時間21日23時の公式発表のあと、いつ更新するかを開発会社と決めておく |
| 今やること | 修正版を当てるまで、サイトの一時停止・アクセス制限・監視のどれで対応するかを開発会社と決めておく(追記:10月21日 18時時点) |
| 発表後すぐ | 公式に発表された「影響を受けるバージョン」と自社のPHPのバージョンを照らし合わせる |
| 発表後すぐ | サポートが終わったPHPを使っている場合は、バージョンアップの計画と見積もりを相談する |
| 様子見でよい | フレームワークや言語の乗り換えの検討(今回の対応が落ち着いてからで遅くありません) |
発注者がやること チェックリスト
- ☐ 自社のWebサイト・システムが、どのバージョンのPHPで動いているか把握した
- ☐ 使っているCMS・フレームワーク(WordPress・Laravelなど)とそのバージョンを把握した
- ☐ PHPの更新を誰が行うか(サーバー会社・開発会社・自社)を確認した
- ☐ 緊急のセキュリティ更新が保守契約の範囲内か、別費用かを確認した
- ☐ 日本時間10月21日23時の公式発表を誰が確認し、いつ更新するかを決めた
- ☐ サポートが終わったPHP(8.1以前)を使っていないか確認した
- ☐ WordPressやフレームワークのバージョンが、「PHP 8.1までしか動かない古いバージョン」の表に当てはまらないか確認した
- ☐ 更新後に、サイトやシステムが正しく動くかを誰がどう確認するか決めた
開発会社への質問例
- 「当社のシステムは、どのバージョンのPHPで動いていますか?WordPressやフレームワークのバージョンも教えてください」
- 「10月21日に出るPHPの修正版(CVE-2026-109618・109619と報じられているもの)は、当社のシステムに関係しますか?」
- 「PHPの更新は、御社とサーバー会社のどちらが行いますか?保守契約の範囲で対応してもらえますか?」
- 「修正版が出たら、いつまでに更新できますか?更新の前後で、サイトが止まる時間はありますか?」
- 「PHPやWordPress・フレームワークのバージョンが古くて修正版を当てられない場合、フレームワークも含めたバージョンアップにどのくらいの作業と期間がかかりますか?」
まとめ
(追記:10月21日 23時時点)PHPの開発チームは日本時間21日22時40分ごろ、修正版(8.5.12・8.4.27・8.3.36・8.2.35)を公開しました。2件はログインなしで遠隔からプログラムを実行される脆弱性で、完全な緩和策はなく、更新だけが安全な対策です。PHP 8.1以前には公式の修正版が出ません。
PHPの開発チームは、緊急度の高い脆弱性2件(CVSS v4.0で9.2)を直す修正版を、日本時間10月21日23時に公開すると予告しています。報道では、この2件はCVE-2026-109618・CVE-2026-109619と呼ばれ、遠隔から任意のプログラムを実行される種類のものとされています。ただし、影響を受けるバージョンなどの詳細は、修正版の公開時に公式に発表されます。
WordPressやLaravel、Symfony、CakePHP、CodeIgniterなど、PHPで作られたシステムは土台のPHPの影響を受けます。発注者が今日やるべきことは、自社のシステムのPHPのバージョンと、更新を誰が行うかを確認し、公式発表のあとすぐ更新できる段取りを開発会社と決めておくことです。サポートが終わった古いPHPを使っている場合は、バージョンアップも含めて早めに相談しましょう。
あわせて読みたい関連記事













