libwebsockets: RCE via HTTP/2 HPACK, Single-Line Patch Available

On August 24, 2026, the Trend Micro Zero Day Initiative published advisory ZDI-26-590, documenting a remote code execution vulnerability in libwebsockets, a lightweight C library for WebSocket and HTTP widely integrated into embedded firmware and IoT devices. The flaw resides in the parsing of the HTTP/2 HPACK path header: the absence of a bounds check in the lws_frag_append() function allows a remote attacker to write past the end of an allocated buffer, achieving arbitrary code execution in the context of the server process. The vendor was notified on July 3, 2026; coordinated disclosure occurs today with a patch available.

The Flaw in the HTTP/2 HPACK Parser

The core of the vulnerability lies in the HTTP/2 frame processing path in libwebsockets. The HTTP/2 protocol uses HPACK to compress request headers; during parsing of the path field, the function lws_frag_append() in lib/roles/h2/hpack.c increments the ah->pos pointer without verifying that the position remains within the bounds of the ah->data buffer, sized according to max_http_header_data.

The ZDI advisory describes the mechanism precisely: "The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer." This condition opens a window for corruption of adjacent heap or stack memory, depending on the build configuration and target architecture.

The severity is amplified by the unauthenticated nature of the attack. As the same source states: "Authentication is not required to exploit this vulnerability." Every Internet-exposed endpoint employing libwebsockets with HTTP/2 enabled is potentially reachable without any access prerequisites.

The Single-Line Patch and Its Significance

Commit 8241518 in the official libwebsockets repository, identified as the response to case ZDI-CAN-31036, contains a surgical modification. Before the operation ah->data[ah->pos++], the code adds the check:

"if ((unsigned int)ah->pos >= wsi->a.context->max_http_header_data)" — libwebsockets patch commit 8241518

If the condition evaluates to true, the function aborts processing and returns an error. The minimalist nature of the fix—a single conditional line—highlights the structural fragility of the original parser and the density of impact that can stem from a seemingly marginal omission.

The commit attributes the discovery to Maher Azzouzi in collaboration with the Trend Micro Zero Day Initiative. The timeline documents roughly seven weeks of coordination between reporting and publication, an interval consistent with the standard responsible disclosure cycle managed by ZDI.

Why libwebsockets Exposes a Broad Attack Surface

libwebsockets is designed for resource-constrained environments: its small memory footprint and lack of heavy external dependencies make it a natural fit for routers, IoT devices, industrial gateways, and embedded server applications that require HTTP, HTTP/2, and WebSocket simultaneously. This pervasive deployment translates into a geographically and sectorially dispersed attack surface, often under the direct control of firmware teams rather than dedicated security operators.

The ZDI advisory does not list specific affected versions. This absence constitutes a significant operational limitation: integrators lack an immediate criterion to distinguish between vulnerable and non-vulnerable builds. Verification falls to source code analysis or checking for the presence of commit 8241518 in the local repository history.

The source also does not specify whether HTTP/2 is enabled by default in standard libwebsockets configurations or requires explicit activation at compile time. This missing data affects the assessment of immediate risk for legacy systems that may not expose the HTTP/2 service.

Recommended Actions

The following actions follow directly from the facts documented in the dossier and primary sources:

• Verify the presence of commit 8241518 in the libwebsockets version in use; if absent, plan an upgrade to the version that includes the fix
• Check whether the local libwebsockets build includes HTTP/2 support; if HTTP/2 is not required for the application, evaluate disabling it at compile time as an attack surface reduction
• Inspect access logs for anomalous HTTP/2 requests that may indicate exploit attempts against the path header, bearing in mind that no specific signature is documented in the sources
• Contact maintainers of upstream projects that depend on libwebsockets to verify the patch integration status in their respective release cycles

A Recurring Pattern in Binary Protocol Parsers

The structure of this vulnerability falls into a well-documented family: parsers of complex protocols that delegate bounds management to the caller, while the caller fails to perform the check. HPACK in particular requires decoding variable-length fields with references to dynamic tables; this inherent complexity increases the likelihood of confinement errors in accumulation buffers.

Case ZDI-26-590 adds a contemporary example to a history that includes similar vulnerabilities in HTTP/2 implementations from various vendors. The difference here lies in the vertical penetration of libwebsockets into ecosystems where the patch cycle is dictated by firmware timelines, not cloud infrastructure.

The absence of a CVSS score and an affected versions list in the ZDI advisory text constitutes an information gap that slows automated prioritization by vulnerability management systems. Operators will need to compensate with manual code analysis or tracking of the specific commit.

Sources

• http://www.zerodayinitiative.com/advisories/ZDI-26-590/
• http://www.zerodayinitiative.com/advisories/published/
• https://www.cve.org/CVERecord?id=CVE-2026-19773
• http://www.zerodayinitiative.com/advisories/upcoming/
• https://github.com/warmcat/libwebsockets/commit/824151862f37bc72f46d9a3e01d5b9408d313a0b
• https://www.trendmicro.com/

Information verified against cited sources and current as of publication.

Sources