PHPに深刻な脆弱性2件、修正版8.5.12などを公開【2026年10月】

「PHP に重大な脆弱性」のニュースを見て、自分の WordPress は大丈夫なのか気になった人も多いのではないでしょうか。

2026年10月21日（日本時間同日夜）、PHP の開発チームは 重大な脆弱性2件を修正した PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開しました。深刻度は 2件とも CVSS v4.0 で 9.2 で、認証なしでリモートからコードを実行される（RCE）恐れ があります。

PHP: News Archive

php.net は 「すべての PHP 利用者は今すぐ更新を」 と強く呼びかけ、完全な対策は更新だけ としています。前日に予告されていたセキュリティリリースが、ついに中身ごと公開された——という位置づけです。

※ この記事は、10月21日朝の予告の段階で公開した速報を、修正版の公開を受けて更新したものです（2026年10月21日時点の情報）。

PHPの修正版とは？一言でまとめると

「Web で動く PHP の重大な脆弱性2件を直した修正版。サポート中の 8.2〜8.5 はすぐ更新を」という PHP 公式のセキュリティリリース です。

CVSS は脆弱性の深刻度を 0〜10 で表す指標です。9.0 以上は最も深刻な「Critical」 にあたります。

修正された2件の脆弱性：CVEと中身

php.net のセキュリティアドバイザリと GitHub のアドバイザリによると、2件の中身は次のとおりです。

GitHub のアドバイザリでは、2件とも ネットワーク経由・認証不要・利用者の操作も不要 と評価されています。一方で 攻撃の条件はやや複雑（AC:H / AT:P） とされています。それでも成功すれば、Web サーバーのワーカーの権限で任意のコードを実行される 恐れがあります。

CVE-2026-109618 では、マルチパート（ファイルのアップロードなどで使う形式）の解析 などを通じて、攻撃者がメモリ不足を引き起こせるとしています。

なお、php.net の発表には、実際の攻撃（悪用）が確認されたかどうかの記載はありません。

影響を受ける環境とバージョン

① 対象：Webリクエストを処理するすべてのPHP

php.net は、Web リクエストを処理するすべての PHP が危険にさらされているとしています。名前が挙がっているのは次の動かし方です。

• PHP-FPM（nginx と組み合わせる構成など）
• Apache の mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

最もリスクが高いのは mod_php です。php.net は、認証なしのリクエストで、アプリのコードが動く前に攻撃できる エクスプロイトを実証済みとしています。

PHP-FPM について、GitHub のアドバイザリは次のように書いています。

• CVE-2026-109618: ソースの解析上は影響を受けうるが、完全なエクスプロイトは実証されていない
• CVE-2026-109619: セッションのアップロード進捗の機能を通じて影響を受ける

FPM だから安全、とは言えない ので、構成にかかわらず更新しましょう。

② 修正版のバージョン

※ 2026年10月21日時点。8.2 は 年末でサポートが終わる ため、php.net も上位バージョンへの移行を計画するよう求めています。

③ 8.1以前：php.netからの修正版は出ない

8.1 以前には、PHP プロジェクトからの修正版は提供されません。 php.net は、ディストリビューションや LTS ベンダーがバックポート（修正の移植）を出している場合がある ので提供元に確認するか、サポート中のバージョンへ移行する よう案内しています。

ただし今回は深刻度が高いため、PHP のセキュリティチームは 7.4・8.0・8.1 向けに最小限のソース用バックポート も用意しました。自分でソースからビルドしている人向けのものです。

なお、予告の段階では CERT-EU が「PHP 5 以降のすべてのバージョンが影響を受ける可能性」 と伝えていました（根拠は SNS の投稿）。php.net の発表には PHP 5〜7.3 についての記載はありません。古いバージョンを使っている場合は、影響の有無にかかわらず移行を急ぐ のが現実的です。

更新方法：VPS・レンタルサーバー別

① 使っているPHPのバージョンを確認する

VPS なら、サーバーにログインして次のコマンドで確認できます。

