【緊急】2026年10月発表のPHPの脆弱性｜サーバー乗っ取りの危険性と対処法（php2shell）

2026年10月21日の日本時間23時、PHPの開発チームはPHP 8.5.12・8.4.27・8.3.36・8.2.35を緊急のセキュリティリリースとして公開しました。8.5.12の公開告知は、次のように更新を呼びかけています。

This is a security release fixing two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619) that can allow unauthenticated remote code execution. All PHP 8.5 users are strongly encouraged to update immediately. There are no complete mitigations, updating is the only safe choice.

意訳

ログイン不要で外部からプログラムを実行されうる、深刻度が緊急（Critical）の脆弱性2件（CVE-2026-109618、CVE-2026-109619）を直すセキュリティリリースです。PHP 8.5の利用者は、すぐに更新することを強く勧めます。完全な緩和策はなく、安全な選択肢は更新だけです。

PHP公式「PHP 8.5.12 Released!」（2026年10月21日）

8.4.27・8.3.36・8.2.35の公開告知も、同じ趣旨で更新を呼びかけています。発見した研究者らは、この2件をまとめて「php2shell」と呼んでいます。PHPは、フレームワークを使わない自社開発のWebアプリから、LaravelやSymfonyなどのフレームワーク、WordPressなどのCMSまで、多くのWebサイトの土台になっている言語です。W3Techsの集計では、サーバー側の言語を判別できたWebサイトの69.3%がPHPを使っています（2026年10月時点）。

01.根本原因と原因のモジュール

php2shellの根本原因は、Zend Engineのエラー処理にあります。Zend Engineは、メモリの上限（memory_limit）への到達などの致命的なエラーが起きると、決まった地点まで一気に処理を戻します。この処理はbailoutと呼ばれます。

エラー処理で壊れたデータが残る仕組み

2件の違いは、壊れた状態を使う処理にあります。表の深刻度は、脆弱性の危険度を10点満点で表す国際的な指標（CVSS）の値です。

PHPのセキュリティチームは、セキュリティ情報の共有に使われるメーリングリスト（oss-security）で、それぞれの原因を説明しています。CVE-2026-109618の告知は次のとおりです。

PHP uses longjmp() to abort request handling on out-of-memory (OOM) errors. An allocation failure can interrupt initialization while incomplete request state is already reachable. Request shutdown may then access this invalid state, potentially allowing remote code execution.

意訳

PHPは、メモリ不足（OOM）のエラーが起きると、longjmp()でリクエストの処理を打ち切ります。メモリの確保に失敗すると、初期化が途中で打ち切られることがあります。そのとき、作りかけのリクエストのデータが、すでにほかの処理から参照できる状態になっています。その後、リクエストの終了処理がこの不正なデータに触れ、リモートでのコードの実行につながるおそれがあります。

PHPセキュリティチーム「CVE-2026-109618: PHP 8.2–8.5 RCE via OOM corruption」（2026年10月21日）

longjmp()は、C言語で決まった地点まで一気に処理を戻す仕組みで、上で触れたbailoutの実体です。続くCVE-2026-109619の告知は、リクエストをまたいで残る情報を原因に挙げています。

PHP maintains global state that temporarily points into request memory. In some scenarios, this state is not correctly reset, or is repopulated after being reset. Once the request memory is freed, a subsequent request handled by the same worker may access the stale state before normal initialization replaces it, causing a use-after-free and potentially allowing remote code execution.

意訳

PHPは、一時的にリクエスト用のメモリを指す情報を、PHP全体で保持しています。場面によっては、この情報が正しく消されなかったり、消したあとに再び設定されたりします。リクエスト用のメモリが解放されたあと、同じワーカーが処理する次のリクエストが、通常の初期化で上書きされる前にこの古い情報を使うことがあります。その結果、解放済みのメモリの使用（use-after-free）が起き、リモートでのコードの実行につながるおそれがあります。

PHPセキュリティチーム「CVE-2026-109619: PHP 8.2–8.5 RCE via stale global state」（2026年10月21日）

CVE-2026-109619のセキュリティ勧告によると、コードの実行まで確かめられた経路は2つです。PHP 8.5の致命的なエラーの呼び出し履歴（バックトレース）を残す処理と、セッションの処理です。

原因のモジュールと修正の範囲

PHP 8.5.12の修正コミットは、Zend Engineを中心に、リクエストの受け付けやセッションなど多くのモジュールに手を入れる大きな修正です。コミットのメッセージは、修正の方針を次のように記しています。

Avoid state corruption via bailout
- Replace bailout on OOM with UnwindExit
- Properly reset various globals that may be accessed during startup

意訳

bailoutによる内部の状態の破損を防ぐ

