PHPに重大な脆弱性（CVE-2026-109618・109619）：対象の確かめ方と更新の手順

この記事の要点

• 2026年10月21日、PHPに2件の重大な脆弱性（CVE-2026-109618・CVE-2026-109619）が公表されました。悪用されると、ログインなどの認証なしに、外部からサーバー上でプログラムを実行されるおそれがあります。
• WebサイトやシステムをPHPで動かしていれば、WordPressで作ったサイトも含めて対象です。PHP本体の欠陥のため、サイト側の対策では防げません。
• 修正版の8.5.12・8.4.27・8.3.36・8.2.35へ、できるだけ早く更新します。すぐに更新できないときの一時的な対策と、確認の点検表も紹介します。

PHPの公式サイト（php.net）は2026年10月21日、2件の脆弱性を修正した版を公開し、すべての利用者にすぐ更新するよう強く呼びかけました。深刻度はどちらも最も高い「Critical」で、共通の評価基準CVSS v4.0の値は10点中9.2です。公式によると、ApacheにPHPを組み込んで動かす方式（mod_php）では、認証のないリクエストを送るだけで、サイトのプログラムが動き出す前の段階から攻撃が成り立つことが確かめられています。

修正版と、公式のセキュリティ更新が続く期限は次のとおりです。

LinuxのディストリビューションのパッケージでPHPを入れている場合は、版の番号がこの表と違うことがあります（3章）。

1. 公表された2つの脆弱性

CVE-2026-109618は、メモリが足りなくなったときの処理の欠陥です。PHPは、使えるメモリの上限に達すると、その場で処理を打ち切ります。打ち切る時点によっては、内部のデータが準備の途中のまま残り、後片付けの処理がそれを正しいデータとして扱ってしまいます。ファイルのアップロードなどに使う形式（multipart）のリクエストを細工すると、PHPの設定上の上限を超えていないように見せたまま、メモリ不足を起こせることが分かっています。

CVE-2026-109619は、リクエストをまたいで古い情報が残る欠陥です。PHP-FPMやmod_phpなどでは、同じプロセス（ワーカー）が次々にリクエストを処理します。エラーで処理が途中で止まると、前のリクエストのために使ったメモリを解放した後も、そのメモリを指す内部の情報が残ることがあります。同じワーカーが次のリクエストを処理するとき、通常の準備が終わる前に、その古い情報を使ってしまいます。

公式の詳細によると、外部からのプログラムの実行まで確かめられたのは主にmod_phpですが、PHP-FPMでも、サイトの処理の条件がそろえばCVE-2026-109619で成り立つことが確かめられています。実行されるのは、WebサーバーでPHPを動かしているユーザーの権限です。サイトのファイルの書き換えや、データベースの情報の持ち出しにつながるおそれがあります。

2. 自社のサイト・システムが対象か確かめる

対象は、Webのリクエストを処理しているすべてのPHPです。公式は、PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedを挙げ、中でもmod_phpの危険が最も高いとしています。WordPressやEC-CUBE、Laravelなどで作ったサイトやシステムも、PHPで動いていれば対象です。WordPress本体やプラグインを更新しても直りません。

まず、サイトがどこで、どのバージョンのPHPで動いているかを確かめます。

WordPressで作ったサイトなら、管理画面の「ツール」→「サイトヘルス」→「情報」タブの「サーバー」で、PHPのバージョンが分かります。レンタルサーバーで8.1以前を選んでいる場合は、公式の修正がありません。サーバー会社の案内を確かめ、新しいバージョンへの切り替えを考えます。

3. 更新の手順

OSのパッケージで入れている場合

公式によると、Linuxのディストリビューションと、長期サポート（LTS）を提供する事業者には、修正が前もって渡されています。Ubuntu・Debian・AlmaLinuxなどの標準のパッケージでPHPを入れている場合は、各ディストリビューションのセキュリティ情報を確かめ、更新されたパッケージを入れます。

ディストリビューションのパッケージは、元の版に修正だけを取り込むことがあり、版の番号が8.3.36などにならない場合があります。番号ではなく、セキュリティ情報に載っている修正済みの版かどうかで判断します。

AlmaLinuxやRocky Linuxで、有志が運営するremiのリポジトリ（rpms.remirepo.net）からPHPを入れている場合は注意が必要です。公式は、このリポジトリには公表の当日に更新が出ないとして、ディストリビューションのパッケージへの切り替えか、ソースコードからのビルドを勧めています。

公式の配布物から入れている場合

公式のダウンロードのページから、修正版のソースコードを入手します。Windows版もこのページにあります。

