developersIO
CVE-2026-111497に対するAWS Lambdaのランタイム更新を確かめてみた

CVE-2026-111497に対するAWS Lambdaのランタイム更新を確かめてみた

CVE-2026-111497（HTTP2Shell）というBrotliの脆弱性に対して、AWS Lambdaのマネージドランタイムが修正版を展開しています。 本ブログではNode.js 24を対象に実際に確認してみました。
AWSAWS Lambda
あかいけ
2026.10.30

はじめに

皆様こんにちは、あかいけです。

AWSのセキュリティ情報によると、Brotliの脆弱性CVE-2026-111497（通称HTTP2Shell）の修正版は、AWS Lambdaのマネージドランタイムに「フェーズ1」と「フェーズ2」の2段階で展開されるそうです。

https://aws.amazon.com/security/security-bulletins/2026-155-aws/

本ブログでは実際にNode.jsの関数で両方のフェーズと、フェーズ2を待たずに修正版を取り込む方法を試してみました。

前提条件

本記事は執筆時点の情報です。
最新の状況は公式情報をご確認ください

  • 検証日時：2026年10月30日の18時頃（日本時間）
  • 検証環境：
    • リージョン：東京リージョン（ap-northeast-1）
    • ランタイム：Node.js 24（nodejs24.x）、アーキテクチャはx86_64
    • デプロイ方式：ZIPパッケージ

ざっくり概要

CVE-2026-111497とは

CVE-2026-111497は、Googleが開発している圧縮形式Brotliのデコーダ（解凍処理）に見つかったバッファオーバーフローの脆弱性です。
細工した圧縮データを解凍させることで、任意のコードを実行したり、プロセスのメモリを読み取ったりできるおそれがあります。
また原因はBrotliのデコーダ自体にあるため、Brotliで解凍処理を行う他の言語やアプリケーションにも影響があります。

https://aws.amazon.com/security/security-bulletins/2026-155-aws/

なお米国のCISAは2026年10月27日に、この脆弱性を悪用が確認された脆弱性のカタログ（KEV）に追加しています。

https://www.cisa.gov/known-exploited-vulnerabilities-catalog

AWS Lambdaの対応方針

AWSは2026年10月28日にセキュリティ情報（2026-155-AWS）を公開しています。
ここでは各種AWSサービスの対応方針が整理されており、Lambdaについての記載を要約すると次のとおりです。

  • Lambdaのサービス自体は影響を受けない
  • Node.jsと.NETのランタイムは影響を受ける
  • Python、Ruby、OS専用ランタイム（provided.al2023）は、Brotliライブラリを含まない
    • ただし、関数のデプロイパッケージやレイヤーとしてBrotliライブラリを含めている場合は、修正してデプロイすることが推奨されています

ランタイムごとの対応状況は次のとおりです。
（2026年10月29日のページ最終更新時点）

ランタイム コンテナのベースイメージ ZIPのフェーズ1 ZIPのフェーズ2
Node.js 22、24、26 更新済み 完了 2026年10月30日
.NET 8、9（コンテナのみ）、10 更新済み 完了 2026年10月31日

https://aws.amazon.com/security/security-bulletins/2026-155-aws/

フェーズ1とフェーズ2の違い

ZIPパッケージの関数では、マネージドランタイムの修正版が次の2段階で展開されます。

  • フェーズ1
    • 関数を作成または更新したとき（UpdateFunctionCodeやUpdateFunctionConfigurationの呼び出し時）に、修正版のランタイムが適用される
  • フェーズ2
    • 更新モードがAutoで、まだ修正版になっていない関数に、Lambdaが自動で適用する

ここでいう更新モードは、関数ごとのランタイム管理設定のことです。
ランタイム管理設定にはAuto（既定値）、Function update、Manualの3つがあります。

Function updateの関数は、関数を更新したときにだけ修正版になります。
Manualの関数は、どちらのフェーズでも修正版になりません。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html

修正版かどうかの見分け方

セキュリティ情報によると、修正版が適用されたかどうかは、関数ログのINIT_STARTの行に出るランタイムバージョンで判断できます。
INIT_STARTは、実行環境がコールドスタートするたびに出力されます。

ランタイム 修正版のランタイムバージョン
Node.js 22 nodejs:22.mainline.v157以上
Node.js 24 nodejs:24.mainline.v114以上
.NET 8 dotnet:8.mainline.v165以上
.NET 10 dotnet:10.mainline.v113以上

https://aws.amazon.com/security/security-bulletins/2026-155-aws/

なお、Node.js 24ではprocess.versionに修正が反映されないとも書かれています。
これは後ほど実際に確かめてみます。

フェーズ1を試してみる（新規作成した関数）

フェーズ1は、関数を作成または更z新したときに修正版を適用する段階です。
セキュリティ情報ではすでに完了となっているので、新しく関数を作れば修正版のランタイムになるはずです。

関数を作成する