• メモリ不足のときのbailoutを、UnwindExitに置き換える
• リクエストの開始処理で使われうる各種のグローバル変数を、正しく初期化し直す

php-srcの修正コミット「Avoid state corruption via bailout」（2026年10月18日）

UnwindExitは、例外と同じ仕組みで、呼び出し元へ順に戻りながら処理を終える方式です。グローバル変数は、PHP全体で保持する情報を指します。この方針に沿って書き換えられた、主な変更先は次のとおりです。

2段階の上限のうち、2つ目の上限は新しい設定（memory_hard_limit_percent）で決まります。修正コミットのソースコードでは、既定値はmemory_limitが1GB以下ならその2倍、1GBを超えるなら1GBを足した値です。

サポートが終わった8.1向けの最小限の修正は、サポート中の系の修正と同じ範囲には及びません。古いバージョンほど、8.3以降への移行を優先してください。

02.想定される被害と悪用状況

脆弱性の深刻度を表す目盛り（CVSS）で、php2shellは、PHPの開発チームとNVDの評価では最も上の緊急の段階に入ります。Red Hatの評価も、その1つ下の重要の段階です。

情報が抜かれる攻撃の流れ

研究者らが実証した攻撃は、大きく2通りあります。どちらもログインは要らず、外部からリクエストを送るところから始まります。

Wizの公表によると、2つの流れの違いは次のとおりです。

• 流れ1：サーバーは、解放済みのメモリの中身を、応答のCookie（セッションID）に入れて返します。中身には、ほかの利用者のリクエストやサーバー自身のパスワード・認証トークン・APIキー・証明書が含まれえます。サーバーでプログラムを動かさずに、情報だけを抜ける点が特徴です
• 流れ2：流れ1で抜いたメモリの情報も使い、壊れたメモリを利用して、攻撃者のプログラムをWebサーバーの権限で動かします。Wizは、WordPress・Drupal・Joomlaで、ログイン不要のコードの実行まで実証しました
• どちらも：アプリ側のコードに欠陥がなくても攻撃は成立しうるため、画面に文字を表示するだけの単純なページでも、修正前のPHPで動いていれば対象になります

公表前の流出と攻撃の試み

PHP Foundationによると、流出のあと、発見者の1社が攻撃の実演動画を誤って公開し、その複製がSNSで出回りました。同財団は、これが攻撃コードの開発を早めたとみています。一方で、修正版の公開時点では、実際に動く攻撃コードは確認していないとしています。流出の経緯は07章の年表で整理しています。

Fastlyは、公表前から実際の攻撃が始まっていた形跡があるとしています。ただし、攻撃の通信が観測されていることと、攻撃が成功したことは別の事実です。

米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、日本時間10月22日朝の時点で、今回の2件を既知の悪用済み脆弱性（KEV）カタログに載せていません。

ただし、カタログへの掲載は実際の悪用を確認してからの判断です。攻撃の通信がすでに観測されている以上、掲載を待たずに更新するのが適切です。攻撃に使う通信の中身は、悪用を助けかねないため本記事では扱いません。

03.影響を受ける範囲

バージョン別の対象と修正版

サポート終了日は、PHP公式のサポート対象バージョンの一覧に基づきます。表の番号はPHP公式の番号で、OSが配布するPHPは番号の付け方が違うため、04章の方法で確かめてください。

CVEの公式記録が対象として挙げるのは、PHP公式がサポートを続けている8.2〜8.5です。ただし、これは8.1以前が安全という意味ではありません。

Google Cloudは、PHP 5.4以降の修正前のバージョンが影響を受けると説明しています。古いバージョンほど、修正の手段が限られる点に注意が必要です。

古いバージョンのPHPは、今も広く使われています。W3Techsのバージョン別の集計とPHP 8系の内訳を掛け合わせると、バージョンを判別できたPHPのサイトの約半数（48%）が8.1以前でした（2026年10月21日時点）。

サーバー構成別のリスク

PHPをWebサーバーにどうつないでいるか（構成）によって、攻撃の成立しやすさは変わります。PHP公式のセキュリティ勧告は、対象となる構成を次のように示しています。

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

意訳

リスクがあるのは、Webリクエストを処理するすべてのPHPです。PHP-FPM、mod_phpを組み込んだApache、php-cgi、FrankenPHP、LiteSpeedを含みます。私たちは、mod_phpのリスクが最も高いと考えています。アプリのコードが動く前に、ログインしていないリクエストで攻撃を起こせる手法が実証されています。

PHP公式「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）

構成による差について、Red Hatは、同社のLinuxの標準構成はmod_phpではなくPHP-FPMで、コードの実行まで至るのは実際には難しいと評価しています。一方で、mod_phpを既定の設定で動かす環境はリスクが高いとしています。攻撃が難しい構成でも、更新が要らなくなるわけではありません。