更新したら再起動する

PHP-FPMやApacheは、パッケージを入れ替えても、再起動するまで古いプログラムのまま動き続けることがあります。更新したらPHP-FPM（mod_phpならApache）を再起動し、動いているプロセスが更新の後に起動し直したことを確かめます。

PHP 8.1以前を使っている場合

PHP 8.1以前は、公式の更新が終わっています。ディストリビューションやLTSの事業者が独自に修正を出していることがあるので、まず提供元に確かめます。今回は深刻さを考えて、公式のセキュリティチームが7.4・8.0・8.1向けの修正もソースコードで公開しましたが、自分でビルドする人などに向けた、今回の2件に対する最小限の修正です。

根本的な対策は、サポート中のバージョンへの移行です。8.2は2026年12月31日で公式の更新が終わるため、移行先は8.3以降を選びます。古いプログラムやプラグインは新しいPHPで動かないことがあるので、テスト用の環境で確かめてから切り替えます。移行が済むまでの間は、次の章の一時的な対策を入れておきます。

4. すぐに更新できないときの一時的な対策

公式は、完全な対策は更新だけだとしています。次の設定は、確かめられている攻撃の経路の一部を塞ぐもので、これで安全になるわけではありません。更新までのつなぎとして、サーバーの設定が分かる担当者が行います。

CVE-2026-109618（メモリ不足）への対策

• memory_limitを-1（上限なし）にします。サイトのプログラムから変えられない場所（PHP-FPMのプールやApacheの設定のphp_admin_value）で設定し、ほかの設定で上限が戻っていないかも確かめます。ただし、OSからメモリを確保できなかったときなど、別の形のメモリ不足では、まだ問題の処理に至ることがあります。
• 上限を外す代わりに、コンテナやcgroupでメモリの上限を設けます。できれば、上限を超えたワーカーだけが止まる形にします。RLIMIT_ASやRLIMIT_DATAでの代用はしません。メモリの確保の失敗を起こし、かえってこの欠陥の引き金になります。
• post_max_sizeを小さくします。ファイルのアップロードが無いサイトは8M、あるサイトは32Mが目安で、upload_max_filesizeはそれより小さくします。Webサーバーやプロキシの側でも、リクエストの大きさ（Content-Lengthが無いものも含む）、入力項目の数、ヘッダーの数などに上限を設けます。multipart形式の送信を使わないサイトなら、その形式のリクエストをPHPに届く前に止めます。

CVE-2026-109619（古い情報の再利用）への対策

• session.upload_progress.enabledを0にし、すべてのワーカーを再起動します。php.iniやPHP-FPMのプールなど、リクエストの読み込みより前に効く設定で行い、ini_set()や.user.iniには頼りません。公式の詳細では、この機能を使わないなら、更新した後も0にしておくのが無難だとしています。
• PHP 8.5では、fatal_error_backtracesを0にし、すべてのワーカーを再起動します。
• リクエストごとに当てる設定（Apacheの.htaccessのphp_valueや、nginxから渡すPHP_VALUEなど）のうち、無効な値や廃止予定の設定で警告が出るものを取り除きます。error_reportingやdisplay_errors、@で警告を隠しても効果はありません。
• 外からのリクエストで起こせる致命的なエラーや、実行時間の超過を直します。ファイルのアップロードや取り込み、コールバック、後片付けの処理も含みます。

5. 確認の点検表

次の項目に「はい」と答えられるかを確かめてください。

まとめ

• 今回の2件は、認証なしで外部からプログラムを実行されるおそれがある重大な脆弱性です。PHP本体の欠陥のため、サイト側の対策では防げません。
• 修正版か、ディストリビューションの修正済みのパッケージへ、できるだけ早く更新します。更新したらPHP-FPMやApacheを再起動します。
• PHP 8.1以前には公式の修正がなく、8.2も2026年末で更新が終わります。8.3以降への移行を計画します。

当社では、PHPで作られたWebサイトや業務システムの開発・保守と、サーバーの構築・保守を行っています。PHPのバージョンの確認や更新、古いバージョンからの移行、他社が作ったシステムの引き継ぎも、お気軽にご相談ください。詳しくはシステム開発とクラウドインフラ構築のページをご覧ください。

参考

• Security advisory: Critical remote code execution vulnerabilities, update now（php.net・英語）
• RCE via OOM corruption（CVE-2026-109618）（GitHub・英語）
• RCE via stale global state（CVE-2026-109619）（GitHub・英語）
• Downloads（php.net・英語）
• Supported Versions（php.net・英語）