次のコードで、ランタイムがnodejs24.xの関数を新規作成しました。
Node.jsのバージョンと、Node.jsに組み込まれているBrotliのバージョンをログに出力するだけの関数です。

index.mjs
export const handler = async () => {
  const info = {
    nodeVersion: process.version,
    brotliVersion: process.versions.brotli,
    executionEnv: process.env.AWS_EXECUTION_ENV,
  };
  console.log(JSON.stringify(info));
  return info;
};

フェーズ1は関数を作成した時点で適用されるので、作成の方法はマネジメントコンソールでもAWS CLIでも構いません。
更新モードは既定値のAutoのままにしています。

INIT_STARTを確認する

作成した関数を1回呼び出して、Amazon CloudWatch Logsのログを確認しました。

INIT_START Runtime Version: nodejs:24.mainline.v114	Runtime Version ARN: arn:aws:lambda:ap-northeast-1::runtime:2810f32b3d68c5c2f8ddf47c28f8a7f2655c51ab3a3dbbce37a7dacd8d9e299c
START RequestId: ce7626a1-49ba-41fd-b0e3-f758f6373ad0 Version: $LATEST
2026-10-30T09:07:52.176Z	ce7626a1-49ba-41fd-b0e3-f758f6373ad0	INFO	{"nodeVersion":"v24.21.0","brotliVersion":"1.2.0","executionEnv":"AWS_Lambda_nodejs24.x"}
END RequestId: ce7626a1-49ba-41fd-b0e3-f758f6373ad0
REPORT RequestId: ce7626a1-49ba-41fd-b0e3-f758f6373ad0	Duration: 37.83 ms	Billed Duration: 172 ms	Memory Size: 128 MB	Max Memory Used: 75 MB	Init Duration: 133.44 ms

INIT_STARTのランタイムバージョンはnodejs:24.mainline.v114でした。
修正版の基準（v114以上）を満たしているので、新規作成した関数にはフェーズ1で修正版が適用されていました。

process.versionでは判断できない

一方で、同じ呼び出しでコードから出力したログは次のとおりでした。

2026-10-30T09:07:52.176Z	ce7626a1-49ba-41fd-b0e3-f758f6373ad0	INFO	{"nodeVersion":"v24.21.0","brotliVersion":"1.2.0","executionEnv":"AWS_Lambda_nodejs24.x"}

process.versionはv24.21.0、process.versions.brotliは1.2.0でした。
Node.js 24系の修正版は24.22.1ですが、process.versionは24.21.0のままです。
セキュリティ情報によると、Node.js 24.22.1には既知の不具合（リグレッション）があるため、AWSは最新リリースに上げるのではなく、現在の安定版に対象を絞った修正を当てているそうです。

https://aws.amazon.com/security/security-bulletins/2026-155-aws/

Brotliのバージョン表記も、Brotli本家の修正版である1.2.1ではなく、1.2.0のままでした。

https://github.com/google/brotli/releases/tag/v1.2.1

つまりNode.js 24では、コードから取得できるバージョンで修正の有無を判断できません。
確認にはINIT_STARTのランタイムバージョンを使う必要があります。

フェーズ2を試してみる（既存の関数）

フェーズ2は、更新モードがAutoの既存の関数に、Lambdaが自動で修正版を適用する段階です。
Node.jsのフェーズ2は2026年10月30日の予定で、ちょうど検証当日にあたります。

検証には、最終更新が2026年8月の既存の関数を使いました。
Hello Worldを返すだけの関数で、ロググループが存在しなかったので、これまで一度も呼び出していなかったようです。

更新モードを確認する

まずは更新モードを確認します。

aws lambda get-runtime-management-config \
  --function-name <関数名> \
  --query UpdateRuntimeOn --output text

Auto

既定値のAutoだったので、フェーズ2の対象になるはずです。

INIT_STARTを確認する

次に、関数を1回呼び出してINIT_STARTを確認しました。
（18時13分頃）

INIT_START Runtime Version: nodejs:24.mainline.v55	Runtime Version ARN: arn:aws:lambda:ap-northeast-1::runtime:3f2695d917b249350567df30dd784ee6b9547bbdb635b4c188153c39b5347c8b

ランタイムバージョンはnodejs:24.mainline.v55で、修正版の基準（v114以上）より古いままでした。
この時点では、少なくともこの関数にはまだフェーズ2で修正版が適用されていないようです。

フェーズ2を待たずに修正版を取り込んでみる

18時15分頃の時点では、既存の関数に修正版が自動で適用されていませんでした。
そこで、セキュリティ情報に書かれている方法で、フェーズ2を待たずに修正版を取り込んでみます。

