公式の告知が挙げているのは、次の2件です。どちらも、公式は「認証なしのリモートコード実行(RCE)につながりうる」としています。

• CVE-2026-109618／PHPは、メモリ不足になると処理を途中で打ち切ります。そのとき、メモリが「準備の途中」だと、壊れた状態のまま残り、後片付けの処理がそれを読んでしまいます
• CVE-2026-109619／1回のリクエストが使ったメモリを片付けたあとも、その場所を指す記録だけが残ります。次のリクエストが、その古い記録を使ってしまいます。GHSAは、これを解放後利用(Use After Free)と呼んでいます

どちらも、メモリの扱いの不具合を突かれる問題です。壊れたメモリや、片付け済みのメモリを使わせることで、攻撃者の用意した命令を動かせてしまうおそれがあります。GHSAが確認している影響は、ログイン不要でのコード実行(2件とも)と、メモリの内容の漏れ(2件目)です。

用語を整理します。

• リモートコード実行(RCE)／外部の第三者が、狙われたサーバー上で、自分の用意したプログラムを動かせてしまう状態です。脆弱性のなかでも、特に深刻なものに分類されます
• 認証不要／ログインしていない相手でも攻撃が成立する、という意味です。管理画面のパスワードを強くしても、これは防げません
• CVSS(深刻度の点数)／脆弱性の深刻さを10点満点で示す世界共通の物差しです。GHSAは、2件ともCVSS v4.0で9.2(Critical)としています。ネットワーク越しに攻撃でき、ログインも利用者の操作も要りません
• ワーカー／Webからのリクエストを実際に処理するPHPの担当(プロセス)です。サーバーには複数のワーカーが並んでいます
• CVE番号／脆弱性に付く世界共通の管理番号です。業者やサーバー会社への問い合わせでは、この番号を伝えると話が早くなります

公式の告知は、対象を「Webのリクエストを処理するすべてのPHP環境」としています。具体例として、次の5つが挙がっています。

• PHP-FPM／PHPを別の処理担当として動かす方式です
• Apache + mod_php／WebサーバーのApacheにPHPを組み込む方式です
• php-cgi／リクエストのたびにPHPを起動する古い方式です
• FrankenPHP／新しいPHP用のサーバーです
• LiteSpeed／高速なWebサーバーです

公式は、このうちmod_phpのリスクが最も高いとしています。認証なしのリクエストが、アプリケーションのコードが動く前に攻撃を発動できることが実証されているためです。GHSAは、初期設定のメモリ制限などの環境でも、完全なコード実行が確認されたと書いています。

方式による違いは、GHSAに次のように書かれています。

• FPM／1件目は、ソースの分析上は影響を受けるが、完全な攻撃はまだ実証されていません。2件目の「セッション経路」は、mod_phpとFPMの両方で実証されています
• FrankenPHP・LiteSpeed／FrankenPHPは影響を受けやすいとみられています。LiteSpeedは、攻撃が成り立つ可能性が高いものの、未検証とされています

次のようなものは、PHPで動いていることがあります。

• WordPressで作ったサイト／自社サイト、ブログ、採用ページなど
• 制作会社が作ったサイト・フォーム／ネットショップ、予約フォーム、会員サイトなど。作り方は会社によって違います
• 業務システム／請求書発行、見積、在庫、勤怠、経費精算など。PHPで作られているものがあります

PHPで動いているかどうかが分からないときは、次のPOINT 03のとおり、管理している相手に聞くのが確実です。

PHP本体を修正版にできるのは、そのPHPを管理している人だけです。WordPressの管理画面の「更新」ボタンは、WordPress本体・テーマ・プラグインの更新用で、PHPは更新できません。まず、自分のサイトやシステムが、次のどれに当たるかを確かめます。なお、ここは公式の告知ではなく、一般的な契約や運用の形にもとづく整理です。

• 誰が直すか／サーバーの運営会社です。多くの共用型のレンタルサーバーでは、PHP本体を修正版にできるのは運営会社だけで、利用者は触れません。利用者が触れるのは、運営会社が管理画面に用意した範囲(PHPのバージョンの切り替えなど)に限られます
• あなたがやること／運営会社のお知らせ(障害・メンテナンス情報)を確かめます。運営会社が「修正済みのバージョンを選べる」と案内したら、その手順に従って切り替えます。案内が出るまでは、POINT 06のバックアップを取って待ちます
• 注意／POINT 05の緩和策は、利用者が設定を変えられないことが多く、使えない場合があります

• 誰が直すか／サーバーを開発会社が契約しているなら開発会社、自社が契約していて保守を頼んでいるなら、保守の委託先です。誰が管理しているか分からないときは、契約書や請求書で確かめます
• あなたがやること／開発先に問い合わせます。「CVE-2026-109618とCVE-2026-109619への対応状況と、対応する予定日を教えてください」と聞きます。あわせて、この対応が保守契約の範囲に入るのか、費用がかかるのかも確かめます
• 注意／PHPのバージョンを上げると、古いプログラムが動かなくなることがあります。その場合は改修が必要になり、対応に時間がかかることがあります。いつまでに対応できるのかを、必ず聞いておきます

