2026年10月21日(日本時間の夜)、プログラミング言語PHPの開発チームが、重大な脆弱性2件を修正したセキュリティリリースを公開しました。2件とも深刻度は、評価基準CVSS v4.0で「9.2」(満点は10.0)です。
PHPは、WordPressをはじめ、世界中の多くのWebサイトの裏側で動いています。「自分のサイトは大丈夫?」と気になった方のために、この記事では次のことを整理します。
- 何が起きたのか、どれくらい危ないのか
- 修正版のバージョンと、対象になる・ならないの目安
- WordPressなどのサイト運営者が、今日からやること
先に結論です。公式は「認証なしでリモートからコードを実行される恐れがある。すべてのPHP利用者は直ちに更新を」と呼びかけています。そして、設定変更などの回避策では完全には防げず、PHPのバージョンを修正版に更新することだけが確実な対策とされています。(情報は2026年10月22日時点です)
【2026年10月22日 更新】 修正版公開の翌日に確認できた新情報を反映しました。主な更新点は、①攻撃の状況(各社の見立ての整理)、②暫定対策の注意点(設定後はPHPの再起動が必要)、③PHP 8.1以前向けの非公式な修正の扱い、④国内レンタルサーバー各社の対応状況、⑤脆弱性が見つかった経緯です。
【10月22日追記】公開後に分かったこと
記事の公開後、攻撃の状況や対策について新しい情報が出ています。(2026年10月22日時点)
- 悪用の報告は、情報源によって分かれています。
- セキュリティ会社のwatchTowrは、10月21日に自社のおとりの仕組み(ハニーポット)で、実際の悪用を観測したと報告しています。なお、米CISAの「悪用が確認された脆弱性の一覧」には、同社の記載の時点では載っていません。
- Cloudflareは、詳細が流出した後に、自社の顧客を狙う攻撃通信を観測し、攻撃者が防御を避けるために手口を変えてきたと説明しています。
- 一方、カナダのサイバーセキュリティセンターは、攻撃用のコード(PoC)が出回っているものの、悪用は確認していないとしつつ、状況はすぐ変わり得ると注意しています。
- 確認できる範囲では、実際に攻撃が行われているとする報告がある段階です。更新を後回しにできる状況とは言えません。
- Cloudflareは、10月21日3:02(UTC)から、WAF(Webサイトを守る防御サービス)の無料プランを含む各プランで、この攻撃を既定で防ぐようにしたと発表しています。 ただし同社は、これで更新が不要になるわけではなく、PHP自体を更新するよう呼びかけています。
- 影響を受ける範囲は、広く考えたほうがよさそうです。 カナダのサイバーセキュリティセンターは、WebからのリクエストをPHPが処理する構成(Apacheのmod_php、PHP-FPM、php-cgiなど)は、いずれもリスクがあるとしています。なかでもmod_phpは、サイト側のプログラムが動く前に、ログインなしのリクエストで問題を起こせるため、最もリスクが高いとされています。
- サポートが終わったPHP(8.1以前)も、一部のOS提供元や長期サポートの業者が、独自に修正を出す場合があります。 利用中の提供元の案内を確認してください(カナダのサイバーセキュリティセンターの記載)。
国内のレンタルサーバー各社の対応は、日々更新されています。契約先のお知らせを直接確認してください。
まずは中学生にも分かる説明
専門用語を使わずに、ざっくり説明します。
PHPは、サイトの「店員さん」のような存在です。 あなたがWebサイトを開くと、PHPが裏で注文を受けて、ページを組み立てて返してくれます。WordPressで作られたサイトも、多くはこの店員さんが動かしています。
今回見つかった問題は、店員さんが「失敗したあとの片づけ」でミスをしてしまうというものです。公式の説明を、たとえ話にするとこうなります。
- 仕事が多すぎて店員さんが途中で手を止めてしまったとき(メモリ不足)、書きかけのメモを正しいメモと思い込んで片づけてしまう
- 前のお客さんのメモが捨てられないまま残り、次のお客さんの対応で使われてしまう
悪意のある人が、わざとこの失敗を起こすようなアクセスを送ると、店員さんが操られ、最終的にサーバーを乗っ取られる恐れがあるというのが今回の脆弱性です。しかも、ログインしていない人でも狙えるとされています。

