PHPのセキュリティチームは、2026年10月21日（日本時間23時）、認証不要でリモートコード実行（RCE）につながる重大な脆弱性2件を修正するセキュリティリリースを公開しました（PHP公式ニュース）。通称「php2shell」です。国内では、予告の段階から、多くの組織が予防的にサービスを止めました（ピヨログの集計）。
この記事は、PHPを運用するエンジニア向けに、公式アドバイザリ（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）を軸にして、確認できた事実と、まだ確認できていない情報を分けて整理したものです。出典は、各記述のそばに示しています。状況が動いているため、今後2日間は毎日更新します。
| 項目 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| アドバイザリ | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| 公式の題名 | RCE via OOM corruption | RCE via stale global state |
| 深刻度 | CVSS v4.0 9.2（Critical） | CVSS v4.0 9.2（Critical） |
| ベクタ | AV:N／AC:H／AT:P／PR:N／UI:N | 同左 |
| 公開日 | 2026年10月21日 | 2026年10月21日 |
ベクタの読み方は、攻撃元がネットワーク、権限とユーザー操作は不要、ただし攻撃の複雑性は高く、成立に特定の条件が必要、ということです。公式は、エクスプロイトの移植性と信頼性は、PHPのビルド、拡張、フロントエンドの挙動、メモリ割り当ての配置に依存すると説明しています。「簡単に破られる」わけではありませんが、条件が整えば成立することは、mod_phpで実証されています（GHSA-w8hw-w9fx-j79w）。
PHPは、メモリ不足が起きると、longjmp()で現在の処理から抜けて、リクエストを中断します。ところが、一部の場面では、リクエスト用のメモリが完全に初期化される前に、この脱出が起こりえます。その結果、リクエストメモリが不正な状態のまま残り、そのあとのシャットダウン処理が、不正な状態を読み取ったり、それをもとに分岐したりします（GHSA-w8hw-w9fx-j79w）。
メモリ不足を起こす手段として、公式は、マルチパート解析の問題を挙げています。Content-Lengthが使えないマルチパートのリクエストは、最初のpost_max_sizeのチェックを通過できます。また、1つのパートに含められるヘッダーの数に制限がなく、PHP内部での表現にメモリを使うため、post_max_sizeの範囲内でも、通常のmemory_limitを使い切れます（GHSA-w8hw-w9fx-j79w）。
SAPIごとの状況は、GHSA-w8hw-w9fx-j79wの説明では、次のとおりです。
| SAPI | 公式の説明 |
|---|---|
| Apache mod_php | リクエストの起動に失敗しても、シャットダウン処理を無条件に呼び出す。アプリケーションのコードが動く前に発生する。RCEは検証済み |
| PHP-FPM | 起動失敗時は子プロセスを終了するため、不正な状態の利用は防がれる。起動後にOOMへ到達する場面はありうる。完全なFPM向けエクスプロイトは実証されていない |
| FrankenPHP | ソース分析では、mod_phpと同様にシャットダウン処理を無条件に呼ぶ。未検証 |
| LSAPI | FPMに似ている。アプリケーション固有のエクスプロイトはありそうだが、未検証 |
検証されたRCEは、PHPの既定の入力制限とメモリ制限のまま、複数ワーカーを使う、通常のpreforkのmod_phpに対するものです。
ワーカーが保持するグローバル状態（エラー、セッション、オブジェクト、拡張機能の状態など）が、リクエストの終了時に確実にリセットされず、解放済みのメモリを指したまま残ることがあります。同じワーカーが次に処理するリクエストが、通常の初期化の前にその古い状態を使うと、解放済みメモリの参照になります。公式は、影響として、認証不要のヒープのUse After Free、メモリ内容の漏えい、Webワーカーの権限でのRCEを挙げています（GHSA-6wmf-4rv5-p3rp）。
GHSA-6wmf-4rv5-p3rpが確認済みとしている経路は、次のとおりです。
fatal_error_backtracesが有効な場合の経路（mod_phpでRCEを確認）session.upload_progress）の経路。この機能は既定で有効で、session_start()の呼び出しは要りません（mod_phpとFPMの両方で検証）auto_detect_line_endings=1、PHP 8.3以降の旧assert.*、不正なmemory_limitです。error_reportingや@では防げません実証されているトリガーは、入力処理中のOOMです。
公式の説明（GHSA-w8hw-w9fx-j79w）では、OOM時のlongjmp()をやめています。代わりに、次のVMの安全な地点で起こす、穏やかな（ソフトな）OOMを使います。メモリ消費が第二の高い閾値に達した場合は、_exit()で即座に終了させます。PHPの通常のメモリ制限の機能は、維持されます。
公式アドバイザリ（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）で影響を受けるとされているのは、次のとおりです。
| 系列 | 影響を受ける | 修正版 |
|---|---|---|
| 8.5 | 8.5.12より前 | 8.5.12 |
| 8.4 | 8.4.27より前 | 8.4.27 |
| 8.3 | 8.3.36より前 | 8.3.36 |
| 8.2 | 8.2.35より前 | 8.2.35 |
| 8.1、8.0、7.4 | 公式の影響表には載っていない。最小限のソースバックポートが提供されている（PHP公式の告知） | バックポートのブランチ（後述） |
| 7.3以前 | PHPプロジェクトからの修正はない | なし |
「5.4.0まで遡る」という主張もあります。これは、脆弱性を報告した側（Calif）の主張として、Tenableの解説が伝えているもので、公式アドバイザリでは確認されていません。
確認のコマンドは、次のとおりです。
php -v # CLIのバージョン（Webで使うバージョンと一致するとは限らない）
php-fpm -v # PHP-FPM
apachectl -M | grep -i php # mod_phpが読み込まれているかCLIのバージョンと、Webを処理しているPHPが、別物の場合があります。Webから使われている方を確認してください（FPMのプールやコンテナを含みます）。Dockerなら、使っているイメージでdocker run --rm <イメージ> php -vを実行します。
ディストリビューションのパッケージは、バージョン番号を上げずに、修正だけを取り込むことがあります。その場合は、変更履歴で確認します。パッケージ名は、環境に合わせてください。
# Debian / Ubuntu
apt changelog php8.4-cli | grep -i -m1 CVE-2026-109618
# RHEL / Rocky / Alma
rpm -q --changelog php | grep -i -m1 CVE-2026-109618脆弱なのは、PHPの実行環境そのものです。WordPressやLaravelなどのアプリケーション側を更新しても、PHPが修正版でなければ、対処になりません。逆に、PHPを更新すれば、アプリケーション側の修正は、この件では必須ではありません。
なお、WordPress、Drupal、Joomlaなどで、認証なしでRCEが成立することを実証した、という報告があります（Wiz、Califなど。Huntress、Tenableが伝えています）。これは第三者による報告で、公式アドバイザリでは確認していません。
主なディストリビューションの状況です。DebianはDebian Security Trackerで、そのほかはピヨログの集計で確認した、10月22日朝の時点の状況です。更新は進んでいるので、必ず自分の環境のアドバイザリを確認してください。
| ディストリビューション | 状況 |
|---|---|
| Debian | trixieのphp8.4は8.4.27-1~deb13u1（DSA-6574-1）、bookwormのphp8.2は8.2.35-1~deb12u1（DLA-4848-1）で修正済み。forky・sidのphp8.4は未修正（Debian Security Tracker） |
| Ubuntu | USN-8948-1。26.10、26.04 LTS、24.04 LTS、22.04 LTSは修正済み。20.04と18.04はUbuntu Pro、16.04と14.04はLegacy Supportで提供 |
| Arch Linux | php 8.5.12-1、php-legacy 8.3.36-1で修正済み |
| Gentoo | GLSA 202610-02で修正済み |
| Alpine Linux | edgeのphp85、php84、php83が修正済み |
| Amazon Linux | AL2023のphp8.2〜8.4は修正済み。php8.5はCVE-2026-109618のみ修正済み（ALAS2023-2026-3304）で、残りは修正待ち |
| AlmaLinux、Rocky Linux、Oracle Linux | 修正済み（展開中を含む） |
| RHEL | RHSB-2026-013。8、9、10のphpは、一部が提供され、残りは進行中 |
| Remiリポジトリ | PHP公式の告知は、10月21日時点で更新がないとして、ディストリビューション版への切り替えか、ソースからのビルドを案内 |
Dockerの公式イメージは、docker-libraryのバージョン定義（versions.json）が、4つの修正版（8.5.12、8.4.27、8.3.36、8.2.35）に更新されていることを確認しました。ただし、イメージ自体の配信は、ここでは確認していません。pullし直して、php -vで確認してください。Windows版は、PHP公式の告知によると、公式のダウンロードページに掲載されています。
更新したあとは、すべてのPHPワーカー（FPMのプール、Apacheのワーカー）を再起動してください。設定の反映だけでは、古いワーカーが残ることがあります。
以下は、PHP公式の告知と、GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rpにある暫定対処です。どれも、安全にはなりません。更新までの、時間稼ぎとして使ってください。
CVE-2026-109618の暫定対処として、memory_limitを-1にして、アプリケーション側で上書きできない形にします。
# Apache（mod_php）
php_admin_value memory_limit -1; PHP-FPMのプール設定
php_admin_value[memory_limit] = -1CVE-2026-109619の暫定対処として、セッションのアップロード進捗を無効にします。リクエストの解析の前に適用される場所（php.ini、FPMのプール、サーバー設定）に書きます。ini_set()や.user.iniは、当てにできません。PHP 8.5では、fatal_error_backtracesも無効にします。
; php.ini
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; PHP 8.5のみ; PHP-FPMのプール設定でも指定する場合
php_admin_flag[session.upload_progress.enabled] = off変更したら、すべてのワーカーを再起動します。変更後に、プールやディレクトリ、アプリケーション側で、有限のメモリ制限が復活していないかも確認してください。
注意点が3つあります。
memory_limit = -1は、完全な緩和策ではありません。基盤のメモリ割り当て（mmap()など）が失敗すると、同じ経路に到達しえます。また、1つのリクエストが、サーバーのメモリを使い切るおそれが増えるため、次の前段の制限と必ず併用してくださいRLIMIT_ASとRLIMIT_DATAによる制限（ulimit -v、systemdのLimitAS=やLimitDATA=など）は、使わないでください。上限に達したときにmmap()が失敗して、脆弱な経路を引き起こすため、とPHP公式の告知が述べていますPHP公式の告知は、修正の代わりにはならないが、リスクを下げる設定として、次を挙げています。
post_max_sizeを控えめにする（ファイルのアップロードが不要なら8M程度、必要でも32M程度。upload_max_filesizeは、それより小さく）Content-Lengthのないリクエストにも適用するmax_input_nesting_levelを下げ、入力変数の数、マルチパートのパート数、パートごとのヘッダー数、アップロード数を制限するCloudflareのCTOは、既知の攻撃経路に対するWAFのルールを、無料プランを含む全顧客に展開したと発表しています。ただし、同社は応急処置として位置づけており、Cloudflareを経由したトラフィックにしか効きません（Tenable、ピヨログの集計）。
PHP公式の告知によると、PHPのセキュリティチームは、ソースからビルドする場合や、LTSベンダーを使えない場合のために、7.4、8.0、8.1向けの最小限のバックポートを、次のブランチで提供しています。
PHP-7.4-CVE-2026-109618-109619PHP-8.0-CVE-2026-109618-109619PHP-8.1-CVE-2026-109618-1096197.3以前には、PHPプロジェクトからの修正はありません。ベンダーのLTS（Ubuntu Proなど）を使うか、サポート中のバージョンへ移行する必要があります。なお、PHP 8.2は、PHP公式の告知によると、2026年12月31日にEOLを迎えます。今回の更新を、移行の計画を立て直す機会にしてください。
修正版を入れても、公開から更新までの間に侵入されていれば、侵害は残ります。セキュリティベンダーのHuntressは、次のような兆候の監視を勧めています。
php-fpm、php-cgi、httpd、apache2）が、シェル（sh、bash、cmd.exe、powershell.exe）やインタプリタ（python、perl）、ダウンロード系のツール（curl、wget、nc、certutil.exe）を起動していないか/dev/tcp/、fsockopen、mkfifoといったリバースシェルの典型的なパターンがないかwhoami、id、uname -a、ipconfigのような偵察コマンドが実行されていないかHuntressは、IOC（侵害の痕跡の一覧）は、現時点では「未定」としています。また、PHPのアドバイザリは、log_errors、error_log、error_reporting=E_ALLでのログ監査を勧めつつ、ログに出ないことは安全の証明にならない、と注意しています。
私見ですが、PHP-FPMのログに、ワーカーが「signal 11（SIGSEGV）で終了した」という記録が突然増えている場合は、攻撃の試行の可能性があります。公式のIOCではありませんが、点検の手がかりにはなります。
侵害が疑われる場合は、ログを保全したうえで、そのサーバーを隔離してください。PHPのワーカーから見える認証情報（データベースのパスワード、APIキー、トークンなど）は、すべて入れ替えが必要になります。
悪用については、情報が割れています。確度とあわせて整理します。
| 項目 | 内容 | 確度 |
|---|---|---|
| 攻撃の試行 | watchTowrは、ハニーポット網で、両方の脆弱性への悪用の試行を観測したと報告（件数などの詳細は非公開）。Cloudflare CTOは、「早期の攻撃が出始めている」と投稿（ピヨログの集計、Tenable） | 第三者の報告 |
| 成功した侵害 | 10月22日朝の時点で、侵害の成功や被害の規模を示す公的な報告は確認できていない。Huntressは、米東部時間10月21日16時30分の時点で、パートナー環境での悪用を観測していない | 確認されていない |
| 公的機関 | CISAは、発表の時点で悪用は観測していないとした。KEV（悪用が確認された脆弱性のカタログ）には、10月22日朝の時点で未登録。オランダのNCSC-NLも、公開PoCはあるが、活発な悪用は未確認とした（ピヨログの集計） | 一次情報は未確認 |
| 公開されたPoC | PHP Foundationは、公開後に出回ったコードに、機能するエクスプロイトは確認できなかったと述べている。一方で、Wizは、WordPress、Drupal、Joomlaでの認証不要のRCEを実証したと報告（Tenable、Huntress） | 割れている |
| 影響バージョン | 公式の影響表は、8.2〜8.5。「5.4.0まで遡る」は、Califの主張（Tenable） | 公式と第三者で違う |
| CVSS | 流出した時点では10.0と報じられたが、公式は9.2（ピヨログの集計、GHSA-w8hw-w9fx-j79w） | 公式の値は9.2 |
古い情報には、注意してください。流出の直後に書かれた記事には、「修正版はまだない」「影響範囲は5〜8系」といった、現在の公式情報と合わない記述が残っているものがあります。
時刻は、日本時間です。出典は、ピヨログの集計です。修正版の公開は、PHP公式ニュースでも確認できます。
| 日時 | 出来事 |
|---|---|
| 2024年 | 外部監査（QuarkslabがOSTIF経由で実施）の過程で、OOMの問題の最初の兆候が見つかるが、攻撃経路は見つからず、修正方針の合意も難航 |
| 2026年7月30日 | Califが、PHPの監査を開始 |
| 8月11日 | Califと、独立してOpenAIが、同じ根本原因のRCEを報告 |
| 8月24日 | Wizが、追加の攻撃経路を報告 |
| 9月18日 | OpenAIが、追加の攻撃経路を報告 |
| 10月21日 0時ごろ | 2件のCVE番号が、誤った公開時刻と、誤ったCVSS 10.0とともに出回る（技術的な詳細は漏れていないとされる） |
| 10月20日（UTC） | PHPが、10月21日14時（UTC。日本時間23時）に重大なセキュリティリリースを行うと予告（当初予定は翌日で、1日前倒し） |
| 10月21日 3時26分 | watchTowrが、エンバーゴ下のRCEの情報が漏えいしたと投稿 |
| 10月21日 16時43分 | CloudflareのCTOが、WAFルールを全顧客に展開したと投稿 |
| 10月21日 22時34分 | GitHubのアドバイザリ2件が公開 |
| 10月21日 23時 | 修正版（8.5.12、8.4.27、8.3.36、8.2.35）が公開 |
| 10月22日 朝 | さくらインターネット、エックスサーバーなどが、サーバー側のPHPの更新を完了（後述） |
予告を受けて、10月21日の夜に、国内では多くの組織が、予防的にサービスを止めました。ピヨログの集計（10月22日朝の時点）では、211組織にのぼります。官公庁、自治体、金融機関、ゲーム、EC、動画・配信、レンタルサーバー事業者などです。日経クロステックも、さくらインターネットの一部機能の停止や、Cygames、pixivの緊急メンテナンスを報じています。
PHPを使うレンタルサーバーは、ピヨログの集計によると、次のように対応しています（10月22日朝の時点。必ず各社の告知を確認してください）。
共用のサーバーを使っている場合、PHPの更新は、事業者側の作業です。ただし、古いPHPのバージョンを選んでいると、更新の対象外になることがあります。コントロールパネルで、使っているPHPのバージョンを確認してください。
国内の公的機関では、IPAと国家サイバー統括室が、10月21日に、リリースへの事前準備を呼びかけています（ピヨログの集計）。
毎日の更新では、次の点を追います。
PHP環境の洗い出しや、更新、侵害の点検でお困りの方は、下記よりお問い合わせください。
43 W 33rd St, #202, New York, NY 10001
Phone: +1 (848) 281-7853
Email: info@supersonicdesign.com