php -v

ただし、コマンドラインの PHP と、Web サーバーが使う PHP（PHP-FPM など）が別のバージョン になっていることもあります。WordPress なら、管理画面の 「ツール → サイトヘルス → 情報」の「サーバー」欄 でも確認しておくと確実です。

② OSのパッケージで入れたPHP：OSの更新を適用する

php.net によると、Linux ディストリビューションと LTS ベンダーには事前にパッチが渡されています。apt や dnf で入れた PHP は、OS の修正版パッケージ を当てます。

Ubuntu の例では、24.04 LTS の修正版は 8.3.6-0ubuntu0.24.04.13 です。OS のパッケージは修正だけを取り込む ため、バージョン番号が php.net の 8.3.36 とは一致しません。番号ではなく、OS のセキュリティ情報で修正済みかを確認 しましょう。

また、Remi のリポジトリ（rpms.remirepo.net）を使っている場合は注意 が必要です。php.net は、このリポジトリは 10月21日当日は更新されない とし、ディストリビューションのパッケージに切り替えるか、ソースからビルドする よう強く勧めています。

VPS の自動アップデートの設定は、こちらの記事で解説しています。

あわせて読みたい

さくらのVPSのセキュリティ初期設定：最初にやる5つの対策【2026年版】

③ ソースからビルドしたPHP：php.netの修正版で入れ直す

php.net のダウンロードページから 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 のソース を取得して入れ直します。Windows 版のソースとバイナリも同じページにあります。

④ レンタルサーバー・マネージドサービス：事業者のお知らせを確認

PHP 本体の更新は 事業者側の作業 です。事業者のお知らせ・メンテナンス情報 を確認しましょう。コントロールパネルで PHP のバージョンを選べる場合は、サポート中のバージョン（8.3 以降が目安） を選んでおくと安心です。

レンタルサーバーと VPS で、どこまで自分で管理するかの違いはこちらで整理しています。

あわせて読みたい

レンタルサーバーとVPSの違いは？【初心者向け】使い分けと選び方を整理する

⑤ 更新後：ワーカーを再起動して確認する

パッケージを更新しても、動いている PHP-FPM や Apache のプロセスは古いまま のことがあります。更新後は PHP-FPM や Apache を再起動 し、サイトヘルスなどで Web サーバーが使う PHP が修正版になったか を確認しましょう。

すぐ更新できないとき：php.netの暫定策

php.net は、すぐに更新できない場合の対策も示しています。ただし 「完全な対策は更新だけ。以下は特定の攻撃経路を減らすだけで、安全にはならない」 と明記しています。あくまで更新までのつなぎ です。

① CVE-2026-109618（OOM）向け

• memory_limit=-1 にする。アプリが上書きできないよう、FPM プールや Apache の設定の php_admin_value で指定し、他の設定で有限の値に戻っていないかも確認する。ただし 下のレイヤーのメモリ確保の失敗は防げない
• post_max_size を小さくする。アップロード不要なら 8M、必要なら 32M。upload_max_filesize はそれより小さく
• Web サーバーやプロキシで制限する（リクエストサイズ、入力フィールド数、マルチパートの数、ヘッダー数、入れ子の深さ）
• コンテナや cgroup の制限 を可用性の境界として使う。RLIMIT_AS / RLIMIT_DATA は使わない（脆弱な経路を引き起こしうるため）

② CVE-2026-109619（古いグローバル状態）向け

• session.upload_progress.enabled=0 にして、すべてのワーカーを再起動する。php.ini・FPM プール・サーバーの設定で指定し、ini_set() や FPM の .user.ini には頼らない。確認済みのセッションの経路は防げるが、他の変種は防げない
• PHP 8.5 では fatal_error_backtraces=0 にして再起動する（確認済みの経路の1つだけを防ぐ）
• リクエストごとに適用している 無効・非推奨の設定 を取り除く。エラー表示を隠しても効果はない
• 攻撃者が起こせる 致命的エラーや実行タイムアウト を直す

