BLOG / セキュリティ
PHPに重大な脆弱性【2026年10月】CVSS9.2の危険性と対策|PieceInnovation
2026年10月21日、PHPに認証不要でリモートコード実行につながる重大な脆弱性2件が公表されました。CVSS9.2の危険性、WordPress・Laravelなどを使う企業サイトへの影響、修正版と対応手順を岡崎市のPieceInnovationが解説します。
2026年10月21日、PHPの開発チームは、認証なしでリモートコード実行につながる可能性がある2件の重大な脆弱性を公表し、修正版を公開しました。
PHP公式は、利用者に対して直ちに更新することを強く推奨しています。[1]
今回確認したいのは、ホームページやWebシステムを動かしているPHP本体の修正状況です。
WordPressなどのCMSや、Laravelで開発されたシステムを運用している企業は、サイトの管理会社・サーバー会社に確認してください。
愛知県岡崎市の株式会社PieceInnovationが、企業の経営者・Web担当者に向けて、今回の危険性と対応の進め方を解説します。
1. 公表された脆弱性とCVSS 9.2の意味
対象となるのは、PHP内部のメモリ管理やリクエスト処理に関する次の2件です。
いずれも深刻度はCVSS v4.0の基本評価値で9.2とされています。[1][2][3]
| 識別番号 | 問題の概要 | 深刻度 |
|---|---|---|
| CVE-2026-109618 | メモリ不足時の処理によって内部データが不正な状態になり、コード実行につながる可能性 | 9.2 / Critical |
| CVE-2026-109619 | 解放済みメモリを指す古い内部状態が残り、後続のリクエストでコード実行につながる可能性 | 9.2 / Critical |
CVSS 9.2とは?
CVSSは、脆弱性の技術的な深刻度を0〜10の数値で表す指標です。
9.0〜10.0は最上位の「Critical(緊急)」 に分類されます。
ただし、CVSS 9.2は、被害に遭う確率が92%という意味ではありません。[4]
攻撃の成否は、以下のような条件によって異なります。
- PHPの実行方式
- サーバーやPHPの設定
- アプリケーションの処理内容
- 攻撃が成立するための環境条件
今回の評価にも成立条件と攻撃の複雑性が考慮されていますが、外部公開された環境では修正状況の確認を急ぐ必要があります。 [2][3]
2. ログイン前に不正な処理を実行されるおそれ
リモートコード実行(RCE)とは?
リモートコード実行(RCE)とは、外部の攻撃者がサーバー上で不正なプログラムや命令を実行できる状態を指します。
今回の脆弱性では、事前のログインや、管理者・利用者によるクリック操作を必要としない攻撃が問題になっています。[2][3]
特にApacheのmod_php環境では、アプリケーションのコードが動く前に攻撃が成立する経路が確認されています。
そのため、管理画面のパスワード強化やアプリ側の認証対策だけで、今回の問題への対応を済ませることはできません。[1][2]
想定される被害
攻撃が成功した場合の権限は、PHPのWeb処理用プロセスが持つ権限です。
その権限で読める情報や変更できるファイル、接続できるデータベースの範囲を踏まえると、次のような被害が想定されます。[2][3]
-
機密情報の窃取
- 設定ファイル
- APIキー
- データベース接続情報
-
顧客情報・登録データへの不正アクセス
- 権限の及ぶ範囲での情報閲覧
- データの改ざん
-
Webサイトの改ざん
- ページ内容の不正な変更
- 不正な処理の追加
-
サービスや業務の停止
- Webサイトの停止
- 管理画面の停止による業務への影響
これらはRCEから考えられる被害例であり、すべての環境で同じ被害が起きるという意味ではありません。
また、今回の発表だけで、個別のサイトがすでに侵入されたと判断することもできません。
3. WordPressやLaravelを利用するサイトも確認が必要
PHP公式は、以下のようなWebリクエストを処理するPHP環境をリスク対象として挙げています。[1]
- PHP-FPM
- Apacheのmod_php
- php-cgi
- FrankenPHP
- LiteSpeed
確認対象となるWebサイト・システム
企業側では、コーポレートサイトだけでなく、以下も確認対象に含めましょう。
- コーポレートサイト(企業ホームページ)
- 採用サイト
- ECサイト
- 会員サイト
- お問い合わせフォーム
- 業務用Webシステム
サイトごとにサーバーやPHPのバージョンが異なる場合があります。
そのため、会社単位ではなく、稼働環境ごとに確認することをお勧めします。
PHP-FPMを利用している場合も注意
PHP-FPMについても、2件目の脆弱性でアプリケーション側の条件を伴うコード実行が検証されています。
PHP-FPMを使っていることだけを理由に、更新を見送ることはできません。 [3]
また、今回更新すべき対象はPHP本体です。
WordPress本体・プラグイン・テーマ、あるいはLaravelの更新と、PHP本体の更新を分けて管理する必要があります。
4. 今回の修正版と古いPHPへの対応
2026年10月21日に公表された修正版は以下のとおりです。
現在利用している系列に対応する、修正済みのPHPまたは提供元の修正パッケージを確認してください。[1]
| 利用中のPHP系列 | 今回の修正版 |
|---|---|
| PHP 8.2系 | PHP 8.2.35 |
| PHP 8.3系 | PHP 8.3.36 |
| PHP 8.4系 | PHP 8.4.27 |
| PHP 8.5系 | PHP 8.5.12 |
※ 上表は今回の修正が入ったバージョンです。公開後に新しい修正版が提供されている場合は、その情報も確認してください。
Linuxサーバーの場合の注意点
Linuxディストリビューションや長期サポートの提供元が、従来のパッケージに修正を取り込む場合もあります。
表示上のPHPバージョンだけで未対策と決めつけず、以下の2件に対する修正適用状況を確認することが大切です。[1]
-
CVE-2026-109618 -
CVE-2026-109619
PHP 8.1以前を利用している場合
PHP 8.1以前は、PHPプロジェクトによる通常のサポートが終了しています。
今回はPHP 7.4・8.0・8.1向けにも最小限のソース修正が提供されていますが、通常サポートの再開を意味しません。
利用中の提供元への確認と、サポート対象バージョンへの移行を進めてください。[1]
5. 企業が進めたい4つの対応手順
今回の脆弱性に対して、企業が実施したい対応を4つのステップに整理しました。
STEP 1:管理会社に現在の環境と修正状況を確認する
最初に、サイトの管理会社やサーバー会社へ、実際にWebサイトの処理で使われているPHPのバージョンと、今回の修正が適用されているかを確認します。
複数のサーバーやコンテナで稼働している場合は、すべての対象環境を確認してください。
確認しておきたい項目
- 対象サイトのURLと利用しているサーバー
- Web処理で使うPHPのバージョン・実行方式
- 今回の2件への対応状況
- 対応状況の根拠となる提供元の案内
- 未対応の場合の作業担当者
- 更新予定日と暫定対応の内容
これらを一覧にしておくことで、対応漏れを防ぎやすくなります。
STEP 2:修正版への更新を優先して進める
PHP公式は、直ちに更新することを推奨しています。[1]
更新前に以下を確認し、作業担当者と実施時刻を決めてください。
- バックアップの取得状況
- 障害発生時の復旧手順
- 主要機能の互換性
- 更新作業の担当者と実施時刻
通常の月次保守まで待たず、緊急の更新として扱うことをお勧めします。
長期間更新していないシステムでは、対応するPHPの系列や拡張機能の確認も必要です。
大きなバージョン変更が必要な場合は、公開範囲を制限するなどの暫定対応も含めて、管理担当者と進め方を判断します。
STEP 3:稼働プロセスへの反映と主要機能を確認する
パッケージを更新した後は、PHP-FPMやApache、コンテナなど、実際にリクエストを処理するプロセスを提供元の手順に従って切り替えます。
更新後の環境で、利用中の主要機能が正常に動作するか確認してください。
主な動作確認項目
- Webページの表示
- 管理画面へのログイン
- お問い合わせフォームの送信
- ファイルアップロード
- 決済機能
- その他の業務上重要な機能
また、対応完了の記録には以下を残しておくことをお勧めします。
- 更新した環境
- 修正パッケージまたはPHPバージョン
- 更新の反映日時
- 動作確認した機能
記録を残しておくことで、社内や取引先への説明にも役立ちます。
STEP 4:不審な挙動があれば調査を進める
ログやファイルの変更履歴などを確認し、不審な処理が疑われる場合は管理担当者へ調査を依頼してください。
公式の詳細勧告では、ログに異常が見当たらないことだけでは安全を証明できないとされています。[3]
脆弱性の修正と、すでに起きた侵害への対応は別の作業です。
侵害が疑われる場合は、修正版の適用と並行して、影響範囲の確認や必要な復旧対応を進めることをお勧めします。
6. すぐに更新できない場合の暫定対策
PHP公式は、一部の攻撃経路を軽減する設定変更を案内していますが、すべての攻撃経路を防ぐ設定上の回避策は示していません。
今回の脆弱性への完全な対策は、修正版の適用です。 [1]
更新までのリスクを減らす手段として、以下のような対応が考えられます。
- アップロード進捗管理の無効化
- リクエストの制限
- Webサーバーやプロキシでのアクセス制限
- 公開範囲の一時的な制限
ただし、適用箇所やPHPのバージョンによって効果が異なります。
管理担当者が公式勧告を確認し、必要に応じてPHPの手前でアクセスを制限してください。[1]
暫定対策を実施する際の注意点
WAFやアクセス制限を実施していても、それだけで今回の修正を省略できるとは判断しないでください。
また、メモリ制限に関する設定変更は可用性に影響するため、紹介された値だけを切り出して一律に変更せず、稼働環境全体で検討する必要があります。
暫定対策はあくまで更新までのリスク軽減策であり、修正版の適用に代わるものではありません。
7. 日頃の保守で緊急時に対応できる状態を整える
今回の対応を機に、サイトごとの管理状況を見直しておくことをお勧めします。
日頃から確認しておきたい項目
- PHPのバージョンとサポート期限
- システム更新の担当者
- バックアップの取得状況
- 障害発生時の復旧手順
- 緊急時の連絡先と対応体制
社内で技術的な判断ができない場合でも、次の2点を明確にしておくことが重要です。
- 誰に連絡すれば更新状況が分かるのか
- 緊急時に誰が対応するのか
この体制が整っていれば、緊急時にも確認から作業までを進めやすくなります。
ホームページを安心して運用するために、制作後の保守と更新の体制まで整えておきましょう。
8. Webサイトの保守やセキュリティ対策のご相談
株式会社PieceInnovationは、愛知県岡崎市を拠点に、ホームページ制作、システム開発、運用保守、ITコンサルティングを行っています。[5]
次のようなお悩みをお持ちの企業様は、お気軽にご相談ください。
- 自社サイトが今回の脆弱性の対象か分からない
- 管理会社からの説明を整理したい
- PHPのバージョンアップを相談したい
- Webサイトのセキュリティ対策を見直したい
- 今後の保守・運用体制を整えたい
現在の構成や管理状況を伺い、必要な確認事項と進め方を整理します。
お問い合わせの際は、以下の情報を分かる範囲でお知らせいただくと、確認がスムーズです。
- 対象サイトのURL
- 利用中のサーバー会社
- 現在のPHPバージョン
Webサイトの保守・セキュリティ対策を相談する
参考情報・出典
本記事は、2026年10月21日時点のPHP公式情報に基づいています。
更新作業の際は、PHP公式および利用中のサーバー提供元の最新情報をご確認ください。