PHPのTLS通信処理に、外部のHTTPSサーバーとの接続失敗をきっかけとしてPHPプロセスが異常終了する脆弱性「CVE-2026-12184」が確認されました。深刻度は「High」、CVSS v4.0の基本値は8.2です。

この脆弱性で特に注意したいのは、情報漏えいやデータ改ざんではなく、システムの可用性に大きな影響を及ぼす点です。PHP-FPMを利用している環境では、条件がそろうとFPMプロセス全体が停止し、複数のワーカーがまとめて利用できなくなる恐れがあります。GitHubの公式アドバイザリーでも、リモートから誘発可能なDoSにより、すべてのワーカーを含むFPMプロセス全体が停止する可能性が示されています。

決済、会員認証、外部API、クラウドストレージ、メール配信など、外部サービスとHTTPS通信するPHPアプリケーションでは、単なる通信エラーがサービス停止へ発展する可能性があります。「外部から不正なコードを送り込まれなければ安全」とは限らない点が、この問題の見落としやすいところです。

CVE-2026-12184とは

CVE-2026-12184は、PHPがHTTPS接続を処理する際のエラー処理に起因する脆弱性です。

PHP内部でTLS暗号化のセットアップや有効化に失敗すると、通信に使用していたストリームが閉じられ、内部の参照がNULLにリセットされます。しかし、その後の証明書の接続先名に関する後処理で、既に無効となったストリームを前提とした処理が実行される可能性があり、異常終了につながります。

PHP公式の変更履歴では、プロキシを設定した状態でHTTPS URLをfile_get_contents()により取得した場合にセグメンテーションフォルトが発生する問題として修正内容が掲載されています。

重要なのは、脆弱性を発生させるために、必ずしも複雑な攻撃コードや特殊なリクエストが必要ではないことです。

公式アドバイザリーでは、接続先証明書のホスト名検証に失敗した場合や、証明書の有効期限が切れている場合にも問題を誘発できると説明されています。つまり、外部サービス側の証明書トラブル、設定ミス、プロキシの挙動、接続先の切り替えなど、通常の運用で起こり得るTLS接続失敗が引き金になる可能性があります。

なぜPHP-FPM環境では影響が大きいのか

PHP-FPMは、Webサーバーから受け取ったPHPの処理を複数のワーカープロセスで実行する仕組みです。NginxとPHPを組み合わせたWebサーバー構成をはじめ、多くのWebサイトや業務システムで利用されています。

通常、外部APIへの接続に失敗した場合、アプリケーション側で例外やエラーを処理し、該当するリクエストだけを失敗させる設計が一般的です。

ところが今回の問題はPHP本体のメモリアクセスに関係するため、アプリケーションがエラーを適切に捕捉していても、その前段階でPHPプロセスが異常終了する可能性があります。

PHP-FPM環境でプロセス全体が停止すると、次のような影響が想定されます。

・Webサイトのページが表示できない
・APIが応答しなくなる
・管理画面や会員ページにアクセスできない
・決済、認証、メール送信などの外部連携が停止する
・復旧まで「502 Bad Gateway」などのエラーが発生する
・監視や自動再起動の構成によっては、停止と再起動を繰り返す

特に、ユーザーが入力したURLへアクセスする機能、Webhook、外部コンテンツの取得、画像やファイルのインポート、URLプレビュー、外部APIの接続先を切り替えられる機能がある場合は、影響範囲を慎重に確認する必要があります。

攻撃者が接続先を直接指定できないシステムでも、連携先サーバーの証明書期限切れや構成変更によって障害が発生する可能性があるため、インターネットに公開していない社内システムも無関係とは限りません。

影響を受けるPHPのバージョン

CVE-2026-12184について、GitHubの公式アドバイザリーで示されている影響範囲と修正版は次の通りです。

ただし、後述するOpenSSL拡張の脆弱性も同時に解消する場合は、2026年7月にセキュリティリリースとして公開された次のバージョン以降への更新が推奨されます。

・PHP 8.2.32
・PHP 8.3.32
・PHP 8.4.23
・PHP 8.5.8