設定を変えたら更新しなくてよい、ということではありません。 修正版が使えるようになったら、すぐに更新しましょう。

これまでの経緯：予告から公開まで

今回の修正版は、前日に日時を決めて予告 されていました。日本時間に直すと、次のとおりです。

予告の段階で IPA は、悪用した攻撃は確認していない としたうえで、攻撃者が極めて短時間で攻撃を実行する可能性 があるとして、公開後すぐ適用できるよう準備を求めていました。IPA は サポートが終わった古い PHP を使い続けているサイトが見受けられる とも指摘しています。

10月21日23時台の確認時点では、IPA のページは予告段階の「事前準備のお願い」のまま で、JPCERT/CC の注意喚起も出ていません。日本語の続報は、IPA と JPCERT/CC のサイトで確認しましょう。

IPA は、PHP が ソフトウェア製品やネットワーク機器の内部で使われている場合もある としています。機器のことは、開発元・提供元のセキュリティ情報 を確認しましょう。

開発者の反応

予告の段階から、海外の開発者コミュニティでも大きな話題になっていました（以下は10月21日18時ごろの確認）。

• 夜遅くまでの対応を覚悟する声: Hacker News の php.announce の告知のスレッド（約800ポイント・320件超のコメント）では、jacquesm 氏が「多くの人が今夜は遅くまで起きていることになる」と書いています（出典）
• 対象バージョンが分からないことへの不満: 同じスレッドで、jamesfinlayson 氏は「どのバージョンが影響を受けるのか、ヒントもないのか」と書いています（出典）
• 事前告知という方法への疑問: php.net の告知のスレッドで、samueloph 氏は「このやり方は、修正版が出るまで誰も対処できないまま、脆弱性探しを促すようなものだ」と、予告の仕方を批判しています（出典）
• 非公式の回避策も出回っていた: 同じく Hacker News では、予告の段階で検証コードや非公式の回避策が SNS で出回っているという書き込みも複数ありました（出典）。現在は php.net が公式の暫定策を公表している ので、設定を変えるならそちらに従いましょう

IT Picks的な所感

予告から1日足らずで、CVE・対象・修正版・暫定策まで一度に公開 されました。php.net が 「完全な対策は更新だけ」と何度も強調 している点からも、深刻さがうかがえます。認証なしで、アプリのコードが動く前に攻撃できる という性質上、WordPress のプラグインを最新にしていても防げない点が重要だと考えています。

特に、VPS で自分でサイトを運用している人は、自分で更新しない限り直りません。OS のパッケージで入れていればコマンド1つで済むことが多い一方、Remi のリポジトリや古いバージョンを使っている場合は 今回が見直しのきっかけ になりそうです。

今週はすでに、認証局 eMudhra の鍵漏えいで サーバー側の証明書の更新 が必要になったばかりです。立て続けに「サーバーを持つ側が動く必要がある」ニュースが続いており、更新の手順と情報源を普段から決めておく ことが大切だと考えています。

あわせて読みたい

eMudhra証明書の鍵漏えい、サーバー側で必要な対応【2026年10月】

まとめ

PHP の重大な脆弱性と修正版のポイントをまとめます。

• 公開日：2026年10月21日（予告は日本時間23:00）
• 修正版：8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• 脆弱性：CVE-2026-109618 / CVE-2026-109619、いずれも CVSS v4.0 で 9.2
• 影響：認証なしのリモートコード実行の恐れ（Web で動くすべての PHP。最もリスクが高いのは mod_php）
• 8.1 以前：php.net からの修正版なし。ディストリ・LTS ベンダーに確認するか移行
• 更新方法：OS のパッケージ（Ubuntu は USN-8948-1 など）か php.net の修正版。更新後は ワーカーを再起動
• 暫定策：php.net の設定変更は 部分的な対策で、更新の代わりにはならない

まずは php -v やサイトヘルスで自分のサイトの PHP のバージョンを確認し、今日のうちに修正版へ更新 しましょう。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。