【更新 2026-07-07】本記事を見直し、修正しました。主な修正点：OpenSSL拡張の脆弱性（GH-22187）にCVE-2026-14355（CVSS 5.6・重要度「中」）が正式採番されNVDに登録されたため追記。あわせてfile_get_contents（GH-21468）の項に、遠隔起因のDoSの可能性がある旨の要確認注記を追加しました。
【更新 2026-07-30】本記事を見直し、修正しました。主な修正点：file_get_contents（GH-21468）に付けていた要確認注記を、PHP公式セキュリティアドバイザリ（GHSA-mhmq-mmqj-2v39）で裏が取れたため解消し、CVE-2026-12184・重要度「High」・遠隔から引き起こせるDoSという確定情報に書き換えました。あわせて、修正内容がブランチごとに異なる点（GD・BCMath・Pharの修正は8.5.8 / 8.4.23のみ。CVE-2026-12184の修正が今回のリリースに含まれるのは8.3.32のみで、8.5系・8.4系は2026年5月に修正済み）を追記しました。
PHPの開発チームは2026年7月2〜3日、複数の脆弱性を修正したセキュリティ更新版を公開しました。対象は現在サポート中の全ブランチ（8.2〜8.5系）で、修正版は8.5.8 / 8.4.23 / 8.3.32 / 8.2.32です。PHPはWordPressをはじめ社内Webシステムや業務アプリの土台として広く使われており、自社サーバーやレンタルサーバー上のバージョンを一度棚卸しすることをおすすめします。
ただし今回の修正の多くは、メモリ破壊や整数オーバーフローといった特定の関数・条件下で起きる不具合です。「入れておけば安心」ではなく、自社が該当機能を使っているかで優先度が変わります。本記事ではその判断材料を整理します。
- 今回修正された脆弱性の種類と対象バージョン
- 「すぐ直すべきか」を判断するための現場の視点
- 情シスとして押さえるべきパッチ運用の考え方
何が起きたのか
PHPの各サポートブランチに対し、複数の脆弱性をまとめて修正したセキュリティリリースが公開されました。主な修正内容は、公開情報およびPHP公式のChangeLog・GitHub上のIssueで確認できる範囲で次のとおりです。なおすべての修正が全ブランチに入っているわけではないため、各項目に対象バージョンを併記します。
- OpenSSL拡張：
openssl_encrypt()で「AES-WRAP-PAD」を扱う際にヒープ（メモリ）破壊が発生しうる問題（GH-22187 / CVE-2026-14355）。対象：8.5.8 / 8.4.23 / 8.3.32 / 8.2.32 の全ブランチ。 - GD拡張：画像処理関数でのダブルフリーや整数オーバーフロー。オーバーフロー起因の早期リターン後に
gdImageSetStyle()で二重解放が起きるケースなど。対象：8.5.8 / 8.4.23 のみ。 - BCMath：
bcround()等での過大なメモリ割り当て・符号付き整数オーバーフロー。対象：8.5.8 / 8.4.23 のみ。 - Phar：「.phar」ディレクトリ保護のバイパス（
addEmptyDir()で「/.phar」始まりのパスが保護されない問題）。対象：8.5.8 / 8.4.23 のみ。 - file_get_contents（HTTPストリーム）：プロキシ設定時にHTTPS URLを取得し、TLS通信の確立に失敗すると異常終了（セグメンテーション違反）する問題（GH-21468 / CVE-2026-12184）。PHP公式のセキュリティアドバイザリは、これを遠隔から引き起こせるDoSと位置づけ、重要度を「High」（CVSS 4.0で8.2）としています。証明書の期限切れやホスト名の検証失敗といった接続先サーバー側の事情だけで発火しうる点と、PHP-FPMではプロセス全体が全ワーカーを巻き込んで停止しうる点が要注意です。対象：この修正が今回のリリースに含まれるのは8.3.32のみ。8.5系・8.4系は2026年5月7日公開の8.5.6・8.4.21で既に修正済みで、8.2系は本アドバイザリの対象に含まれていません。
各修正にはGitHubのIssue番号（GH-22187など）が付与されています。このうちCVEが採番されたのは2件です。OpenSSL拡張の問題にはCVE-2026-14355（CVSS 3.1で基本値5.6・重要度「中」、CWE-122 ヒープバッファオーバーフロー）が割り当てられ、NVDに登録されました。file_get_contentsの問題はCVE-2026-12184（重要度「High」）で、本記事更新時点（2026-07-30）ではNVDおよびCVE Programのデータベースに記録が公開されておらず、内容はPHP公式アドバイザリ（GHSA-mhmq-mmqj-2v39）とPHP公式ChangeLogで確認できます。GD・BCMath・Pharの各修正については、PHP公式のアドバイザリ一覧・ChangeLogにCVEが併記されていません。正確な採番は各Linuxディストリビューションのセキュリティ勧告やNVD・PHP公式の情報で確認してください。ここでは「どの機能に、どんな種類の欠陥があったか」を押さえることを優先します。
影響を受ける環境は？
結論から言うと、サポート対象ブランチの古いパッチレベルを使っているPHP環境が対象です。今回の修正版より前のバージョンは、上記の機能を使う経路で影響を受けうると考えるのが安全です。
| ブランチ | 修正版（今回） | これより前は要更新 |
|---|---|---|
| PHP 8.5系 | 8.5.8 | ◯ |
| PHP 8.4系 | 8.4.23 | ◯ |
| PHP 8.3系 | 8.3.32 | ◯ |
| PHP 8.2系 | 8.2.32 | ◯ |
注意したいのは、すでにサポートが終了したPHP 8.1以前です。8.1は2025年末でサポートが終了しており、今回のような修正は提供されません。EOL（サポート終了）のPHPを動かし続けている場合、今回の件に限らず今後の脆弱性に対して無防備になるため、バージョンアップ計画を最優先で検討すべきです。
自社ではどう確認すればよいか
まずは動いているPHPのバージョンを把握するところからです。サーバー上で php -v を実行する、phpinfo() を確認する、あるいはレンタルサーバー／マネージドホスティングであれば管理画面のPHPバージョン設定を見る、といった方法があります。WordPressやEC、社内グループウェアなど「PHPで動いているとは意識していないシステム」に古いPHPが同梱されていないかも、この機会に洗い出しておくと安全です。
すぐに直すべきか？優先度の考え方
「即座に緊急対応」よりは「計画的に、しかし後回しにしない」レベルと捉えるのが現実的です。今回の脆弱性の多くは、攻撃者が任意のコードを無条件でリモート実行できるタイプというより、openssl_encrypt() や画像処理、Pharの特定機能などアプリ側がその機能を、かつ外部由来のデータで呼び出している場合に問題化するものです。
ただしCVE-2026-12184（file_get_contents）は例外です。アプリ側が特殊なコードを書いていなくても、プロキシ経由のHTTPS接続でTLSの確立に失敗するだけで発火しうる遠隔起因のDoSで、PHP-FPMではプロセス全体が停止しえます。8.3系を使っていてまだ8.3.32に上げていない環境は、優先度を上げて対応してください（8.5系・8.4系は2026年5月の更新で修正済みです）。
そのため優先度は、「該当機能を、信頼できない入力で使っているか」で見極めます。たとえば外部からアップロードされた画像をGDで加工している、外部入力を暗号化処理に渡している、といった構成は優先的に更新したい対象です。逆に、そうした経路が無い静的な社内ツールであれば、通常のパッチ適用サイクルに載せる判断も取り得ます。
現場目線の課題
正直なところ、PHPのマイナー更新は「気づけば数バージョン遅れていた」となりがちです。特に情シスが直接管理していないサーバー（事業部門が立てたレンタルサーバー、外注制作のサイトなど）のPHPは、誰も更新していないまま放置されているケースが少なくありません。今回のように「全ブランチ同時にまとめて修正」が出たタイミングは、そうした管理外のPHP資産を洗い出す良い機会でもあります。バージョン番号を追いかけるより、「そもそも社内にどれだけPHPが動いているか」を把握しているかどうかが、現場では効いてきます。
情シスはどうすべきか
個別の脆弱性対応も大切ですが、本質は「日常的にパッチを当てられる運用」を作れているかです。単発の対応チェックリストを増やすより、資産管理と更新の仕組みを整えるほうが長期的に効きます。基本的な考え方は、公的機関の指針を土台にするのが確実です。
- 中小企業の情報セキュリティ対策ガイドライン（IPA）：ソフトウェア更新や資産把握を含む、実務の土台となる指針です。
- 対策のしおり（IPA）：現場の担当者・エンドユーザー向けの啓発資料として活用できます。
あわせて、社内のPHP利用箇所（自社構築システム・WordPress・外注サイト等）の一覧を持ち、リリース情報を定点観測する担当・仕組みを決めておくと、次回以降の対応が格段に軽くなります。地道ですが、こうしたユーザー・部門への啓発と情報の一元把握こそが、脆弱性が出るたびに慌てない体制につながります。
まとめ
- PHPが2026年7月に全サポートブランチ向けのセキュリティ更新（8.5.8 / 8.4.23 / 8.3.32 / 8.2.32）を公開。OpenSSL・GD・BCMath・Pharなど複数の脆弱性を修正した（修正内容はブランチごとに異なり、GD・BCMath・Pharは8.5.8 / 8.4.23のみ）。
- 多くは特定機能・条件下で起きる不具合のため、「該当機能を信頼できない入力で使っているか」で優先度を判断する。ただしCVE-2026-12184は接続先サーバー起因で遠隔からDoSを起こせる例外で、8.3系は今回の8.3.32が修正版（8.5系・8.4系は2026年5月に修正済み）。EOLのPHP 8.1以前は最優先で更新計画を。
- 単発対応より、社内のPHP資産の把握と継続的なパッチ運用の仕組み作りが本質。土台はIPAの公的指針を活用する。