フェーズ1が完了していれば、関数のコードか設定を更新した時点で修正版が適用されます（更新モードがManualの関数を除く）。
ただし、セキュリティ情報には、変更を伴わない更新では適用されないと書かれています。
そのため実際に何かを変更する必要があり、手軽なのは環境変数を1つ追加する方法です。
セキュリティ情報には、既存の環境変数を残したままTRIGGER_RUNTIME_UPDATEという環境変数を追加するAWS CLIのスクリプトが載っています。

https://aws.amazon.com/security/security-bulletins/2026-155-aws/

今回の関数には環境変数が1つもなかったので、TRIGGER_RUNTIME_UPDATE=1だけを追加しました（18時31分頃）。

aws lambda update-function-configuration \
  --function-name <関数名> \
  --environment "Variables={TRIGGER_RUNTIME_UPDATE=1}"

なお、--environmentは環境変数をまるごと置き換えます。
既存の環境変数がある関数では、セキュリティ情報のスクリプトを使って既存の値を残してください。

更新が完了してから関数を呼び出し、INIT_STARTを確認しました。

INIT_START Runtime Version: nodejs:24.mainline.v114	Runtime Version ARN: arn:aws:lambda:ap-northeast-1::runtime:2810f32b3d68c5c2f8ddf47c28f8a7f2655c51ab3a3dbbce37a7dacd8d9e299c

ランタイムバージョンがnodejs:24.mainline.v55からnodejs:24.mainline.v114に変わり、環境変数を1つ追加しただけで修正版になりました。
設定を更新してから数秒後の呼び出しで、すでに修正版のランタイムで起動していました。

補足: ランタイムバージョンARNによる確認

関数の設定にあるランタイムバージョンARNを比較してみます。

aws lambda get-function-configuration \
  --function-name <関数名> \
  --query RuntimeVersionConfig.RuntimeVersionArn --output text

以下の結果から、既存の関数のARNは、環境変数を追加したタイミングで、フェーズ1で新規作成した関数と同じ値に変わったことがわかります。

関数 INIT_STARTのランタイムバージョン ランタイムバージョンARN
新規作成した関数（フェーズ1） nodejs:24.mainline.v114 arn:aws:lambda:ap-northeast-1::runtime:2810f32b...
既存の関数（環境変数の追加前） nodejs:24.mainline.v55 arn:aws:lambda:ap-northeast-1::runtime:3f2695d9...
既存の関数（環境変数の追加後） nodejs:24.mainline.v114 arn:aws:lambda:ap-northeast-1::runtime:2810f32b...

そしてランタイムバージョンARNはランタイムバージョンごとに一意なので、新規作成した関数とARNを比べれば、呼び出さなくても修正版かどうかを確認できそうです。

なお、同じランタイムバージョンでもARNはリージョンとCPUアーキテクチャごとに異なるため、比べる関数はランタイム、リージョン、アーキテクチャを揃えて作成する必要があります。

ただし注意点として、これはAWSが案内している確認方法ではありません。そのため確実に確かめるなら、INIT_STARTのランタイムバージョンを見てください。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html

考慮事項

環境変数を追加して取り込むときの注意点

環境変数を追加して修正版を取り込むときは、次の点に注意が必要です。

  • 更新されるのは$LATESTだけです。エイリアスで公開済みバージョンを呼び出している場合は、更新後に新しいバージョンを発行し、エイリアスの向き先を切り替える必要があります
  • TerraformやCloudFormationなどで管理している関数をCLIで直接変更すると、コードと実環境に差分が出ます。IaCで管理している場合は、IaC側で変更してデプロイするほうがよいです

自動では修正版にならないケース

次のケースでは、フェーズ2を待っても修正版にならないので、利用者側での対応が必要です。

  • 更新モードがFunction updateまたはManualの関数
  • コンテナイメージの関数（最新のベースイメージで再ビルドし、再デプロイする必要があります）
  • 非推奨になったランタイム（Node.js 18、20など）の関数（セキュリティ更新の対象外です）

https://aws.amazon.com/security/security-bulletins/2026-155-aws/

さいごに

以上、CVE-2026-111497に対するAWS Lambdaのランタイム更新を、フェーズ1とフェーズ2で確かめてみた結果でした。

Node.js 24ではprocess.versionを見ても修正の有無がわからないので、修正版になったかを確かめるときはINIT_STARTのランタイムバージョンを見るようにしましょう。

同じ脆弱性の対応で困っている方の助けになれば幸いです。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

[アップデート] Amazon Inspector の Lambda 関数標準スキャンが .NET 10 と Node.js 24 をサポートしました
いわさ
2026.02.16
AL2023 で CVE-2026-98432 のカーネル更新を確認してみた（Linux カーネルの TCP の脆弱性）
suzuki.ryo
2026.10.30
必見の記事
AWS セキュリティ速報 2026-137-AWS（CVE-2026-99999）は通常の EC2 は対象外。影響範囲を確認してみた
suzuki.ryo
2026.10.17
AWS ParallelCluster の Slurm を CVE 対応の 25.11.8 にアップグレードしてみた
大村 保貴
2026.09.05