Introduction

Hello everyone, this is Akaike.

According to the AWS security bulletin, the fixed version for the Brotli vulnerability CVE-2026-111497 (nicknamed HTTP2Shell) will be rolled out to AWS Lambda managed runtimes in two stages: "Phase 1" and "Phase 2".

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

In this blog post, I tried out both phases on a Node.js function, as well as a way to pick up the fixed version without waiting for Phase 2.

Prerequisites

This article reflects information at the time of writing.
Please check the official information for the latest status.

• Verification date and time: around 18:00 on October 30, 2026 (Japan time)
• Verification environment:
  • Region: Tokyo Region (ap-northeast-1)
  • Runtime: Node.js 24 (nodejs24.x), x86_64 architecture
  • Deployment method: ZIP package

Quick Overview

What is CVE-2026-111497?

CVE-2026-111497 is a buffer overflow vulnerability found in the decoder (decompression process) of Brotli, a compression format developed by Google.
By having the decoder decompress specially crafted compressed data, it may be possible to execute arbitrary code or read process memory.
Also, because the cause lies in the Brotli decoder itself, other languages and applications that use Brotli for decompression are affected as well.

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

Additionally, the US CISA added this vulnerability to the Known Exploited Vulnerabilities catalog (KEV) on October 27, 2026.

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

AWS Lambda's Response Policy

AWS published a security bulletin (2026-155-AWS) on October 28, 2026.
It summarizes the response policy for various AWS services, and the information about Lambda can be summarized as follows:

• The Lambda service itself is not affected
• The Node.js and .NET runtimes are affected
• Python, Ruby, and the OS-only runtime (provided.al2023) do not include the Brotli library
  • However, if you have included the Brotli library in your function's deployment package or layers, it is recommended that you fix it and redeploy

The status for each runtime is as follows.
(As of the page's last update on October 29, 2026)

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

Difference Between Phase 1 and Phase 2

For functions deployed as ZIP packages, the fixed version of the managed runtime is rolled out in the following two stages.

• Phase 1
  • When a function is created or updated (when UpdateFunctionCode or UpdateFunctionConfiguration is called), the fixed version of the runtime is applied
• Phase 2
  • Lambda automatically applies the fix to functions whose update mode is Auto and that have not yet received the fixed version

The update mode here refers to the per-function runtime management configuration.
There are three runtime management settings: Auto (the default), Function update, and Manual.

Functions set to Function update get the fixed version only when the function is updated.
Functions set to Manual do not get the fixed version in either phase.

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

How to Tell Whether You Have the Fixed Version

According to the security bulletin, you can tell whether the fixed version has been applied from the runtime version shown in the INIT_START line of the function logs.
INIT_START is output every time an execution environment cold starts.

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

The bulletin also says that for Node.js 24, the fix is not reflected in process.version.
I will verify this later.

Trying Phase 1 (Newly Created Function)

Phase 1 is the stage where the fixed version is applied when a function is created or updated.
The security bulletin already lists it as completed, so a newly created function should get the fixed runtime.

Creating the Function

I created a new function with the nodejs24.x runtime using the following code.
It is a function that simply logs the Node.js version and the Brotli version built into Node.js.

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;
};

Phase 1 is applied at the moment the function is created, so you can create it with either the Management Console or the AWS CLI.
I left the update mode at the default Auto.

Checking INIT_START

I invoked the created function once and checked the Amazon CloudWatch Logs 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

The runtime version in INIT_START was nodejs:24.mainline.v114.
This meets the fixed-version criterion (v114 or later), so the fixed version had been applied to the newly created function in Phase 1.

You Can't Tell from process.version

On the other hand, the log output from the code in the same invocation was as follows.

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 was v24.21.0, and process.versions.brotli was 1.2.0.
The fixed version for Node.js 24 is 24.22.1, but process.version remains at 24.21.0.
According to the security bulletin, Node.js 24.22.1 has a known defect (regression), so AWS is not moving up to the latest release but is instead applying a fix targeted at the current stable version.

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

