CoolifyがPHP重大脆弱性を修正｜管理基盤と公開アプリを別々に更新する

Coolifyは、今回のPHP重大脆弱性に対応した修正版を公開し、セルフホスト利用者へ更新を呼びかけています。重要なのは、Coolify自体の更新と、Coolifyから展開したPHPアプリの更新が別の作業だという点です。管理画面が修正済みでも、アプリのコンテナ内にあるPHPまで自動で更新されたとは限りません。

Coolify公式のPHPセキュリティ告知を2026年10月22日に確認しました。告知の最終更新日は10月21日です。本記事はCVE-2026-109618・CVE-2026-109619への対応を、デプロイ基盤とアプリの責任範囲から整理します。以下の台帳や確認方法は、本サイトの運用上の提案です。

セルフホストはCoolifyの版を先に確認する

公式告知では、未修正のCoolify v4各系列が影響対象とされ、可能ならv4.4.7への移行が推奨されています。既存のマイナー系列を維持する場合に備え、系列ごとの修正版も示されています。

利用中の系列	最初の修正済みリリース
v4.0.x	v4.0.1
v4.1.x	v4.1.3
v4.2.x	v4.2.1
v4.3.x	v4.3.24
v4.4.x	v4.4.7

この表は、今回のPHP脆弱性に対する修正の境界です。Coolifyは、旧マイナー系列にとどまると、バックポートされていない別のセキュリティ修正を受け取れない点にも注意しています。今回の修正版に達したことと、他の問題も含めた最新状態を同じ意味で扱わないでください。

本サイトでは、運用中の版を記録してから、緊急の修正適用と、推奨版への移行予定を分けて管理することを勧めます。旧系列を一時的に維持するなら、その理由と見直し日を残します。判断が必要な差分を、単に「更新済み」という一語で隠さないためです。

更新経路は稼働状態と系列によって違う

公式告知は、v4.4利用者には管理画面のSettingsからUpdateへ進み、更新を確認してv4.4.7を適用する経路を案内しています。操作前に対象インスタンスの識別情報と現在の版を確認し、別の検証環境を更新した結果と取り違えないようにします。

v4.0からv4.3の安定版を維持する場合には、公式のパッチスクリプトも案内されています。ただし、その経路は稼働中の安定版が対象で、ベータ、RC、nightlyには対応しないとされています。手順の名前が同じ更新作業でも、どの状態で使えるかが異なります。

停止済みの安定版には、未修正版を先に起動せず、端末からv4.4.7へ更新する経路が用意されています。古い系列を維持するために起動が必要な場合には、公開アクセスを隔離した状態で作業するよう案内されています。記事中の断片だけをコピーせず、公式の更新手順と、自分の状態に対応する告知の節を照合してください。

ベータなど旧構成の復旧も、通常の安定版更新とは分けて扱います。保守担当へ相談する際は、現在の版、稼働・停止の状態、公開経路、バックアップの有無を渡すと、適用できる経路を特定しやすくなります。対象が違うスクリプトを繰り返して試す方法は避けます。

Cloudの修正済み表示をアプリへ広げない

Coolifyは、Coolify Cloudの基盤は修正済みと説明しています。Cloud利用者がセルフホスト向けのインスタンス更新コマンドを実行する必要はありません。一方で、利用者のサーバーへ展開したPHPアプリは別に対応する必要があると明記しています。

セルフホストでも、この分離は同じです。Coolifyの管理コンテナと、アプリの実行コンテナでは、使うイメージや更新のタイミングが違います。基盤側の修正完了を受け取ったら、それを全リソースの完了へ読み替えず、アプリごとのランタイムを調べます。

確認する対象	完了を説明するための記録例
Coolify基盤	修正済みの版、更新結果、管理画面の動作
PHPアプリ	ベースイメージや配布元、PHPの修正版、再展開結果
本番への経路	公開ドメイン、稼働するアプリ、確認した時刻

この表は本サイトの提案です。Coolify側で表示されるアプリ名と、コンテナ、公開ドメインを結び付けると、同じリポジトリーから作った別環境を見落としにくくなります。ステージングだけ更新した状態を、本番対応済みとして報告しないためにも役立ちます。

アプリはビルド元から稼働実体まで追う

PHPアプリを更新するときは、どこでPHPが組み込まれるかを確認します。Dockerfileのベース、ビルド設定、独自イメージなど、実際の構成によって更新箇所が異なります。Coolifyの版を上げる操作だけで、利用者のリポジトリーや固定したベース参照まで変更されるとは考えないでください。