アプリの作り方を問わない影響

原因がPHP本体にあるため、アプリの作り方を問わず、修正前のPHPで動いていれば対象です。発見者の1社であるCalifは、ログイン前の段階でのコード実行を、次のようなソフトウェアで確認したと公表しています。

• フレームワーク：Laravel・Symfony
• CMS：WordPress・Drupal・Joomla・MediaWiki
• 業務アプリ・管理ツール：Magento・WHMCS・Nextcloud・Roundcube・phpMyAdmin

フレームワーク・CMS・業務アプリを問わず確認されている点が、PHP本体の問題であることを示しています。作り方ごとに、PHPの更新に加えて確認したいことは06章で整理しています。

04.PHPのバージョンの確認方法

php -v
php-fpm -v   # PHP-FPM の場合。Debian・Ubuntu では php-fpm8.3 -v のように番号が付く

php -v で表示されるのは、コマンドから使うPHPのバージョンです。Webサイトを動かすPHP（PHP-FPMやmod_php）が別のバージョンのこともあるため、両方を確かめると確実です。

UbuntuやDebianなどOSが配布するPHPは、PHP公式とは別に修正を取り込むため、番号だけでは判断できません。たとえばUbuntuの24.04では、PHP 8.3の修正済みのパッケージは「8.3.6-0ubuntu0.24.04.13」です。

この場合、先頭の「8.3.6」は修正版の8.3.36より小さく見えますが、修正は入っています。OSのパッケージは、提供元の告知にある修正済みの番号以降かどうかで判断してください。

05.実行環境別の更新手順

レンタルサーバー・クラウドの場合

レンタルサーバーでは、PHP本体の更新は事業者が行います。事業者の障害・メンテナンス情報で、修正版の適用状況を確かめてください。

たとえばKAGOYAは10月21日、レンタルサーバープランのPHP 8.2〜8.5系を順次更新する予定とし、ほかのプランやバージョンは対応方針を調整中と案内しています。

管理画面で8.1以前を選んでいる場合は、事業者の修正が届かないことがあります。8.3以降へ切り替えるのが確実ですが、古いコードやプラグインが動かなくなる場合もあるため、バックアップを取ってから進めてください。

クラウドでは、提供元が更新する範囲と自社の範囲を確かめます。Google Cloudの場合、App Engineのスタンダード環境（PHP 8.2以降）は自動で更新されます。自社で用意したコンテナは、修正版のPHPでの作り直しと再デプロイが必要です。

自社でサーバーを管理している場合

OSが配布するPHPを使っているなら、OSのパッケージを更新します。DebianとUbuntuは10月21日に修正済みのパッケージを公開し、Red Hatも一部の修正を公開済みで残りを準備中としています。

更新したあとは、PHP-FPMやApacheの再起動が欠かせません。再起動しないと、更新前のPHPがそのまま動き続けるためです。ソースコードからPHPを組み立てている場合は、修正版のソースで組み立て直してから再起動します。

RHEL系のサーバーで、有志が運営するremiのリポジトリからPHPを入れている場合は、修正が届くまで時間がかかることがあります。入手先の切り替えは、すぐに更新できない場合の緩和策の節で整理しています。

製品・機器に組み込まれたPHP

製品や機器に組み込まれたPHPについて、IPA（情報処理推進機構）は修正版の公開前に出した注意喚起で、次のように呼びかけています。

PHPは、ウェブアプリケーションだけでなく、ソフトウェア製品やネットワーク機器などの内部でも利用されている場合があります。製品や機器の内部でのPHPの利用状況は、利用者側では把握できない場合があります。まずは、製品のマニュアルや、開発元・提供元が公開するセキュリティ情報などをご確認ください。

IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（2026年10月21日）

こうした製品では、利用者がPHPだけを入れ替えられないことが多いため、提供元の修正を待って適用することになります。PHPの利用がわかっている製品は、提供元の告知を追い、修正が出たらすぐに当てられるよう準備しておきましょう。

すぐに更新できない場合の緩和策

検証や社内承認に時間がかかる場合は、更新までの間、設定の変更と攻撃通信の遮断で被害の可能性を下げます。設定の変更について、PHP公式の勧告は位置づけを次のように明記しています。

If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

意訳

すぐに更新できない場合：完全な解決策は更新だけですが、次の対策で、特定の攻撃経路から攻撃を受けにくくできます。ただし、これらの対策でPHPが安全になるわけではありません。

PHP公式「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）

勧告が挙げる主な設定と、それぞれの注意書きは次のとおりです。

なお、同じ勧告は、有志が運営するremiのリポジトリには公表当日の更新が出ないとしています。remiを使っている場合は、OSのパッケージへ切り替えるか、ソースから組み立てるよう勧めています。