PHP開発チームは、これらをセキュリティリリースとして公開しています。

PHP 8.4.21や8.5.6以降ではCVE-2026-12184自体は修正されていますが、複数のセキュリティ問題をまとめて解消する観点では、各系列の最新セキュリティリリースへ更新する方が安全です。

OpenSSL拡張にもメモリ破損の脆弱性

今回のPHPセキュリティ更新では、OpenSSL拡張に影響する「CVE-2026-14355」も修正されています。

この問題は、openssl_encrypt()関数でAES-WRAP-PADアルゴリズムを利用した際、暗号化結果のサイズを正しく考慮せずに出力用のメモリ領域を確保していたことが原因です。

AESの鍵ラップにパディングを組み合わせる処理では、暗号化後のデータが入力データより大きくなる場合があります。しかし、脆弱な実装ではRFC 5649によるサイズ増加を考慮しないまま領域を確保するため、OpenSSLが確保済みバッファの外側へ書き込む可能性があります。

その結果、ヒープの管理情報が破損し、PHPアプリケーションが異常終了する恐れがあります。NVDではCVSS v3.1の基本値が4.8、深刻度は「Medium」とされています。

影響を受けるバージョンは次の通りです。

AES-WRAP-PADは一般的なWebサイトで広く使われる暗号方式ではありません。そのため、CVE-2026-12184と比べると該当環境は限定的と考えられます。

それでも、鍵管理システム、暗号化データの交換、クラウドサービスとの連携、独自の暗号処理などでAES-WRAP-PADを利用している場合は、メモリ破損やサービス停止につながる可能性があるため、コードと設定の確認が必要です。

自社環境で優先的に確認すべきポイント

まず、サーバーで稼働しているPHPのバージョンを確認します。

コマンドラインでは、次のコマンドを実行できます。

php -v

PHP-FPMについては、実際にWebサーバーが利用しているバージョンと、コマンドラインで表示されるバージョンが異なる場合があります。複数のPHPをインストールしている環境では、FPMサービスの名称や設定ファイルも併せて確認してください。

次に、アプリケーションが外部へHTTPS通信を行っているかを調べます。主な確認対象は次の通りです。

・file_get_contents()によるHTTPS URLの取得
・cURLを使用した外部API通信
・Webhookやコールバック先への接続
・決済サービスや本人認証サービスとの連携
・メール配信、SMS、地図、翻訳などの外部API
・Composerパッケージが内部で実行するHTTP通信
・HTTPSプロキシを経由する通信
・ユーザーが指定したURLからのデータ取得

CVE-2026-12184の公式な再現例はPHPのHTTPストリーム処理に関係しています。すべてのHTTPS通信方式が同じ条件で影響を受けると断定するのではなく、PHP本体のバージョンを基準に更新し、そのうえで外部通信の経路を洗い出すことが重要です。

更新時はパッケージの表示だけで判断しない

Linuxディストリビューションが提供するPHPでは、PHP公式と異なるバージョン表記のまま、セキュリティ修正だけがバックポートされる場合があります。

そのため、「PHP 8.3.32ではないから未修正」と即断せず、利用しているOSやパッケージ提供元のセキュリティ情報も確認してください。

反対に、コンテナイメージ、独自ビルド、外部リポジトリ、レンタルサーバーのPHPを利用している場合は、修正版が提供されているかを管理会社やサービス事業者へ確認する必要があります。

更新後はバージョン表示だけでなく、次の項目まで確認します。

・PHP-FPMが正常に起動しているか
・WebサーバーとFPMの接続に問題がないか
・必要なPHP拡張が読み込まれているか
・外部APIや決済などのHTTPS連携が成功するか
・監視システムに異常終了の記録がないか
・エラーログにセグメンテーションフォルトやメモリ破損が出ていないか
・コンテナやオートスケール環境の全インスタンスが更新されているか

キャッシュやOPcacheが有効な環境では、パッケージを更新しただけで旧プロセスが残っていないかも確認してください。PHP-FPMの再起動後、実際に稼働しているプロセスが新しいバイナリへ切り替わったことを確かめる必要があります。

