【至急】PHPに重大な脆弱性2件、修正版8.5.12などを公開｜IPAも注意喚起、対象と対処法

ウェブサイトやウェブサービスで広く使われているプログラミング言語「PHP」に、認証なしで遠隔からプログラムを実行されるおそれのある重大な脆弱性が2件見つかりました。PHPの開発チームは10月21日、修正版のPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開し、すべての利用者に直ちに更新するよう呼びかけています。

IPA（情報処理推進機構）も同日、修正版の公開に備えた事前準備を求める注意喚起を出しました。この記事では、公式発表をもとに、脆弱性の概要、影響を受ける環境、更新先のバージョン、すぐに更新できない場合の緩和策を整理します。

何が起きたか（時系列）
2つの脆弱性の概要
影響を受ける環境
更新先のバージョン
すぐに更新できない場合の緩和策
1. 1件目（CVE-2026-109618）への緩和策
2. 2件目（CVE-2026-109619）への緩和策
サイト運営者・利用者がやるべきこと
公表内容から読み取れること（考察）
関連記事
まとめ
出典

何が起きたか（時系列）

日時（日本時間）	出来事
10月20日	PHPの開発チームが、重大な脆弱性2件のセキュリティリリースを10月21日23時（14:00 UTC）に公開すると予告。深刻度はいずれもCVSS v4.0で9.2
10月21日	IPAが「事前準備のお願い」として注意喚起を公表
10月21日	予告の23時より前に修正版が公開され、セキュリティ勧告も掲載

PHPの開発チームは予告の段階で、詳細が外部に漏れたり、実際の悪用が確認されたりした場合は公開を早める可能性があるとしていました。今回、修正版は予告時刻より前に公開されています。前倒しの理由は公式発表では説明されていません。

2つの脆弱性の概要

今回修正されたのは次の2件です。どちらも、悪用されると攻撃者が任意のプログラムを実行できる「リモートコード実行（RCE）」につながります。

CVE番号	名称	概要
CVE-2026-109618	RCE via OOM corruption	メモリ不足（OOM）の処理でリクエストの処理が中断されたとき、初期化途中の内部データが不正な状態のまま残り、後片付けの処理がそれを正しいデータとして扱ってしまう
CVE-2026-109619	RCE via stale global state	あるリクエストが使っていた内部の状態が、メモリ解放後も残り続け、同じワーカーが処理する次のリクエストがその古い状態を使ってしまう（解放後メモリ使用）

1件目について、PHPの開発チームは、ファイルアップロードなどで使われるマルチパート形式のリクエストを細工することで、設定上の上限内に収まっているように見せながらメモリ不足を起こせると説明しています。

影響を受ける環境

PHPの開発チームによると、ウェブのリクエストを処理しているすべてのPHP環境が対象です。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが挙げられています。

なかでも危険度が最も高いとされるのがApacheのmod_phpです。認証されていないリクエストひとつで、アプリケーションのコードが動き出す前に攻撃が成立することが実証されています。PHP-FPMについては、ソースコードの分析から影響を受けると判断されていますが、1件目の脆弱性で完全な攻撃手法は示されていないとしています。

IPAは、PHPがウェブアプリケーションだけでなく、ソフトウェア製品やネットワーク機器の内部で使われている場合もあると指摘しています。製品内部のPHPは利用者側で把握できないことがあるため、製品の開発元・提供元のセキュリティ情報を確認するよう求めています。

更新先のバージョン

系列	修正版	備考
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35	2026年12月31日でサポート終了
PHP 8.1以前	公式の更新なし	7.4・8.0・8.1向けにはソースコード用の最小限の修正を提供

LinuxディストリビューションやLTS（長期サポート）を提供する事業者には、事前に修正が共有されています。OSのパッケージでPHPを入れている場合は、各ディストリビューションの更新を確認してください。

PHP 8.1以前は、PHPの開発チームからの更新が終わっています。重大度を踏まえて7.4・8.0・8.1向けの最小限の修正も公開されましたが、基本はサポート中のバージョンへの移行が必要です。IPAも、サポートが終了した古いPHPを使い続けているサイトが見受けられると注意を促しています。