攻撃通信の遮断には、CDN・WAFの各社が提供する対策ルールを使えます。Cloudflareは無料プランを含むWAFで、日本時間10月21日の正午ごろから自動で適用しています。

メモリ上限まわりの詳しい条件は、CVE-2026-109618のセキュリティ勧告にまとまっています。緩和策は時間を稼ぐためのもので、更新を先送りする理由にはなりません。

06.開発形態別の追加の対応

フルスクラッチで開発したアプリ

フレームワークを使わずPHPで書いた自社のWebアプリも、修正前のPHPで動いていれば対象です。アプリのコードを直しても根本的な解決にはならないため、まずPHPを更新します。

そのうえで、CVE-2026-109619のセキュリティ勧告が残りのリスクを減らす手段として挙げている次の点を、自社のコードと設定で見直します。

• 攻撃者が外部から致命的なエラーを起こせる箇所をなくす。アップロード・インポート・エラーページ・終了処理・デストラクタ・シリアライズなど、通常のページ表示以外の経路も見直す
• 実行時間切れ（Maximum execution time exceeded）も致命的なエラーと同じように扱い、攻撃者が狙って起こせないようにする
• リクエストごとに適用する設定（.htaccess の php_value など）より、php.iniやFPMのプール設定など起動時に読まれる設定を使い、廃止済みの設定を外す。error_reporting の変更や@による抑止、display_errors の無効化でエラーを隠しても、この脆弱性は防げない
• アップロード進捗の機能（session.upload_progress）は、使っていなければPHPの更新後も止めておくことを検討する

Califによると、セッションの読み込み（session_start()）や unserialize() のように、保存したデータを元に戻す処理も攻撃の経路になります。データの中身が正当でも、攻撃者にメモリの使われ方を操作されると、その処理が途中で打ち切られることがあります。こうした処理を使うアプリほど、更新を急いでください。

フレームワークで作ったアプリ

LaravelやSymfonyなどのフレームワークを最新にしても、PHPが古ければ対象のままです。フレームワークは、PHP本体が受け取ったリクエストを処理する上の層にあたるためです。

コンテナで動かしている場合は、元になるPHPのイメージを修正版に上げてから作り直し、再デプロイします。本番だけでなく、開発・検証環境やCIで使うイメージのPHPもそろえておくと、環境ごとの食い違いを防げます。

WordPressなどのCMS

WordPress・Drupal・JoomlaなどのCMSも、本体やプラグインの更新では直りません。CMSの管理画面でPHPのバージョンを確かめ（04章）、レンタルサーバーを使っているなら事業者の対応状況を確認します（05章）。

なお、2026年7月に見つかったwp2shellはWordPress本体の脆弱性で、対処の方法も今回とは別です。そちらの内容と対応手順は、別記事で整理しています。あわせてご覧ください。

07.発見の経緯とタイムライン

PHP Foundationによると、兆候が見つかったあとも修正方針を決めきれず、作業は数か月にわたって止まっていました。同財団はこの遅れを、意思決定の仕組みと人手不足による構造的な問題だったと認めています。

PHP公式の事前の告知は、詳細が公開されたり実際の悪用が見つかったりすれば、さらに前倒しする可能性があるとしていました。

今回の発見では、AIが大きな役割を果たしています。Wizは、欠陥のあるコード自体は10年以上前からあり、攻撃に使える形にするには複雑な手順の積み重ねが必要だったと説明しています。最新のAIモデルがその手間を大きく減らしたというのが同社の見方です。

8月11日に報告したOpenAIは、コードの脆弱性を見つけて検証するエージェント「Codex Security」の提供元です。仕組みと使い方は別記事で整理しています。あわせてご覧ください。

08.よくある質問（FAQ）

09.まとめ

php2shellは、PHP本体のZend Engineが、メモリ不足などの致命的なエラーで処理を打ち切るときの後片付けに潜んでいた2件の脆弱性です。ログイン不要でのサーバーの乗っ取りにつながり、自社開発・フレームワーク・CMSのどれであっても、アプリの更新では直りません。

まずは自社で動かしているPHPのバージョンを確かめ、レンタルサーバーなら事業者の対応状況を、自社管理ならOSのパッケージの更新と再起動を確認しましょう。8.1以前を使っている場合は、この機会に8.3以降への移行まで進めると、次のサポート終了にも慌てずに済みます。

PHPのような実行環境の更新は、開発と運用の体制が整っているかどうかで対応の速さが変わります。自社だけで更新状況を追い続けるのは、担当者が少ない場合はとくに負担になりがちです。弊社では、AIをフル活用した開発支援から運用保守までを伴走支援しています。