HTTP2Shell Vulnerability: How Should Security Teams Assess and Reduce Exposure?

TL;DR: The HTTP2Shell vulnerability (CVE-2026-111497) is a critical flaw in Google’s Brotli decompression decoder that could allow attackers to corrupt memory and potentially execute malicious code. With a CVSS v4.0 score of 9.2, the vulnerability affects software beyond Node.js, creating potential exposure across cloud native applications and their dependencies. Security teams should identify affected components, determine whether vulnerable decoding paths are reachable and apply available updates. Aquasec has also confirmed that while the affected library was present in certain Enforcer images, its analysis found no exploitable decoding path and an updated Enforcer release is now available.

What is the HTTP2Shell vulnerability?

HTTP2Shell, initially called Node2Shell, is a critical memory corruption vulnerability affecting Google’s Brotli decompression library. Tracked as CVE-2026-111497, the flaw occurs when the decoder processes specially crafted compressed data, potentially allowing an attacker to crash an application, disclose sensitive information or execute arbitrary code.

Despite its name, HTTP2Shell is not a vulnerability in the HTTP/2 protocol itself. The flaw exists in Brotli, a widely used compression library embedded in applications and software dependencies.

This distinction matters because the potential impact extends beyond Node.js. Any application that incorporates an affected Brotli decoder and processes attacker controlled compressed data could be exposed, making it important for organizations to examine more than their Node.js environments.

Why does HTTP2Shell matter to cloud native environments?

HTTP2Shell highlights a challenge that security teams regularly encounter when managing vulnerabilities across cloud native environments. A single vulnerable library can be present in multiple applications, container images and third party components, making it difficult to understand where exposure actually exists.

In containerized environments, dependencies are frequently bundled directly into images or application binaries. Updating a library on the underlying host does not necessarily update the same library embedded in a running container.

The vulnerability also creates different levels of risk depending on how an application uses Brotli. An application that actively decompresses attacker controlled content may be exposed, while another application containing the same vulnerable library may never execute the affected code.

For security teams, this means that identifying vulnerable software is an important first step, but assessing actual exposure requires understanding how that software operates in production.

Why doesn’t finding a vulnerable Brotli library confirm exploitability?

Traditional vulnerability scanning is essential for identifying affected software, but a scanner finding alone cannot establish whether HTTP2Shell can be exploited in a particular environment.

Exploitation requires the vulnerable decoder to process Brotli compressed content that an attacker can influence. Simply having the library installed does not establish that this condition exists.

For example, two applications may contain the same vulnerable Brotli version, but only one may be configured to decompress untrusted content. Both applications could generate vulnerability findings even though their exposure differs significantly.

This is where runtime context becomes valuable. Understanding which components are active, how applications behave and whether vulnerable functionality can be reached helps security teams distinguish findings that represent immediate exposure from those that require further investigation.

That context does not eliminate the need for remediation. It helps teams make more informed decisions about where to act first.

What does an effective HTTP2Shell response look like?

An effective response combines comprehensive vulnerability identification with an assessment of the conditions required for exploitation.

Security teams should begin by locating affected Brotli libraries across their environments, including dependencies embedded in application images and third party software. Once identified, the next step is to determine which applications decompress content that an attacker could control.

Applications with an exposed decoding path should receive priority for remediation, particularly when they are running in production and accessible to untrusted sources.

Where corrected versions are available, organizations should update the affected software and verify that the corrected components are actually running. This is especially important in containerized environments where an application may continue using an older image even after a dependency has been updated elsewhere.

Runtime security adds another layer to this strategy by providing insight into workload activity and enforcing supported security policies inside running workloads. These controls complement vulnerability remediation, helping organizations manage production risk while software updates are applied.

How is Aquasec addressing HTTP2Shell?

Aquasec has reviewed the impact of HTTP2Shell on its own components and confirmed that the affected Brotli library was present in certain Aquasec Enforcer images.

However, our security analysis determined that the vulnerable decoding functionality is not used by Enforcer components. The Enforcer does not decompress Brotli data, meaning the conditions required to exploit HTTP2Shell through the affected decoder are not present in the assessed Enforcer execution paths.