• 誰が直すか／自社です。クラウド上の仮想サーバーやVPSを借りている場合も、中のPHPの更新は、借りた側の作業になるのが一般的です
• あなたがやること／公式は、Linuxの提供元や長期サポートの業者には、パッチが事前に提供されたと書いています。提供元の更新済みパッケージを確かめて更新し、必要に応じてサービスを再起動します
• 注意／PHP 8.1以前を使っている場合は、提供元がバックポートを出しているかを確かめます(POINT 04)

• 誰が直すか／サービスの提供元です。利用者は、PHP本体を直せません。そのサービスがPHPを使っているかどうかも、利用者には分からないことがあります
• あなたがやること／提供元のお知らせを確かめます。対応状況が書かれていなければ、問い合わせます。利用者側でできる、パスワードの変更などは進めておきます(POINT 06)

• 請求書をたどる／サーバーの利用料、ドメインの更新料、保守費の請求書は、経理に届いているはずです。支払先が、サーバーの運営会社なのか、制作会社なのかで、誰が管理しているかが分かります
• 一覧にする／自社のサイトやシステムを、「名前・URL・管理している先・PHPのバージョン・対応状況」の表にします。Excelで十分です。管理している先ごとに、まとめて問い合わせられます

公式が示した修正版は、次のとおりです。GHSAは、影響を受ける版を「それぞれの修正版より前」としています。

• PHP 8.5／8.5.12に更新
• PHP 8.4／8.4.27に更新
• PHP 8.3／8.3.36に更新
• PHP 8.2／8.2.35に更新

公式は、PHP 8.1以前は、PHPプロジェクトからの更新の提供が終わっていると明記しています。ただし、次の2つの道があります。

• 提供元のバックポート／Linuxの提供元や、長期サポートを売る業者が、修正を古い版に取り込んで配っていることがあります。契約先に、対応の有無を問い合わせます
• 移行／サポート対象のバージョン(8.2以降)に上げます。古いプラグインやテーマが動かなくなることがあるため、事前にバックアップを取り、動作確認の時間を取ります

公式は、PHP 7.4・8.0・8.1向けにも、修正を移した最小限のソース(バックポート)を公開しました。古い版も、同じ問題を抱えていると考えるのが自然です(筆者の読みです)。ただし、これはソースからビルドする知識のある人向けで、レンタルサーバーの利用者が自分で当てるものではありません。

サーバー会社の管理画面(サーバーパネル)が開けないときでも、WordPressを使っているなら、WordPressの管理画面からPHPのバージョンを確かめられます。

• 手順／管理画面の「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」の欄に、PHPのバージョンが表示されます
• 見方／表示された番号を、上の修正版と見比べます。たとえば8.3系なら、8.3.36以上であれば修正版です

• 聞くこと／「私のサーバーのPHPには、CVE-2026-109618とCVE-2026-109619の修正は適用されていますか。まだなら、いつ適用されますか」
• 手元に用意するもの／契約しているサーバーの名前、使っているPHPのバージョン、対象のドメイン

公式は、すぐに更新できない場合の緩和策も示しています。ただし、次のように明記しています。

• memory_limit=-1にする／PHPのメモリ上限を外します。アプリケーション側で上限を戻されない設定(FPMのプール設定やApacheのphp_admin_valueなど)が望ましいとされています。ただし、公式は、根本的なメモリ確保の失敗は脆弱な経路に到達しうると書いています
• post_max_sizeを小さくする／ファイルのアップロードが不要なら8M、必要なら32Mにします。upload_max_filesizeはpost_max_sizeより小さくします
• Webサーバー側でも制限する／リクエストの大きさ、入力欄の数、ヘッダーの数などの上限を、Webサーバーやプロキシでも設けることを検討します
• フォーム形式の通信を手前で断る／GHSAは、アプリケーションが「multipart形式」(ファイルのアップロードなどに使う送信形式)を使わないなら、その通信をPHPに届く前にWebサーバーで断ることも挙げています。WordPressは、画像のアップロードなどでこの形式を使うため、そのまま断ると管理画面の機能が止まることがあります

• session.upload_progress.enabled=0にする／アップロードの進み具合を記録する機能を切ります。設定したあとは、すべてのワーカーの再起動が必要です
• PHP 8.5ではfatal_error_backtraces=0にする／致命的エラー時の追跡情報の出力を止めます。確認された経路だけをふさぎます
• 攻撃者が届く致命的エラーや実行時間切れを直す／アップロードや取り込みの処理の失敗などが対象です

レンタルサーバーでは、これらの設定を利用者が自由に変えられないことが多いと思います。しかも、レンタルサーバーで使える.user.iniは、上のとおり公式が「頼るな」としている方法です。設定で粘るより、運営会社の更新の連絡を待つほうが、現実的な選択になる場合があります。

PHPが修正版になっても、更新の前に、すでに侵入されていた場合は直りません。念のため、次の点を確かめておくと安心です。なお、これらは公式の告知が求めている手順ではなく、サイトを運営するうえでの一般的な確認です。

不審な点が見つかったときは、自分で直そうとして上書きせず、まず運営会社と、サイトを作った業者に相談します。会計データや取引先の情報を扱っているサイトであれば、専門の業者の判断を仰ぐ場面も考えられます。