WAFや証明書監視だけでは防げない

CVE-2026-12184は、一般的なSQLインジェクションやクロスサイトスクリプティングのように、Webアプリケーションへの不正な入力だけを検知すれば防げる問題ではありません。

TLS接続の失敗後にPHP内部で発生する処理不備であるため、WAFで受信リクエストを検査していても、根本的な対策にはなりません。

接続先証明書の有効期限を監視することは障害予防として有効ですが、証明書のホスト名不一致、信頼チェーンの問題、プロキシ設定、接続先の一時的な構成不良まで完全に防ぐことは困難です。

また、PHP-FPMの自動再起動を設定していても、同じ条件が繰り返されれば再び停止する可能性があります。監視や再起動は被害を抑える補助策にはなりますが、脆弱性そのものを解消するものではありません。

根本的な対策は、修正済みのPHPへ更新することです。

「攻撃されていないから後回し」は危険

今回の脆弱性は、機密情報を盗み出すタイプではありません。しかし、サービスを止めることができる脆弱性は、ECサイト、予約システム、会員サービス、社内業務システムなどにとって十分に重大です。

さらに、明確な攻撃が行われなくても、連携先の証明書期限切れや設定変更をきっかけに障害が発生する可能性があります。

つまり、セキュリティ事故と通常障害の境界が曖昧な問題です。原因を知らないままでは、「外部APIの一時的な不調」「PHP-FPMが偶然落ちた」と判断され、再発を繰り返す恐れもあります。

PHP-FPMを利用し、外部のHTTPSサービスと通信している環境は、優先度を上げて対応してください。

特に次の条件に該当する場合は、早期の更新が求められます。

・決済や認証など、停止が売上や業務に直結する
・ユーザー入力を基に外部URLへアクセスする
・複数の外部APIやSaaSと連携している
・HTTPSプロキシを利用している
・PHP-FPM停止時の自動復旧や監視が整備されていない
・利用中のPHPバージョンを長期間確認していない

まとめ

PHPで確認されたCVE-2026-12184は、TLS接続のセットアップに失敗した際の処理不備により、PHP-FPM全体を停止させる可能性があるHigh評価の脆弱性です。

証明書の期限切れやホスト名検証の失敗でも誘発される可能性があり、特殊な攻撃コードがなくても問題が表面化し得る点に注意が必要です。

また、OpenSSL拡張のAES-WRAP-PAD処理におけるメモリ破損「CVE-2026-14355」も公開されています。

両方の問題へ対応するには、利用している系列に応じてPHP 8.2.32、8.3.32、8.4.23、8.5.8以降への更新を検討してください。OSベンダーがバックポート修正を提供している場合は、ベンダーのセキュリティ情報に基づいて適用状況を判断します。

Webサイトが現在正常に動作していても、安全であるとは限りません。外部HTTPS通信を行うPHP-FPM環境では、障害が起きてから対応するのではなく、稼働バージョンと更新状況を今の段階で確認することが重要です。

Failure to setup TLS with a remote server can result in a remote DoS

### Summary In `php_stream_url_wrap_http_ex`, when TLS crypto setup fails (via `php_stream_xport_crypto_setup` or `php_s...

github.com

ext/openssl: Memory corruption (zend_mm_heap corrupted) in openssl_encrypt with AES-WRAP-PAD

### Summary Usate of AES-WRAP-PAD can result in memory corruption and abort of application. ### Details The output buffe...

github.com

この記事ではPFX形式の証明書から証明書と秘密鍵を取り出す方法を説明します。

秘密鍵を取り出す

# openssl pkcs12 -in <PFXファイル> -nocerts -out <出力する秘密鍵名>

取り出す秘密鍵を暗号化する必要がなければ次のように「-nodes」を付けます。

# openssl pkcs12 -in <PFXファイル> -nocerts -nodes -out <出力する秘密鍵名>

サーバ証明書を取り出す

# openssl pkcs12 -in <PFXファイル> -clcerts -nokeys -out <出力する証明書名>