PHP の緊急脆弱性 (CVE-2026-109618 / 109619) への対応報告。公式の修正が出ない PHP 8.1 の API 3 台を、公開翌日に止めずに更新しました
2026 年 10 月 21 日の夜、PHP に深刻度 9.2 (CVSS v4.0) のリモートコード実行の脆弱性 2 件 (CVE-2026-109618 / CVE-2026-109619) の修正版が公開されました。攻撃はすでに観測されていて、国内でも大手サービスが緊急メンテナンスに入り、国のサイバー統括室が注意喚起を出す規模でした。
当社が保守している、不動産関連の 3 事業の API (VPS 3 台、Laravel 8) と、レンタルサーバー上のサイトも対象でした。結論から書くと、公開翌日の 10 月 22 日に 3 台とも修正版へ更新を完了し、サービスの停止は再起動の数秒だけでした。この記事は、その対応の報告です。影響範囲の調べ方、公式の修正が出ない PHP 8.1 をどう更新したか、止めずに更新するための確認の順番を、実際の作業どおりに書きます。技術的な手順も載せていますが、読んでほしいのは「誰が、どの順番で判断したか」です。
修正版が出たのは PHP 8.2 以降。8.1 以前には公式の修正がない
公開された修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です。PHP 8.1 以前はサポートが終了しているため、公式の修正はありません。8.1 を動かしている環境は、remi などの配布元が独自に用意した修正版に入れ替えるか、8.2 以降へ上げるかのどちらかになります。
ここが今回の一番の落とし穴です。「PHP を最新にする」で済むのは、すでに 8.2 以降を動かしている環境だけです。PHP の各バージョンのサポート期限と、期限が切れた PHP に何が起きるかは、PHP のサポート期限一覧にまとめています。
影響範囲の調べ方: サーバーごとに「誰が PHP を管理しているか」で分ける
最初にやったのは、自分たちが関わるサーバーを「PHP を誰が管理しているか」で分けることです。
| サーバー | PHP のバージョン | 管理者 | 対応 |
|---|---|---|---|
| レンタルサーバー (ConoHa WING) のサイト | 8.3 | 提供元 | 提供元がパッチを当てる。待つだけ |
| 事業 A の API (VPS) | 8.1.27 | 自社 | 公式の修正なし。配布元の修正版へ |
| 事業 B の API (VPS) | 8.1.27 | 自社 | 同上 |
| 事業 C の API (VPS) | 8.1.34 | 自社 | 同上 (修正前のバージョン) |
レンタルサーバーは、提供元が PHP 本体を管理しているので、利用者側でできることはありません (提供元の告知を確認して待ちます)。VPS は自社で入れた PHP なので、自分で更新するしかありません。この切り分けを先にしておくと、「どこを急ぐか」が決まります。
更新前に確認したこと: 古い Laravel が新しい PHP で動くか
3 台の API は Laravel 8 (8.83.27) です。PHP を入れ替えて API が動かなくなっては本末転倒なので、更新前に 3 つを確認しました。
- 同じ構成で動いている実績があるか。 事業 C の API は、同じ Laravel 8.83.27 が PHP 8.1.34 で約 7 か月半、問題なく稼働していました。8.1.27 から 8.1.34 への更新は、この実績で安全と判断できます。
- PHP と拡張の要件を満たすか。 事業 A で
composer check-platform-reqsを実行し、Laravel と依存パッケージが要求する PHP のバージョンと拡張がすべて合格することを確認しました。 - 差分がセキュリティ修正だけか。 8.1.27 から 8.1.34-6 までの変更点を確認し、すべてセキュリティ修正で、API の動作に影響するものがないことを確認しました。
この 3 つがそろったので、更新に進みました。
更新の手順: バックアップ、暫定策、入れ替え、再起動
事業 A の API での実際の手順です。17:15 に始めて 17:17 に完了しました。
- バックアップ。 PHP の設定ファイルとインストール済みパッケージの一覧を固めて
/root/php-backup-20261022.tar.gzに保存。戻すときの手がかりにします。 - 暫定策の設定を先に入れる。 PHP の追加設定ファイルを作り、次を設定。入れ替えに失敗しても、攻撃の入口を狭めておくためです。
session.upload_progress.enabled = 0 session.use_strict_mode = 1 - PHP を配布元の修正版に入れ替える。 remi の 8.1.34-6 (今回の CVE の修正入り) に更新し、php-fpm を再起動。API が止まるのはこの再起動の数秒だけです。
- 確認。
- 入れ替わった PHP に今回の CVE の修正が含まれていることを確認
- API の応答が更新前と完全に同じことを確認
- 更新後に新しいエラーが出ていないことを確認
事業 B と事業 C の API も、同じ日に同じ手順で更新を完了しました。3 台とも、停止は php-fpm の再起動の数秒だけです。
「誰がパッチを当てるか」が決まっていないサイトの問題
今回の作業で、技術的に難しいことは何もありません。難しかったのは、速さと判断です。公開から 1 日以内に、対象のサーバーを全部洗い出し、古い Laravel が動くことを確かめ、公式の修正がないバージョンをどう更新するかを決めて、実行する。これができたのは、3 台とも当社が日常的に保守していて、構成と依存関係を把握していたからです。保守とは、月次の点検のことではなく、こういう日に即日で動ける状態を保っておくことだと考えています。
逆に言うと、次の状態のサイトは、今回のような日に誰もパッチを当てられません。
- 作った会社や担当者がもういない。サーバーの構成や PHP のバージョンを誰も把握していない
- レンタルサーバーだと思っていたが、実は VPS で、PHP は自分で入れたものだった
- 古いフレームワークで動いていて、PHP を上げると動くかどうか誰にも分からない
脆弱性そのものは、いずれ直ります。直らないのは「誰が、いつ、何を確認して当てるか」が決まっていない状態です。
当社では、作って終わりではなく、今回のような緊急の更新まで含めた保守を前提に、業務システムや Web サービスの開発をお手伝いしています。自社のサーバーで PHP を誰が管理しているか分からない、更新できる人がいないという場合は、影響があるかどうかの確認からご相談ください。「作った人がいなくなったシステム」の引き継ぎもお受けしています。緊急対応の内容と料金をご覧いただくか、お問い合わせフォーム、または LINE 公式アカウントからどうぞ。