あくまでイメージをつかむためのたとえ話で、実際の仕組みはもう少し複雑です。直し方は一つで、店員さん(PHP)を、ミスを直した新しい版に入れ替えること。それが、このあと出てくる「PHPの更新」です。
何が起きたのか:PHP本体の重大な脆弱性2件
PHP公式は、10月20日に「21日14:00(UTC)に重大なセキュリティリリースを行う」と事前告知しました。日本時間では10月21日の23:00にあたります。そして21日、修正版の公開とあわせて、2件の脆弱性について公式のアドバイザリ(注意喚起)を出しました。
| 項目 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| 公式の分類 | メモリ不足(OOM)時の処理の不具合によるRCE | 古い内部状態が残ることによるRCE |
| 公式の説明(要約) | メモリ不足でPHPが中断されたとき、内部データが中途半端な状態のまま後片付けの処理に渡り、不正なデータが正常として扱われる | リクエストごとの内部データが、元のメモリが解放された後も残り、同じワーカーが次に処理するリクエストがその古い状態を使ってしまう |
| 深刻度(CVSS v4.0) | 9.2 | 9.2 |
RCEは「リモートコード実行」の略で、外部の攻撃者が、狙ったサーバー上で好きなプログラムを動かせてしまう状態のことです。サーバーの乗っ取りにつながり得るため、脆弱性の中でも最も警戒される種類のひとつです。公式は「認証なしで」起こり得ると説明しています。つまり、ログインしていない第三者からも狙われる可能性がある、ということです。
なぜ「重大」と言われるのか
アプリではなく、PHP本体の問題
セキュリティ企業Sansecの解説によると、今回の問題はPHPのエンジン自体にあります。そのため、WordPressやLaravelなどのアプリ側のコードが丁寧に書かれていても、影響を受ける可能性があります。
Sansecは、研究者(Calif)の検証として、Magento、WordPress、Drupal、Joomla、Laravel、Symfony、phpMyAdmin、Nextcloudなど、よく使われる11のPHPアプリで認証前のRCEを確認したと報告しています。これは研究者による検証の結果で、実際の被害件数を示すものではありません。
ここが、WordPressのプラグインの脆弱性との大きな違いです。プラグインの問題なら、プラグインを更新すれば済みます。今回はPHP本体の問題なので、WordPress本体やプラグインを更新しても直りません。レンタルサーバーやVPSで動いているPHPそのものを、更新する必要があります。