The Brotli version also remained at 1.2.0 rather than 1.2.1, which is the fixed version from the Brotli upstream.

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

In other words, on Node.js 24 you cannot determine whether the fix is present from the version obtainable in code.
You need to use the runtime version in INIT_START to confirm.

Trying Phase 2 (Existing Function)

Phase 2 is the stage where Lambda automatically applies the fixed version to existing functions whose update mode is Auto.
Phase 2 for Node.js is scheduled for October 30, 2026, which happens to be the day of this verification.

For verification, I used an existing function whose last update was in August 2026.
It is a function that just returns Hello World, and since no log group existed, it seems it had never been invoked before.

Checking the Update Mode

First, I check the update mode.

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

Auto

It was the default Auto, so it should be a target of Phase 2.

Checking INIT_START

Next, I invoked the function once and checked INIT_START.
(Around 18:13)

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

The runtime version was nodejs:24.mainline.v55, which is still older than the fixed-version criterion (v114 or later).
At this point, it seems the fixed version had not yet been applied to this function, at least, in Phase 2.

Picking Up the Fixed Version Without Waiting for Phase 2

As of around 18:15, the fixed version had not been automatically applied to the existing function.
So I tried picking up the fixed version without waiting for Phase 2, using the method described in the security bulletin.

If Phase 1 is complete, the fixed version is applied at the point you update the function's code or configuration (except for functions whose update mode is Manual).
However, the security bulletin says that it is not applied by updates that involve no changes.
Therefore you need to actually change something, and an easy way is to add one environment variable.
The security bulletin includes an AWS CLI script that adds an environment variable called TRIGGER_RUNTIME_UPDATE while keeping the existing environment variables.

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

The function this time had no environment variables at all, so I added only TRIGGER_RUNTIME_UPDATE=1 (around 18:31).

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

Note that --environment replaces the environment variables entirely.
For functions that have existing environment variables, use the script in the security bulletin to keep the existing values.

After the update completed, I invoked the function and checked INIT_START.

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

The runtime version changed from nodejs:24.mainline.v55 to nodejs:24.mainline.v114, and simply adding one environment variable got me the fixed version.
An invocation just a few seconds after updating the configuration was already running on the fixed runtime.

Supplement: Checking via the Runtime Version ARN

Let's compare the runtime version ARNs in the function configuration.

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

From the results below, you can see that the existing function's ARN changed, at the moment the environment variable was added, to the same value as the function newly created in Phase 1.

And since a runtime version ARN is unique per runtime version, it seems you could check whether the fixed version is in place without invoking the function, simply by comparing its ARN with that of a newly created function.

Note that even for the same runtime version, the ARN differs per region and CPU architecture, so the function you compare against must be created with the same runtime, region, and architecture.

However, please note that this is not a verification method that AWS has published. So to be certain, look at the runtime version in INIT_START.

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

Considerations

Caveats When Picking Up the Fix by Adding an Environment Variable

When you pick up the fixed version by adding an environment variable, you need to be careful about the following points.

• Only $LATEST is updated. If you invoke a published version through an alias, you need to publish a new version after the update and switch the alias target
• If you directly modify a function managed with Terraform, CloudFormation, or similar via the CLI, a difference arises between your code and the actual environment. If you manage it with IaC, it is better to make the change on the IaC side and deploy

Cases Where the Fix Isn't Applied Automatically

In the following cases, waiting for Phase 2 will not give you the fixed version, so action on the user's side is required.

• Functions whose update mode is Function update or Manual
• Container image functions (you need to rebuild with the latest base image and redeploy)
• Functions on deprecated runtimes (such as Node.js 18 and 20) (they are not covered by security updates)

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

Conclusion

The above are the results of checking AWS Lambda's runtime updates for CVE-2026-111497 across Phase 1 and Phase 2.

On Node.js 24, looking at process.version does not tell you whether the fix is present, so when checking whether you have the fixed version, make sure to look at the runtime version in INIT_START.

I hope this helps anyone struggling with responding to the same vulnerability.