FrankenPHPのDockerイメージに脆弱性、修正版1.1.11
FrankenPHPのDockerイメージが、Alpine・PHP・Goの修正を取り込まないまま配布され、古いライブラリ経由でコード実行を受けるおそれがありました。イメージを使う組織は1.1.11以降へ更新し、コンテナを作り直してください。
急ぎ度: 早めに
CVSS v3は9.8、v4は9.3と高い一方、修正版が出ており、対応はイメージの取り直しと再デプロイで済むため、早めの対応を勧めます。
関係があるか
FrankenPHPのDockerイメージ（dunglas/frankenphp）でPHPアプリを動かしている環境と、そのイメージをベースに自社イメージを作っている環境が対象です。1.1.11より前のイメージを取得したまま動かし続けていると影響を受けます。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| FrankenPHPのDockerイメージ（dunglas/frankenphp） | 1.1.11より前 | 1.1.11 |
| イメージに含まれるAlpineのシステムライブラリ（libcrypto3など） | Alpine側で修正済みの内容が未反映のイメージ | Alpine 3.20.9、3.21.6、3.22.3、3.23.3で修正された内容を取り込んだイメージ |
確かめ方
- 1Dockerfileの
FROM、docker-composeの設定、KubernetesのマニフェストからFrankenPHPのイメージ名とタグを洗い出します。 - 2各ホストとレジストリで、イメージの作成日時を確認します。タグが同じでも、古い時点で取得したままのイメージは修正を含みません。
- 3FrankenPHPをベースにした自社イメージは、いつ最後にビルドしたかを確認します。ベースを取り直さずにビルドしていると、古い層が残ります。
何が起きたか
FrankenPHPのDockerイメージが、Alpine・PHP・Goの更新に追いつかないまま配布され、古いシステムライブラリの既知の脆弱性が残った状態になっていました。外部の攻撃者がそれを悪用すると、コードを実行されるおそれがあります。
原因はFrankenPHP本体のコードではなく、イメージを作り直す仕組みです。ビルドが動くのは、ベースイメージに新しいタグができたときと、手動で起動したときだけでした。ところがAlpine、PHP、Goの公式イメージは、セキュリティ修正を既存のタグに上書きして配ることが多く、FrankenPHP側の再ビルドが走りませんでした。
勧告が具体例に挙げるのは、libcrypto3のCVE-2025-15467（リモートコード実行）です。Alpine 3.20.9、3.21.6、3.22.3、3.23.3で修正された内容が、FrankenPHPのイメージに届いていませんでした。分類は、CVEの記録がCWE-1395（脆弱なサードパーティ部品への依存）で、GitHubの勧告にはCWE-787（境界外書き込み）も付いています。
ベンダーは2026年2月4日にCI/CDを改めました。ベースイメージのダイジェストを毎日上流のレジストリと比べ、変化があればタグ名が同じでもFrankenPHPのイメージを自動で再ビルドして再公開します。
攻撃の流れ
-
1
上流が修正
Alpine・PHP・Goが、既存のタグのまま修正版のベースイメージを配ります。
-
2
再ビルドなし
新しいタグができないため、FrankenPHP側のビルドが動きません。
-
3
古い層が残る
修正前のライブラリを含むイメージが、そのまま配られ続けます。
-
4
既知の欠陥を狙う
ネットワーク越しに、残った既知の脆弱性が狙われるおそれがあります。
-
5
コード実行
悪用されると、コンテナ内でコードを実行されるおそれがあります。
どう悪用されるか
CVSSの評価では、ネットワーク越しに、認証なし・利用者の操作なしで悪用でき、攻撃の複雑さも低いとされています。実際に狙われるのは、イメージに残った古いライブラリの既知の脆弱性です。そのため、悪用できるかどうかは、個々の脆弱性ごとに条件が異なると考えられます。
悪用された場合は、コードの実行を通じて、情報の漏えい、データの改ざん、サービスの停止のいずれにもつながりえます。CVSSでも機密性・完全性・可用性の影響はいずれも高いとされています。
今すぐやること
-
1
使っているイメージを洗い出す
本番・検証・CIのすべてで、FrankenPHPのイメージとそれをベースにした自社イメージを一覧にします。ホストに残っているイメージの作成日時も見ておきます。
docker images dunglas/frankenphp -
2
1.1.11以降のイメージに更新して再デプロイする
使っているタグの最新のイメージを取得し、コンテナを新しいイメージで作り直します。コンテナの再起動だけでは、古いイメージのまま動き続けます。
docker pull dunglas/frankenphp:latest -
3
自社イメージはベースを取り直して再ビルドする
FrankenPHPをベースにしたイメージは、ベースを最新にして作り直し、レジストリに登録し直してから入れ替えます。
docker build --pull -t my-app . -
4
外部に公開していた環境は、ログも見ておく
更新が遅れていた期間に、インターネットに公開していたコンテナは、念のため不審な通信や想定外のプロセスの跡がないかを確認します。
すぐ更新できないとき
FrankenPHPの版をすぐに上げられない事情があるときは、使っているタグのまま取り直す方法でも、最新のベースレイヤーを取り込めます（勧告が示す回避策）。取得はdocker pull dunglas/frankenphp:latest、自社イメージのビルドはdocker build --pull -t my-app .です。その後、コンテナを作り直します。
背景
FrankenPHPは、GoのWebサーバーCaddyの上でPHPを動かすアプリケーションサーバーで、Dockerイメージとして配られることが多い製品です。HTTPの受け付けやTLSの処理もこのコンテナが担うため、インターネット側に直接さらされる構成も少なくありません。TLSの暗号処理を担うlibcrypto3の脆弱性が残っていれば、影響は小さくありません。
コンテナでは、アプリ本体より下の層にあるOSとライブラリの修正は、イメージを作り直さないと届きません。さらに今回のベースイメージは、修正を既存のタグに上書きして配っていました。タグ名が変わらないため、配布側も利用者側も、更新があったことに気づきにくい構図でした。
よくある質問
Q.タグにlatestを指定していても影響を受けますか。
Q.修正は2月なのに、CVEの公表が11月なのはなぜですか。
まだ分かっていないこと
- 修正前のイメージのうち、どのタグ・どの期間のものが古いライブラリを含んでいたかの一覧は示されていません。
- CVE-2025-15467のほかに、どの既知の脆弱性が古いイメージに残っていたかの一覧は示されていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| phpfrankenphp |
1.1.11 未満→ 1.1.11 |
1.1.11 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
FrankenPHP Docker images before 1.1.11 were rebuilt only when new base image tags were created, so security fixes that Alpine, PHP, and Go applied under existing tags were not propagated. Remote attackers could exploit known flaws in the stale system libraries, such as CVE-2025-15467 in libcrypto3, to execute code.
出典: CVE.org (CVE Program・cvelistV5) NVD