Our assessment included examination of both source code and released binaries to verify that the vulnerable decoder is not invoked during Enforcer operation.

Although the vulnerable library was not reachable through Enforcer functionality, we have released an updated Enforcer version containing the corrected Brotli package.

Aquasec Enforcer 2022.4 U47 SP2 (2022.4.951.5) is now available. We recommend that customers upgrade to this release to remove the vulnerable dependency and address associated scanner findings.

Customers looking for additional information about affected versions, our technical assessment and upgrade guidance can refer to the Aquasec Support Knowledge Base and the U47 SP2 release documentation.

What does HTTP2Shell tell us about vulnerability management?

HTTP2Shell reinforces an important distinction between identifying vulnerabilities and understanding their actual impact in production.

A vulnerability scanner can identify a component associated with a known CVE, but it cannot always determine whether the vulnerable functionality is being used or whether an attacker can reach it.

This creates a challenge for security teams managing large volumes of findings. Treating every finding as equally exploitable can divert attention from exposures that represent a more immediate threat.

Aquasec’s runtime security approach focuses on understanding what is happening inside running workloads and using that context to inform security decisions. Instead of relying solely on static vulnerability information, teams can combine scanning with runtime intelligence to focus remediation on the risks that matter most.

The objective is to reduce real exposure while maintaining protection for workloads that continue running during the remediation process.

What should organizations do now to address HTTP2Shell?

Organizations should review their application environments for affected Brotli dependencies and prioritize workloads that process compressed content from untrusted sources.

Corrected upstream Brotli releases include versions 1.0.10, 1.1.1 and 1.2.1. Node.js has also released security updates in versions 22.23.4, 24.22.1 and 26.12.1. Organizations running unsupported Node.js versions should migrate to a supported release.

Security teams should also review vendor advisories for affected third party software, apply available updates and rescan their environments to verify remediation. Updating the underlying operating system alone may not resolve vulnerabilities in libraries bundled with applications or container images.

Aquasec customers should upgrade affected Enforcer deployments to 2022.4 U47 SP2 (2022.4.951.5) and follow the documented upgrade and verification procedures.

FAQs

What is CVE-2026-111497?

CVE-2026-111497, also known as HTTP2Shell or Node2Shell, is a critical vulnerability in Google’s Brotli decompression decoder. It can cause memory corruption when an affected application processes specially crafted compressed data, potentially resulting in application crashes, information disclosure or arbitrary code execution.

Does HTTP2Shell only affect Node.js applications?

No. Although the vulnerability was initially associated with Node.js, the flaw exists in the underlying Brotli decoder. Other applications and software components that incorporate affected Brotli versions may also be exposed if they decompress attacker controlled content.

Does detecting HTTP2Shell mean an application is exploitable?

Not necessarily. A vulnerability finding confirms the presence of an affected component, but exploitability depends on whether the vulnerable decoder processes attacker controlled data. Security teams should assess the application’s behavior and exposure alongside the scanner finding.

Is Aquasec Enforcer affected by HTTP2Shell?

Aquasec identified the affected Brotli library in certain Enforcer images, but its security assessment found that Enforcer does not execute the vulnerable decoder. Aquasec has also released Enforcer version 2022.4.951.5 with an updated Brotli package and recommends that customers upgrade.

Can runtime security replace patching for HTTP2Shell?

No. Applying corrected software remains the recommended remediation. Runtime security provides additional context about workload behavior and can enforce supported security controls in production, helping organizations manage risk while remediation proceeds. Aquasec runtime controls are not the basis of its assessment that the vulnerable decoding path is unreachable in Enforcer.

Aqua Security is the pioneer in securing containerized cloud native applications from development to production. The Aqua full lifecycle solution prevents attacks by enforcing pre-deployment hygiene and mitigates attacks in real time in production, reducing mean time to repair and overall business risk. The Aqua Platform, a Cloud Native Application Protection Platform (CNAPP), integrates security from Code to Cloud, combining the power of agent and agentless technology into a single solution. With enterprise scale that doesn’t slow development pipelines, Aqua secures your future in the cloud. Founded in 2015, Aqua is headquartered in Boston, MA and Ramat Gan, IL protecting over 500 of the world’s largest enterprises.