BrefがPHP修正版のLambdaレイヤーを公開｜再デプロイと本番への反映を確認する

Brefが、今回のPHP重大脆弱性を修正したLambdaレイヤーとDockerイメージの公開を案内しました。サーバーレスだからPHPの更新作業がなくなるわけではありません。新しいレイヤーが配布されても、利用者の関数が古いレイヤーを参照していれば、稼働する環境は別に確認が必要です。

Brefの10月21日付セキュリティ告知を2026年10月22日に確認しました。本記事はCVE-2026-109618・CVE-2026-109619への対応のうち、LambdaでPHPを動かすBref利用者の再デプロイと反映確認を扱います。通常のVPSへパッケージを入れる手順とは区別し、提供元が実施したことと利用者の作業を分けます。

修正済みレイヤーの公開と関数への適用は別

Brefは、PHPの修正版を含むBref 3のレイヤーとDockerイメージを、全リージョンへ公開したと説明しています。Bref 3ではbref/bref 3.0.14以降への更新と再デプロイを案内しています。これは既存の全関数が自動で切り替わったという発表ではありません。

同告知にあるBref 3の新しいレイヤー版は、PHP 8.5がphp-85:21、8.4がphp-84:24、8.3がphp-83:24、8.2がphp-82:26です。これらは告知で示されたレイヤー識別子の末尾を含む表記です。実際のARNではリージョンやCPUアーキテクチャーも照合してください。

AWSのレイヤー資料は、各レイヤー版が変更されないスナップショットであり、関数には使う版のARNを指定すると説明しています。この仕組みを踏まえると、提供元に新しい版が存在することだけでは、手元の関数が参照する版を証明できません。

本サイトでは、対応記録を「修正版が配布された」「設定が新しい版を指す」「本番へ反映された」の三段階で残すことを勧めます。Composerの更新結果と、AWS上の関数設定を別々に保存すると、途中で止まっている工程を発見しやすくなります。

レイヤー方式では依存関係とデプロイ設定を確認する

Brefが示す基本の更新手順は、次のとおりです。実行前に対象プロジェクトとステージを確認し、普段のデプロイ手順へ組み込んでください。ここにあるコマンドは、利用者のAWS環境で本サイトが実行したものではありません。

composer update bref/bref -W
serverless deploy

-WはBref自身の依存関係も更新するために付けると告知されています。更新後はcomposer.lockの差分を確認し、対象外の変更まで含まれていないかをレビューします。検証環境へ展開したものと同じ依存関係を、本番の成果物で再現できる形にしてください。

レイヤーARNを直接記載している場合は、Composerの更新だけで設定が書き換わると考えないでください。Brefはその構成向けに最新ARNの確認先を案内しています。IaC、ステージ別設定、別アカウントの複製など、実際にデプロイへ使う設定を探します。

環境名を似た文字列で管理しているチームでは、作業前にアカウント、リージョン、ステージ、関数名を一組で確認します。更新に成功したものの検証環境だけだった、という状態を避けるためです。画面の成功表示だけで本番全体の完了にしないようにします。

AWS上の設定を読み戻して確かめる

Brefの告知は、get-function-configurationでレイヤーを確認する方法を示しています。次は読み取り用の例です。my-functionは自分が確認する関数名に置き換え、AWS CLIのアカウントとリージョンが対象と一致することを先に確かめます。

aws lambda get-function-configuration --function-name my-function --query Layers

得られたARNのレイヤー名、版、リージョンを、実際に使うBrefの系列と照合します。複数のレイヤーを使っているなら、配列に何かが表示されたというだけで終えず、PHPランタイムに該当するものを特定します。出力を共有するときは、必要な範囲だけをチーム内の記録へ残します。

本サイトの提案は、更新前後の関数設定とデプロイ記録を対にする方法です。関数名だけでなく、リリースの識別子や実施時刻を付けると、複数人が作業しても対応が混ざりにくくなります。想定した版と異なる結果なら、再デプロイの前に、どの設定が最終成果物へ入ったかを調べます。

エイリアスと呼び出し元を確認対象に入れる

AWSのエイリアス資料によると、エイリアスは関数のバージョンを指し、二つの版へトラフィックを分けることもできます。新しい関数版を用意することと、利用者のリクエストがその版へ向かうことは別です。