なお、有志が運営するRPMリポジトリ「rpms.remirepo.net」は、10月21日中には更新されないとPHPの開発チームが案内しています。このリポジトリを使っている場合は、ディストリビューションのパッケージに切り替えるか、ソースから構築することが推奨されています。

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

PHPの開発チームは、完全な解決策は更新だけだと強調しています。以下は特定の攻撃経路を減らすための措置で、これだけで安全になるわけではありません。

1件目（CVE-2026-109618）への緩和策

memory_limit を -1 に設定する。アプリケーション側から上書きできないよう、FPMのプール設定やApacheの設定で php_admin_value として指定する
post_max_size を小さくする。ファイルアップロードが不要なら 8M、必要なら 32M とし、upload_max_filesize はそれより小さくする
ウェブサーバーやプロキシで、リクエストのサイズ、入力項目数、マルチパートの数、ヘッダー数などに上限を設ける

2件目（CVE-2026-109619）への緩和策

session.upload_progress.enabled を 0 にし、すべてのワーカーを再起動する。php.ini やFPMのプール設定など、リクエストの解析前に効く場所で設定する
PHP 8.5 では fatal_error_backtraces を 0 にし、すべてのワーカーを再起動する
リクエストごとに適用している無効・非推奨の設定を取り除き、攻撃者が引き起こせる致命的エラーやタイムアウトを修正する

いずれも、ini_set() や .user.ini での設定では効果がないとされています。詳細はPHPのセキュリティ勧告とGitHub上のアドバイザリで確認してください。

サイト運営者・利用者がやるべきこと

1. 自分のサイトが使っているPHPのバージョンを確認する

まずは、運営しているサイトやサービスでPHPを使っているか、使っているならどのバージョンかを洗い出します。IPAも、可能な範囲での棚卸しを求めています。WordPressなどのCMSもPHPで動いているため、対象に含めてください。

2. 修正版に更新する

自分でサーバーを管理している場合は、修正版に更新し、PHP-FPMやApacheを再起動します。PHP 8.1以前を使っている場合は、サポート中のバージョンへの移行を急いでください。

3. レンタルサーバーやクラウドの場合は、事業者の案内を確認する

レンタルサーバーやマネージドサービスでは、PHPの更新を事業者が行う場合と、利用者が管理画面でバージョンを切り替える場合があります。契約している事業者の告知を確認し、必要なら管理画面から修正版やサポート中のバージョンを選んでください。

4. 機器や製品の情報を確認する

ネットワーク機器やソフトウェア製品の内部でPHPが使われている場合は、開発元・提供元からの情報を待って対応します。IPAは、すべての製品を個別に確認することまでは求めていないとしています。

公表内容から読み取れること（考察）

ここからは、公式発表をもとにした筆者の考察で、推測を含みます。

今回の脆弱性で特に警戒すべきなのは、mod_phpではアプリケーションのコードが動く前に攻撃が成立する点です。アプリケーション側でどれだけ入力チェックを丁寧にしていても防げません。PHPの開発チームが緩和策としてウェブサーバーやプロキシでの制限を挙げているのも、PHPに届く前に止める必要があるからだと考えられます。

また、修正版が予告より前に公開されたことにも注意が必要です。予告では、詳細の流出や悪用の確認があれば前倒しするとしていました。前倒しの理由は示されていませんが、IPAも、攻撃者が極めて短い時間で攻撃を実行する可能性に言及しています。修正版の公開と同時に修正内容の分析も始まるため、更新は「週末に」ではなく「今日中に」が望ましいと考えます。

2024年にもPHPの脆弱性（CVE-2024-4577）を悪用した攻撃があり、IPAが注意喚起を出しています。サポートが終わった古いPHPを使い続けているサイトは、今回を機に更新の体制を見直す必要がありそうです。

【2026年10月】情報漏えい相次ぎ国が注意喚起｜NCO・IPA・個情委など8機関の声明を一次情報で整理