古いPHPは、公式の修正が出ない
公式の修正版は次の4つです。
| PHPのブランチ | 修正版 |
|---|---|
| 8.5系 | 8.5.12 |
| 8.4系 | 8.4.27 |
| 8.3系 | 8.3.36 |
| 8.2系 | 8.2.35 |
PHP 8.1以前はすでにサポートが終了していて、今回も公式の修正版(正式なリリース)は出ていません。ただしPHP公式は、7.4・8.0・8.1向けの最小限の修正(バックポート)をソースコードのリポジトリ(php-src)で公開しています。ソースから自分でビルドしている人向けの位置づけで、LinuxのOSやLTS(長期サポート)ベンダーには、修正が事前に配られていたと公式は説明しています。Sansecによると、影響を受けるコードは古く、PHP 5.4.0以降にさかのぼるとされています。古いPHPを使っているサイトは、サポートされている版への移行が必要です。
なお、8.2系も2026年12月31日にサポートが終了すると、公式のリリースノートに書かれています。今回の更新を機に、8.3以降への移行も視野に入れておくと安心です。
時系列で整理
| 日付 | 出来事 | 情報源 |
|---|---|---|
| 2026年8月11日 | 研究者(Calif)が最初の問題をPHPに報告 | Sansec |
| 2026年8月24日 | Wiz ResearchがPHPに報告 | Sansec |
| 2026年10月20日 | PHP公式が「重大なセキュリティリリースを予定」と事前告知。同日、詳細が外部に漏れたとされる | PHP公式、Sansec |
| 2026年10月21日 | 修正版(8.5.12、8.4.27、8.3.36、8.2.35)とアドバイザリを公開 | PHP公式 |
| 2026年10月21日 | 修正版の公開前から、Cloudflareが早期の攻撃を観測したとSansecが記載(協定世界時7:43)。WAFによる防御ルールの提供も始まる | Sansec、Help Net Security |
事前告知の時点では、技術的な詳細も影響するバージョンも公表されていませんでした。セキュリティ企業のQualysも、10月20日の時点では「CVE番号はPHPが確認しておらず、影響範囲は未公開」と注意していました。
攻撃はもう始まっているのか
情報源によって書き方が異なるため、確認できた範囲を分けて書きます。(10月22日時点で再確認しました)
- セキュリティ会社Huntress:10月20日時点では、実際の悪用は確認していないとしています。
- GMO Flatt Security:10月21日の追記で、悪用できると主張するコードがインターネット上に出回り始めたと記しています。
- watchTowr:10月21日に、おとりの仕組みで悪用を観測したと報告しています。
- Cloudflare:詳細の流出後、自社の顧客を狙う攻撃通信を観測したと説明しています。
- カナダのサイバーセキュリティセンター:攻撃用のコードは出回っているが、悪用は確認していないとしています。
はっきり言えるのは、「実際の被害の広がり」はまだ誰も確定できていない一方で、悪用の動きがあるとする報告が複数あるということです。修正版が公開されて詳細が広まった今、攻撃が増える可能性があると、複数の解説が見ています。ここは各社の見立てであり、確定した事実ではありません。
また、2件のうちどちらがどの機能(アップロードの進捗表示機能など)に関係するかは、公式の説明と、Sansec・Flatt Securityの解説とで書き方が異なっています。この記事では公式の説明を採用し、機能との対応は断定していません。
サイト運営者が今やること
1. 自分のPHPのバージョンを調べる
WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で、PHPのバージョンを確認できます。レンタルサーバーの場合は、サーバーの管理画面(PHPバージョンの切り替えページ)でも確認できます。
調べるのは、次の点です。
- 8.5・8.4・8.3・8.2系で、修正版(上の表)以上になっているか
- 8.1以前を使っていないか
なお、LinuxのOSが用意しているPHPは、バージョン番号が公式と異なる形で修正されることがあります。VPSなどで自分で管理している場合は、OSの提供元の案内も確認してください。
2. レンタルサーバーの対応を確認する
レンタルサーバーでは、サーバー側でPHPが更新される場合と、管理画面から利用者が切り替える場合があります。契約しているサーバー会社のお知らせを確認してください。
国内の各社は、10月21日の夜から22日にかけて、サイトの一時停止や緊急メンテナンスを案内しています。確認できた範囲は次のとおりです。
- カゴヤ(公式のお知らせを直接確認、10月21日18時20分更新):レンタルサーバープランのPHP 8.2〜8.5系は、修正版を確認したうえで順次更新する予定。そのほかのプランやバージョンは対応方針を調整中としていました。
- そのほかの会社:Webセキュリティ診断センターのまとめ記事によると、エックスサーバーは22日朝に「PHP 8.2〜8.5の修正パッチ適用が完了した」と案内し、ロリポップ!やヘテムル、ムームーサーバーは一部のサイトを一時停止したとされています。さくらのレンタルサーバ、ConoHa WING、お名前.comは、告知に「PHP」の記載がないまま緊急メンテナンスを案内したとのことです。この部分は、私が各社の公式ページを直接開いて確認できたものではなく(エックスサーバーのページは開けませんでした)、まとめ記事を通した情報です。
告知に「PHP」と書かれていない会社でも、対応していないとは限りません。逆に、サイトを止めただけでは、PHPの更新が済んだかどうかは分かりません。各社の最新のお知らせと、管理画面のPHPバージョンの表示を確認してください。
3. 更新までの時間稼ぎ(完全な対策ではありません)
公式は「完全な緩和策はなく、更新だけが安全」としています。そのうえで、公式やFlatt Security、Sansecは、更新までの一時的な対策として次のようなものを挙げています。
- `session.upload_progress.enabled` を `0` にする(CVE-2026-109619の一部の攻撃経路しか防げず、CVE-2026-109618には効きません)
- PHP 8.5を使っている場合は、`fatal_error_backtraces` を `0` にする(公式が挙げる暫定策)
- `post_max_size` を小さくする(アップロードを使わないなら8M程度。公式が挙げる暫定策)
- Cloudflareなどのセキュリティサービス(WAF)を前に置く
- ファイルのアップロードなどに使われる通信(multipart/form-data)を遮断する(アップロード機能が使えなくなる恐れがあります)
- 更新できるまで、サイトを一時的に止める(WordPressなどの「メンテナンスモード」では防げません。PHPがリクエストを処理する時点で問題が起きるためです。Sansecの指摘です)
設定の `memory_limit` を `-1`(無制限)にする方法は、公式も暫定策として挙げています。Datadogも、既知の攻撃経路をふさぐが恒久対策ではない、と注意しています。一方でSansecは、1つのリクエストがサーバーのメモリを使い切るおそれがあると警告しています。
これらの設定は、`php.ini` やPHP-FPMの設定ファイルなど、アプリ側から上書きできない場所で行う必要があります。公式によると、`ini_set()` や `.user.ini` では効果がなく、設定後はPHPのワーカーをすべて再起動する必要があります。ふだんWordPressを使っているだけの方は、設定をいじるよりも、サーバー会社の案内に従ってPHPを更新するほうが現実的です。
4. 更新したら再起動と動作確認、バックアップも
VPSなどで自分で更新した場合は、PHP-FPMやWebサーバーを再起動して、新しい版が読み込まれたことを確認してください。レンタルサーバーの管理画面で切り替える場合は、基本的に不要です。
PHPを更新すると、古いプラグインやテーマが動かなくなることがあります。更新の前にバックアップを取り、更新後は表示や管理画面、フォームなどを一通り確認しておくと安心です。
今回の件で分かること(筆者の考察)
ここからは筆者の考察です。
- 今回の弱点は、PHPが「メモリ不足などの失敗」から立ち直るときの処理にあります。普段は目立たない場面の不具合が、深刻な脆弱性になった例だと言えます。
- Sansecによると、発見した研究者3組は、いずれも高性能なAIモデルが攻撃コードの実用化に役立ったと述べているとのことです。この点は、Sansecの記載を紹介するにとどめます。
- 発見の経緯について、GIGAZINEは次のように伝えています。セキュリティ企業のCalifとWizが、それぞれ独立して2026年8月に見つけてPHPに報告しました。CalifはOpenAIが6月に発表した「Patch the Planet」というセキュリティの取り組みの一環で見つけたとしており、OpenAIやGoogleのチームも、修正の調整に協力したとされています。Wizが発見にどのAIを使ったかは、同記事からは読み取れません。
- 運営者側から見ると、「サイトのコードを更新していればよい」では守れない場面が増えています。サーバーのPHPのバージョンに目を向ける習慣が大切になりそうです。
まとめ
- PHP本体に、認証なしでサーバーを乗っ取られる恐れがある重大な脆弱性2件(CVE-2026-109618・109619、CVSS 9.2)が見つかり、2026年10月21日に修正版が公開された
- 修正版は8.5.12、8.4.27、8.3.36、8.2.35。8.1以前は公式の修正がなく、移行が必要
- WordPress本体やプラグインの更新では直らない。サーバーのPHPの更新が必要
- 回避策では完全には防げない。まず自分のPHPのバージョンを確認し、サーバー会社の案内に沿って更新する
- 攻撃の状況は情報源によって見方が分かれる(10月22日時点)。修正版の公開で状況が変わり得るため、早めの更新が安全
詳細は、PHP公式のアドバイザリと、各セキュリティ企業の解説で更新されていく見込みです。数日のうちに情報が変わる可能性があるので、最新の発表も確認してください。
サイトを触る前に、バックアップを取っておくと安心です。外付けSSDに丸ごと保存しておけば、更新で不具合が出ても元に戻せます。
PHPやサイトの更新前のバックアップ置き場に。小型で持ち運びやすい外付けSSDです。
Amazonで詳細を見る →
