PHPの重大脆弱性（PHP2Shell）とは｜影響と今すぐやること
PHP本体に見つかった2つの重大な脆弱性（PHP2Shell、CVE-2026-109618／109619）を速報で解説。サイトを見るだけの人は端末の操作は不要で、対応が必要なのはサイトの運営者です。修正版の番号と、バージョンの確かめ方を公式情報でまとめました。
「PHP2Shell」は、Webサイトを動かすプログラム言語PHPの本体に見つかった2つの重大な脆弱性（CVE-2026-109618、CVE-2026-109619）の呼び名です。悪用されると、ログインしていない第三者がサーバー上で任意のプログラムを実行できるおそれがあります。問題はサーバー側のPHPにあるため、サイトを見るだけの人がスマホやWi-Fiを切る必要はありません。対応が必要なのはサイトの運営者で、PHPを8.5.12／8.4.27／8.3.36／8.2.35以上に更新します。PHP 8.1以前には公式の修正リリースがないため、8.2以上への移行が必要です。
本記事は2026年10月22日（日本時間）時点の速報版です。PHP公式やIPA・JPCERT/CCなどの公式情報で確認できたことだけをまとめ、確認できない点は「未確認」としています。続報が入りしだい更新します。
何が起きたか
PHPの開発チームは2026年10月21日（日本時間21日23:00）、修正版のPHP 8.5.12・8.4.27・8.3.36・8.2.35を公開し、すべての利用者にすぐ更新するよう求めました。2つの脆弱性はどちらも認証なしでの遠隔からのコード実行につながりうるもので、深刻度はCVSS v4.0で**9.2（緊急）**です。
- CVE-2026-109618：メモリ不足（OOM）の処理で、リクエストのデータが作りかけのまま中断され、後片付けの処理がそれを正しいデータとして扱ってしまう
- CVE-2026-109619：あるリクエストの内部状態が、メモリを解放したあとも残る。同じワーカーが処理する次のリクエストが、その古い状態を使ってしまう
PHP公式によると、対象はPHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどWebのリクエストを処理するすべてのPHP環境で、危険がいちばん大きいのはmod_phpです。調査したWiz社は、PHP 5.4以降のほぼすべての版が影響を受け、WordPress・Drupal・Joomlaで認証なしのコード実行を実演したうえ、サーバーのメモリからほかの利用者のパスワードや認証トークン、APIキーを読み出せることも示したとしています。
米CISAは10月21日、公表時点では悪用を確認していないとしました。日本ではIPAとJPCERT/CCが10月22日に注意喚起を出し、対策の適用と侵害の有無の調査を呼びかけています。
影響を受ける人・受けない人
いちばんの分かれ目は、自分がPHPで動くサイトやサーバーを運営しているかどうかです。
| 立場 | 影響と、やること |
|---|---|
| サイトを閲覧するだけの人 | 弱点はサーバー側のPHPにあり、スマホ・パソコン・Wi-Fiを切っても対策にはならない。利用中のサービスがパスワードの変更などを案内したら、その告知に従う |
| 自分でサーバーを管理するサイト運営者 | 対象。PHPを修正版に更新する。更新できない間は、公開を止めることも検討する（CISA・IPA） |
| レンタルサーバー・WordPressの利用者 | WordPress本体の更新は不要で、予定もない（WordPress.org）。サーバー会社がPHPの更新や防御ルールの適用を進めている場合があるが、サーバー会社の案内を確認し、必要なら自分でPHPの版を切り替える |
| PHP 8.1以前を使っている人 | PHP公式の修正リリースはない。8.2以上へ移行する。OSやLTS（長期サポート）の提供元が独自に修正を出している場合があるので、提供元に確認する |
クラウドでも、PHPを入れたサーバーやコンテナを自分で用意している場合は自分で更新が必要です（Google Cloud）。
今すぐやること
運営者は、使っているPHPの系列（8.4系など）ごとに、次の版以上へ更新します。PHP公式の告知は「完全な回避策はなく、更新だけが安全な選択肢」としています。
| 使っている系列 | 修正済みの版 | 補足 |
|---|---|---|
| 8.5系 | 8.5.12以上 | |
| 8.4系 | 8.4.27以上 | |
| 8.3系 | 8.3.36以上 | |
| 8.2系 | 8.2.35以上 | 8.2系は2026年12月31日でサポート終了 |
| 8.1以前 | 公式の修正リリースなし | 8.2以上へ移行。ソースからビルドする人向けの最小限の修正は7.4・8.0・8.1に提供 |
- 今のバージョンを確かめる。WordPressなら管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で見られます（WordPress.org）。多くのサーバー会社は管理画面にも表示しています
- 修正版に更新する。Linuxのディストリビューションには修正が事前に渡されているため、OSの更新パッケージを確認します（PHP公式）。レンタルサーバーなら、サーバー会社の案内に沿ってPHPの版を切り替えます
- Webで動いているPHPの版を確かめ直す。コマンドラインのPHPと、Webサーバーが使うPHPが同じとは限りません
- 侵害の痕跡を調べる。JPCERT/CCは、不自然に長いPHPSESSIDのCookie、不審なmultipart形式のリクエストとその前後のメモリ上限エラーやHTTP 500、PHPのワーカーの異常終了や頻繁な再起動を確認するよう案内しています。痕跡がなくても、攻撃を受けていないとは断定できないとしています
PHP公式は設定による緩和策も示していますが、安全にはならないと明記しています。IPAとCISAは、更新や移行ができない場合は外部からのアクセスの遮断やサービスの一時停止を検討するよう求めています。
編集部の実機確認
Debian 13のサーバーで、版の確かめ方と更新の流れを試しました（2026年10月22日14:10〜14:12、日本時間）。脆弱性の再現や攻撃の試験は行っていません。
- 通常の配布元にあるのは8.4.24、セキュリティ更新の配布元には修正済みの8.4.27が届いていました（
apt-cache policy php8.4-cli） - 8.4.24を入れた状態で
php -vは「PHP 8.4.24」。次の1行は「要更新」と表示しました
php -r 'echo PHP_VERSION, " ", version_compare(PHP_VERSION, "8.4.27", ">=") ? "OK" : "要更新", PHP_EOL;'
apt-get install --only-upgradeで更新すると、php -vは「PHP 8.4.27」に。Web向けのPHP-FPMも/usr/sbin/php-fpm8.4 -vで「8.4.27 (fpm-fcgi)」を確認しました
公式の修正版の一覧どおりに版を判定する小さなスクリプトも作り、いくつかの版で試した結果です。
| 版 | 判定 |
|---|---|
| 8.5.11 ／ 8.4.26 ／ 8.3.35 ／ 8.2.34 | 未修正（各系列の修正版へ更新） |
| 8.5.12 ／ 8.4.27 ／ 8.3.36 ／ 8.2.35 | 修正済み |
| 8.1.34 ／ 7.4.33 ／ 5.6.40 | サポート終了。8.2以上へ移行 |
| 8.6.0 | 公式の対象表にない系列（開発版）。要確認 |
ただし、OSやLTSの提供元が、版の番号を変えずに修正だけを取り込むことがあります。その場合は番号だけでは判断できないので、提供元のセキュリティ情報を確認してください。
なぜ「AIが見つけた」が大事か
今回は、最先端のAIモデルが発見から修正の確認まで関わったと、関係者自身が説明しています。
- Wiz社は、自社の「Wiz Atlas」と、GoogleのGemini 4 Argon、OpenAIのGPT-5.6 Solを調査に使ったとしています。Google Cloudも、Gemini 4 Argonが発見、攻撃手順の開発、攻撃の検知、修正の確認に大きく貢献したと書いています
- 発見したのはWiz社だけではありません。PHPの開発を支えるPHP Foundationによると、2026年8月11日にセキュリティ企業Califの研究者とOpenAIが、それぞれ独立に同じ根本原因を報告し、Wiz社が8月24日に別の攻撃経路を報告しました。Califも「Calif、OpenAI、Wizが発見した」としています
- 弱点の芽は以前からありました。PHP Foundationは、2024年の外部監査で今回のメモリ不足の問題の兆しに気づいていたものの、具体的な攻撃方法が見つからなかったことや、修正方針を決めきれなかったことから対応が遅れたと説明し、「構造的な失敗だった」と認めています
Wiz社は、悪用には人間の研究者が現実的にこなせる限界に近い複雑な手順が必要だったが、最先端のAIモデルがその壁を大きく下げたと述べています。守る側が弱点を早く見つけられる一方、攻撃の準備にかかる手間も下がるということです。運営者にとっては、公表されたらすぐに更新できる体制がこれまで以上に大事になります。
未確認の点
10月22日時点で、次の各点は一次情報では確認できていません。確認でき次第更新します。
- 実際の悪用の有無（CISAは10月21日の公表時点で「確認していない」とした。その後の状況は未確認）
- 国内の主要なレンタルサーバー各社・WordPress向けホスティングの対応状況（本記事では各社の告知を確かめていない）
- 「NSAが警告した」という報道（NSAの公式サイトを取得できず、未確認）
- 国内の個別のサービスが停止・メンテナンスに入った理由（各サービスの告知を確認していない）
- OpenAIの発表の本文（openai.comは編集部の環境から取得できなかった。OpenAIの関与はPHP Foundation・Califの記載で確認）
- 2つのCVE番号と個々の不具合の対応づけ（Wiz社の記事の表とPHP公式の説明で書き方が異なる。本記事はPHP公式の説明に従った）
よくある質問
Q. スマホの電源やWi-Fiを切る必要はありますか？
必要ありません。今回の脆弱性は、Webサイトを動かすサーバー側のPHPにあり、閲覧する人の端末の弱点ではないため、端末やWi-Fiを切っても対策になりません。利用しているサービスがパスワードの変更などを案内した場合は、その告知に従ってください。
Q. 自分のサイトが影響を受けるか、どう確かめればよいですか？
使っているPHPのバージョンを確かめます。8.5系は8.5.12以上、8.4系は8.4.27以上、8.3系は8.3.36以上、8.2系は8.2.35以上なら修正済みです。WordPressなら管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認でき、サーバーを自分で管理しているならphp -vでも確認できます。コマンドラインとWebサーバーで別のPHPが動いていることもあるため、Web側の版も確かめてください。
Q. WordPressの更新は必要ですか？
WordPress.orgによると、この脆弱性はWordPress固有のものではなく、WordPress本体の更新は不要で、予定もありません。必要なのはサーバーのPHPの更新です。サーバー会社がPHPの更新を進めている場合もあるので、案内を確認してください。
Q. PHP 8.1以前を使っている場合はどうすればよいですか？
PHP 8.1以前はサポートが終わっており、PHP公式の修正リリースは出ません。8.2以上へ移行してください。OSや長期サポートの提供元が独自に修正を出している場合があるので、提供元に確認します。すぐに移行できない場合、IPAやCISAは外部からのアクセスの遮断やサービスの一時停止を検討するよう求めています。
Q. すぐに更新できない場合、設定で防げますか？
完全には防げません。PHP公式は設定による緩和策を示していますが、特定の攻撃経路を減らすだけで、安全にはならないとしています。更新だけが完全な対策です。
参考にした公式情報
本記事は次の公式情報に基づきます（いずれも2026年10月22日14:07〜14:09、日本時間に取得）。内容は更新されることがあるため、最新情報は各公式で確認してください。
- PHP公式：セキュリティ告知（2026年10月21日）（新しいウィンドウで開く）／8.3.36のリリース告知（新しいウィンドウで開く）／サポート中の版（新しいウィンドウで開く）
- PHP公式のGitHub：GHSA-w8hw-w9fx-j79w（新しいウィンドウで開く）（CVE-2026-109618）／GHSA-6wmf-4rv5-p3rp（新しいウィンドウで開く）（CVE-2026-109619）
- IPA（新しいウィンドウで開く）／JPCERT/CC（新しいウィンドウで開く）／JVN（新しいウィンドウで開く）／CISA（新しいウィンドウで開く）の注意喚起
- WordPress.orgの告知（新しいウィンドウで開く）／PHP Foundationのブログ（新しいウィンドウで開く）
- 発見・対応に関わった各社：Wiz Research（新しいウィンドウで開く）／Calif（新しいウィンドウで開く）／Google Cloud（新しいウィンドウで開く）
APIキーが漏れたときの対処はOpenCodeのAPIキー漏洩の記事に、社内でツールを安全に使うためのルールづくりは社内AI利用ルールの作り方にまとめています。