本サイトが勧める順序は、まず実行環境の配布元を特定し、その配布元の修正を確認してから、必要な再ビルド・再デプロイを行う流れです。タグやダイジェストを固定している場合は、その参照先の見直しも含めます。取得元が不明なまま上流PHPの数字だけを当てはめると、判定を誤る可能性があります。

仮想例として、Coolifyを修正版へ更新した後も、アプリが以前に作成したコンテナイメージを使い続ける構成を考えます。管理画面の更新成功は、そのイメージに修正済みPHPが入ったことを証明しません。アプリのリリース記録と、稼働している成果物を別に照合する必要があります。

再展開後は、ビルドした成果物と本番へ配置した成果物の識別子を対応させます。CIの成功、レジストリーへの登録、実際の配備は、それぞれ確認する段階が違います。PHPの情報も、管理用ホストのシェルではなく、対象アプリの実体について取得してください。

一時停止の影響は管理基盤と稼働サービスで違う

すぐ更新できない場合、公式告知は未修正のCoolifyを停止または隔離する一時的な対応を説明しています。Coolifyの停止は、管理画面、API、Webhookによるデプロイ、基盤のバックグラウンド処理へ影響します。一方、既に展開したアプリやデータベースなどは稼働を続けるとされています。

この説明を、Docker全体やプロキシ、アプリ群をまとめて止める手順と取り違えないことが必要です。また、基盤を止めたことで、公開中のPHPアプリまで脆弱性から保護されたとは判断できません。隔離の対象と、まだインターネットから到達する対象を分けます。

停止中には自動更新や該当パッチスクリプトが動作しない点も、告知で注意されています。作業計画では、停止という暫定状態から、修正版を適用して確認し、必要な公開経路を戻すまでを一連の工程にしてください。停止したまま担当が不明になる状態も避ける必要があります。

WAFを使う場合もアプリの修正は残る

WAFは更新準備中の緩和策になり得ますが、PHPやCoolifyのコードを修正するものではありません。Coolifyの告知も、既知の経路を対象としたフィルターに、あらゆる経路への保護を期待しないよう説明しています。オリジンサーバーへ直接到達する経路がある場合も別の確認が必要です。

本記事は、特定のアプリで攻撃や侵害を確認したという報告ではありません。公開情報から、自分の基盤とアプリへ修正を届ける作業を整理したものです。攻撃通信の観測と侵害の成立、設定変更と修正適用は、それぞれ区別してください。

WAF側の検討を始める場合は、末尾の関連記事で、対象となる通信経路と調査の考え方を確認できます。ここではその説明を繰り返さず、更新対象が基盤とアプリに分かれる点を中心に扱っています。

ロールバック用の成果物も見直す

本サイトでは、アプリを戻すために保存した旧イメージも確認対象にすることを勧めます。管理基盤の版を維持したままでも、古いPHPを含むアプリイメージへ切り戻せば、アプリ側の修正を失う可能性があります。

復旧候補は、アプリの変更とPHPの修正を分けて記録します。修正済みのランタイムを使った代替成果物を用意できるか、難しい場合は公開範囲を制限して対処するかを担当者と決めます。古いイメージの保管と、本番へ戻してよいという判断は別です。

復旧後は管理機能とアプリ機能の両方を試す

本サイトの確認項目は、基盤の版を読み戻すこと、管理画面を利用できること、必要なデプロイ経路が回復したこと、PHPアプリの代表機能が動くことです。更新中のデプロイへ影響する可能性もあるため、Coolifyの更新ガイドに沿い、実行中の作業と復旧手段を確認します。

アプリ側では、トップページに加え、認証、フォーム、管理画面、ジョブなど、そのサービスで重要な操作を選びます。外部への通知や決済を伴う処理は、通常の試験手順に従って重複実行を避けます。本サイトが読者の環境で動作確認したという意味ではありません。

最後に未確認のアプリ、残る旧系列、次の作業担当を明記します。「Coolifyは修正済み」と「すべてのPHPアプリへの適用を確認済み」を、別の行で報告できる状態が望まれます。基盤の更新を起点に、公開サービスまで確認範囲をたどることが今回の対応の要点です。

関連記事

• PHP重大RCEの修正版と更新対象を確認する：今回の脆弱性とPHP側の修正版を整理しています。
• CloudflareのPHP攻撃通信観測とWAFの確認範囲：WAFの保護経路と調査範囲を検討する参考記事です。