スマホやパソコンを使うだけの人は、端末側で更新する作業はありません。サイトやサーバーを運営している人は、修正版PHP 8.5.12／8.4.27／8.3.36／8.2.35への更新が唯一の確実な対策です。
2026年10月21日、PHPに見つかった深刻度「緊急」の欠陥2件（通称php2shell）の修正版が公開されました。
日本時間23時の公開予定に合わせて、通販サイトやゲーム、レンタルサーバー各社が夜11時から予防的なメンテナンスに入り、首相までもが適用を呼びかける事態になりました。
翌日に検索する人にとって知りたいのは、何が起きたのか、自分に関係あるのか、そして何をすればいいのかという3点でしょう。
この記事では、時系列の整理から読者タイプ別のやること、版の確認方法、設定変更やWAFでは防げない理由までをひと通り押さえています。
PHP脆弱性で10月21日の夜、何が起きたのか
2026年10月21日、PHPの開発チームが、認証なしで遠隔からサーバー上でコードを実行される（RCE）おそれのある欠陥2件を修正した版を公開しました。
深刻度は2件ともCVSS v4.0で9.2、最も高い「緊急（Critical）」レベルです。
通称は「php2shell」と呼ばれています。
まず結論として、スマホやパソコンを使うだけの人は、端末側で更新する作業はありません。
PHPはサーバー側で動く仕組みで、利用者の端末に入れて直すものではないためです。
一方、サイトやサーバーを運営している人には、やるべきことがあります。
予告から公開までの時系列
流れは次のとおりです。
10月20日（協定世界時）にPHPのセキュリティチームが「重大な脆弱性2件の修正版を公開する」と予告し、公開予定は10月21日14:00（協定世界時）＝日本時間23:00とされました。
脆弱性の詳細が漏れたり悪用の証拠が出たりした場合は前倒しする、とも予告されていました。
実際には同日夜に修正版が公開されています。
ただし公開の正確な時刻には食い違う情報があり、報道は「日本時間23時前後」とする一方、公開済みだった時刻を検証したブログもあります。
ここでは「日本時間21日23時の公開予定で、同日夜に公開された」という表現に留めます。
この予告に合わせて、IPA（情報処理推進機構）が10月21日に「事前準備のお願い」を公開し、国家サイバー統括室や首相も修正プログラムの速やかな適用を呼びかけました。
首相はXで「大至急のお願いです」として適用を求め、すぐ適用できない場合はサイトの一時停止も有効としています。
なぜ夜11時に一斉メンテナンスが集中したのかというと、修正版の公開予定が日本時間23時だったため、各サービスがそれに合わせて予防的に停止・更新したからです。
BASE、makeshop、カラーミーショップ、コドモン、pixiv、niconico、DMM.com、さくらインターネットの一部サービス、ウマ娘 プリティーダービーやグランブルーファンタジーなどが、21日夜から22日にかけてメンテナンスや一時停止に入りました。
複数の自治体もシステム停止を予告しています。
止まったサービスが多いからといって、被害が発生したわけではありません。予防的な停止が中心です。
ウマ娘の公式も情報流出は確認されていないと案内しています。
個別サービスの再開時刻は各社の公式告知を確認してください。
脆弱性2件の内容と深刻さ
2件の欠陥は、どちらもメモリの使い方の不備です。
やさしく言い換えると次の表のとおりです。
| CVE番号 | 何が起きるか（やさしい説明） |
|---|---|
| CVE-2026-109618 | メモリが足りなくなったときの後始末に不備があり、リクエストの処理が途中で中断されると、不正なデータを有効なものとして扱ってしまう |
| CVE-2026-109619 | 前のリクエストが使っていた内部状態がメモリ解放後も残り、同じワーカーが処理する次のリクエストが古い状態（残りかす）を使ってしまう |
深刻度は2件ともCVSS 9.2で、ネットワーク経由・認証不要・利用者の操作不要で攻撃が成立しうる一方、攻撃の複雑さは「高」、攻撃の前提条件「あり」とされています。
誰でも簡単に攻撃できるわけではありませんが、成功すればサーバーを外部から操作されるおそれがあります。
公式の結論は「完全な緩和策はない。更新が唯一の安全な選択」です。
影響を受けるのは8.5.12未満、8.4.27未満、8.3.36未満、8.2.35未満の各8.x系で、修正版はPHP 8.5.12／8.4.27／8.3.36／8.2.35（2026年10月21日公開）です。
▶ PHPの脆弱性、一般の人は何をすればいい？ サイトがある人・ない人別に【ゆっくり解説】
PHP脆弱性は自分に関係ある？読者タイプ別のやること
「PHPの脆弱性って、自分にも関係あるの？」という疑問への答えは、使っている立場によってまったく違います。
次の表で自分のタイプを探してください。
| 読者のタイプ | 自分でやること |
|---|---|
| 一般のネット利用者（スマホ・PCで見るだけ） | 端末での更新作業は不要。パスワードの使い回しを見直す、多要素認証を使う、便乗した詐欺メールに警戒する、といった一般的な備えで十分 |
| クラウド型CMS・SaaSの利用者 | 原則不要。事業者のお知らせで対応完了を確認する |
| レンタルサーバー＋WordPress等の利用者 | 契約先の公式お知らせで更新完了・設定変更の要否を確認。PHPの版を選べるサーバーでは古い版（8.1以前）を選んでいないか確認 |
| パッケージ版CMSを自社サーバーに導入 | 自分でPHPを修正版へ更新する |
| VPS・自前サーバー運用者 | 修正版へ更新し、全ワーカーを再起動。ログの確認 |
| PHP 8.1以前を使う人 | 早急にサポート版へ移行する |
| すぐ更新できない組織 | インターネット公開アプリを外部から切り離す、サイトを一時停止することを検討する |
一般人・クラウドCMS利用者は作業ほぼ不要
10月21日の夜、ゲームや通販サイトが次々と止まり、首相までもが呼びかけたため、「自分のスマホも危ないのでは」と不安になった人は多かったようです。
SNSでは「世界の終わり感」「ドキドキ」「怖い」といった投稿が広がり、知恵袋には中学生レベルで説明してほしいという質問も立っていました。
しかし、PHPはサーバー側で動く言語なので、利用者の端末で更新する作業はありません。
知恵袋の回答でも、一般の利用者は企業側の対応を待てばよく、直接の対策はほぼ不要とされています。
心配な場合は、パスワードの使い回しをやめる、多要素認証を有効にする、脆弱性を口実にした詐欺メールに警戒する、といった普段通りの備えで足ります。
クラウド型のCMSを使っている場合も、事業者側で更新が完了する形が多いです。
たとえばMovable Typeのクラウド版は、10月22日0:12に8.3.36への更新が完了し、利用者の対応は不要と案内されました。
一方で、同じMovable Typeでもソフトウェア版やAMI版は、利用者自身での更新が強く推奨されています。同じ製品でも運用形態でやることが変わります。
運営者は更新が唯一の安全な選択
サイトやサーバーを自分で運営している場合、話は別です。
今回の欠陥はPHP本体のもので、アプリ側の対策では防げません。
IPAは「PHPはWebアプリだけでなく、ソフトウェア製品やネットワーク機器の内部でも使われている場合がある。利用状況を確認し、速やかな適用に備えよ」と呼びかけています。
見えないPHPが社内に潜んでいないか、棚卸しの機会にもしてください。
すぐに更新できない場合は、CERT-EUや政府も示しているとおり、公開アプリを外部から切り離す、サイトを一時停止する、という判断も選択肢です。
実際、国内の多くのサービスが予防的な停止を選び、それを評価する声もSNSで見られました。
止める判断は、乗っ取られた後に止めるよりずっと安くつきます。
なお、サーバー会社への問い合わせが殺到している時期には、何度も重ねて問い合わせるのは控えるとよいでしょう。
知恵袋の回答でも「専門家が徹夜で対応しているので」という呼びかけが見られました。
PHP脆弱性の影響を受けるサイトか確かめる方法と修正版への更新
運営者が最初にやるべきことは、自分のサイトが使っているPHPの版を確認することです。
版番号は「8.3」のような大まかな数字ではなく、3つ目の数字まで見る必要があります。
たとえば「8.3」と表示されていても8.3.35なら未修正、8.3.36なら修正済みです。
PHPの版の確認方法
確認方法は主に3つあります。
- コマンド：サーバーで
php -vを実行する（VPS・自前サーバーの運用者向け） - PHP関数：
phpversion()は動作中のPHPの版を文字列で返します（PHP_VERSION定数でも同等） - 管理画面：レンタルサーバーのコントロールパネルのPHP設定画面や、WordPressの「サイトヘルス」などで表示される
Webで動いているPHPと、コマンドで確認できるPHPの版が違う場合があります。コマンドの結果だけで判断しないでください。
実際にリクエストを処理している側の版を確認することが大切です。
版ごとの判定表と古いPHPの扱い
使っている版ごとの判定は次の表のとおりです（調査時点・2026年10月22日のサポート状況を含む）。
| 使っているPHP | 今回の影響 | 修正版 | サポート状況 |
|---|---|---|---|
| 8.5系 | 8.5.12未満は影響あり | 8.5.12 | アクティブサポート（2027年12月31日まで） |
| 8.4系 | 8.4.27未満は影響あり | 8.4.27 | アクティブサポート（2026年12月31日まで） |
| 8.3系 | 8.3.36未満は影響あり | 8.3.36 | セキュリティ修正のみ（2027年12月31日まで） |
| 8.2系 | 8.2.35未満は影響あり | 8.2.35 | セキュリティ修正のみ、2026年12月31日で終了 |
| 8.1・8.0・7.4 | 影響対象（サポート終了版） | 公式の修正版なし | サポート終了 |
PHP 8.1以前には公式の修正版が出ません。
ただし、セキュリティチームが7.4・8.0・8.1向けに最小限のソース修正（バックポート）をGitHubのブランチで提供しており、ディストリビューションやLTS事業者が独自に修正を出す場合もあります。
古い版には公式の修正版は出ず、最小限の修正がソースで提供されるだけなので、本来はサポート版への移行が筋です。
なお、PHP本体の更新は無償です。
php.netからソースやWindows版を入手できます。
自社で対応できない場合の代行サービスの例としては、セルバが「PHP緊急セキュリティアップデート支援」を10万円から提供しています（価格は調査時点のものです）。
設定変更やWAFでPHP脆弱性を防げる？暫定策の限界と攻撃の状況
「設定を1行変えれば防げる」という情報がSNSで広まりましたが、これは誤解を含む話です。
ここを正しく理解しないと、更新を後回しにしてしまう落とし穴にはまります。
暫定策の中身と「完全な緩和策はない」という公式の結論
公式は一時的な緩和策として、次のような設定を示しています。
- CVE-2026-109618向け：
memory_limit=-1、post_max_sizeを小さくする（アップロード不要なら8M、必要でも最大32M）、コンテナ/cgroupの制限 - CVE-2026-109619への対策としては、まず
session.upload_progress.enabled=0を設定し、さらにPHP 8.5の場合はfatal_error_backtraces=0も設定する必要があります。いずれも設定後は全ワーカーの再起動が必要
ただし公式自身が、これらの暫定策は「露出を減らすが、安全にはしない」と位置づけています。
設定を変えただけで更新を後回しにするのは危険です。設定変更はあくまで更新までのつなぎです。
経緯も触れておきます。
当初は「session.upload_progress.enabled=0という設定を1行加えるだけで防げる」との情報が広まりましたが、この対策を示した企業自身が、のちにそれでは不十分だったと訂正しています。
また「アップロード機能がないサイトは安全」という思い込みも誤りで、PHPはアプリ実行前にリクエスト本文を解析するため、ログイン画面を含むPHPファイル全般が対象になりうると指摘するブログもあります。
攻撃の観測状況とWAFの位置づけ
攻撃の状況はどうでしょうか。
Cloudflareは、修正版の公開前にすでに顧客を狙う攻撃トラフィックを観測し、防御回避のため攻撃内容を変化させる動きも追跡したと公表しています。
Palo Alto Networks Unit 42の推計では、影響を受けうるインスタンスは2,260万以上で、PoCコード（攻撃の再現コード）も観測されています。
少なくとも1つの欧州の政府が予防的にWebサイトを停止したと伝えられています。
一方で、国内で今回の件による被害が出たかは、調査時点で公表されていません。
「観測された攻撃」と「確認された被害」は別物で、この区別を混同しないことが大切です。
SNSでは「23時15分に乗っ取られる」「15分でAIが攻撃コードを作る」といった噂も出回りましたが、これらは根拠がなく伝言ゲームで変形した警告だと検証するブログもあります。
煽りに乗る必要はありません。
CloudflareのWAFについては、公開の約9時間前、10月21日03:02（協定世界時）から、無料を含むWAF有効の全プランで保護が自動適用されました。
ただしCloudflare自身が「WAFはつなぎであり、PHPの更新の代わりにはならない」と明記しています。Cloudflareを経由しない通信は守られません。
WAFは多層防御の一層と考え、本体更新を優先してください。
まとめ：PHP脆弱性への対応と、12月31日までに残る宿題
記事の内容を整理します。
今回起きたのは、PHP本体に見つかった認証なしで遠隔コード実行につながりうる欠陥2件（php2shell）の修正版が、2026年10月21日に公開されたことです。
一般の利用者は端末での作業不要で、普段通りの備えで十分。
運営者は、版番号の3つ目の数字まで確認し、8.5.12／8.4.27／8.3.36／8.2.35へ更新することが唯一の確実な対策です。
設定変更はつなぎ、WAFは補助と考えましょう。
そして、今回で終わりではありません。
PHP 8.2のセキュリティサポートは2026年12月31日で終了します。
今回8.2.35へ上げた人も、約2か月後には8.3以降への移行が必要です。
PHPのサポート方針は「アクティブサポート2年＋セキュリティサポート2年」で、終了後は修正が出ません。
8.4のアクティブサポートも同日に終わります。
移行の際は、古い版から一気に上げるとCMSやプラグインが動かない場合があるため、WordPressの推奨（8.3以上）を目安に、検証環境で動作確認してから移行すると安心です。
対応が難しい場合は、前述のような代行サービスの利用も選択肢になります。
「PHPは脆弱性が多い危ない言語なの？」という疑問には、こう答えておきます。
サーバー側の言語が分かるサイトのうち約7割（69.3%）がPHP（W3Techs調べ）で、利用が多いぶん狙われやすく報告も多くなります。
広く使われているぶん、サポート中の版を使い、更新を続けることが大切な言語です。
2024年には別のPHPの脆弱性（CVE-2024-4577）を悪用した攻撃で、国内の複数組織にウェブシェルが設置される被害が確認されており、放置の代償は決して架空の話ではありません。
夜11時の一斉メンテナンスは、予告が機能し、各社が予防的に動いた結果でもありました。
次に同じ事態が起きる前に、自分のPHPの版を把握し、年末の12月31日の期限までに移行計画を立てておくことをおすすめします。
- PHP公式サイト（php.net）「News Archive – 2026」
- php.announceというPHP公式メーリングリストに投稿された「[ANNOUNCE] Upcoming Critical PHP Security Release」
- GitHub php/php-src 公式セキュリティアドバイザリ「RCE via OOM corruption（GHSA-w8hw-w9fx-j79w）」
- GitHub php/php-src 公式セキュリティアドバイザリ「RCE via stale global state（GHSA-6wmf-4rv5-p3rp）」
- IPA 情報処理推進機構「【事前準備のお願い】PHPのセキュリティリリース公開予定について」
- CERT-EU「Critical Vulnerabilities in PHP（Security Advisory 2026-018）」
- PHP公式サイト（php.net）「Supported Versions」
- PHP公式マニュアル「phpversion」
- Cloudflare Blog「Cloudflare deploys protections against php2shell vulnerability」
- Unit 42（Palo Alto Networks）が公開した解説記事「Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619」
- シックス・アパートが出した告知「[重要] PHP における脆弱性（CVE-2026-109618, CVE-2026-109619）への対応について」
- WordPress.org「Requirements」
- IPA 情報処理推進機構「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」
- W3Techs「Usage statistics of PHP for websites」
- Impress Watch「国内大手サービスで緊急メンテやサービス停止 PHP脆弱性で対策」
- Infoseekニュース（TBS NEWS DIG）「高市総理『大至急のお願いです』PHPの脆弱性に関する注意喚起受け 修正プログラム適用など対応呼びかけ」
- PR TIMES（セルバ）「PHPに深刻度『緊急』の脆弱性2件が発見。セルバがPHP緊急アップデート支援を10万円から提供開始」
- 窓の杜「『PHP』に“致命的”な脆弱性2件、日本時間21日深夜に緊急のセキュリティリリースへ【15時20分追記】」