仮想例として、検証用に新しい版を発行し、本番用エイリアスが以前の版を参照したままの構成を考えます。この場合、新しい版のテストに成功しても、本番の呼び出し経路を確認したことにはなりません。重み付きの配分を使う場合は、旧版へ残る割合も確認項目に入れます。

API、Webhook、定期処理、キューの購読など、どこから呼ばれるかを一覧にします。すべてが同じエイリアスを使うとは限らないためです。再デプロイ後は、実際の呼び出し経路から代表的な処理を実行し、想定した版へ到達しているかを運用情報と照合します。

Docker方式ではベースの再取得と再展開が必要

Brefの告知は、ローカルのビルドキャッシュに古いベースイメージが残る点を注意し、再取得しながらビルドして、イメージをプッシュし再デプロイするよう案内しています。説明用のビルド例は次のとおりです。my-appは記事中の仮のイメージ名です。

docker build --pull -t my-app .

ただし、ダイジェストを固定したDockerfileでは、その固定先の見直しも必要です。タグ名が同じでも内容が更新される場合と、固定した内容を意図的に使い続ける場合を分けます。--pullを付ければ、どんな固定参照も自動で修正済みへ変わるという意味ではありません。

AWSのコンテナイメージ資料も、更新されたベースを利用するにはコンテナイメージを再ビルドし、関数コードを更新すると説明しています。レジストリーへ成果物を置いた段階と、Lambda側へ反映した段階を分けて記録します。

再展開するイメージは、ベースの参照、ビルド時刻、アプリのコミット、成果物のダイジェストを対応させます。CIが成功した後に別の古いタグを指定してしまう取り違えを防ぐためです。ローカルのphp -vではなく、実際に配った成果物を確認してください。

Web用と長時間プロセスの扱いを混同しない

BrefはPHP-FPMランタイムを優先更新の対象として挙げています。一方、Function runtimeやLaravel Octane、コンソール、キューワーカーで使うCLIは、PHPが説明した攻撃経路とは異なると整理しつつ、これらも更新するよう案内しています。異なる条件の説明を、全関数への更新不要の宣言として使わないでください。

運用上は、公開Web関数を優先しながら、残る関数も対象台帳へ入れます。処理の重要度と露出が違うなら、実施順序を変えられます。しかし、影響評価が終わっていない関数を、単に呼び出し頻度が低いという理由で対応済みにはできません。

本サイトでは、HTTPの代表操作に加え、キューや定期処理は重複実行を避けられる方法で試すことを勧めます。更新確認のために本番通知を大量に送ったり、決済処理を無計画に再実行したりしないよう、既存の検証手順を利用してください。

Bref Cloudや旧系列も利用形態を確認する

今回の告知はBref Cloudについて、基盤の更新後の次回デプロイで新しいレイヤーを使うという案内を含みます。本記事では、各利用者のCloudアプリが既に展開済みかまでは確認していません。管理サービスを利用していても、最後のデプロイと実行版を照合します。

Bref 2向けにも修正版の提供が案内されていますが、Bref 1のレイヤーは再ビルドしないとされています。既存システムがどの系列を使うかを先に特定し、自分の系列に対応した公式の更新案内へ進みます。新系列への大きな移行と、今すぐ実施できる修正適用を混同しないことが必要です。

完了の証拠をリリース記録へまとめる

完了条件の例は、対象関数の一覧があること、修正済みランタイムを参照すること、必要なデプロイが完了したこと、エイリアスや呼び出し経路を確認したことです。さらに代表機能の結果と、未確認のステージ・リージョンを残します。

切り戻しも注意が必要です。動作不良に対応して古い成果物へ戻すと、PHPの修正も戻る可能性があります。修正済みランタイムのまま使える代替成果物や、一時的な機能制限を検討し、通常のロールバック手順が今回も安全かを確認してください。

この対応の中心は、提供元の公開速度を評価することではなく、自分の本番関数へ新しい実体が届いたと確認することです。サーバーレスでも、参照するランタイムとデプロイの責任を可視化する作業は残ります。

関連記事

• PHP重大RCEの修正版と更新対象を確認する：通常のサーバーも含む脆弱性の全体像を扱います。
• 国内ホスティング各社のPHP緊急修正対応：事業者の対応完了と利用者側の確認を分ける参考記事です。