CVE-2026-5067: Critical Memory Corruption in Zephyr RTOS

What Happened and Why Defenders Should Care

CVE-2026-5067 is a critical memory corruption vulnerability in the Zephyr Project’s Zephyr RTOS HTTP server, specifically in the WebSocket upgrade path. According to the NVD description, a remote, unauthenticated attacker can trigger the bug by sending a crafted Sec-WebSocket-Key header. The flaw is reachable when CONFIG_HTTP_SERVER_WEBSOCKET is enabled.

The security significance is straightforward: this is not a logic bug with narrow impact, but a parser-path memory safety issue in a network-facing service. The vulnerable path performs a bounded copy into a fixed-size buffer without guaranteeing NUL termination, and later code uses strlen() and concatenation on that data. That creates out-of-bounds read and write conditions on stack memory. At minimum, defenders should expect denial of service. Because the corruption occurs on the stack, potential code execution cannot be ruled out.

For embedded and IoT teams, this matters because Zephyr is frequently deployed in devices that expose management, telemetry, or application interfaces over HTTP. If WebSocket support is enabled and reachable from untrusted networks, the attack surface is external and unauthenticated. That combination makes this vulnerability operationally important even without confirmed exploitation in the wild.

A second reason to prioritize this CVE is that parser bugs tend to be reproducible once researchers and attackers focus on the vulnerable code path. Public exploitation status is currently unknown from the sources available here, and the CVE is not in CISA KEV at the time of writing. Still, a critical remote memory corruption issue in an HTTP/WebSocket handling path should be treated as high-risk by default.

Affected Products, Configuration, and Version Status

The confirmed affected product is Zephyr RTOS, specifically the Zephyr HTTP server’s WebSocket upgrade handling. The vulnerable path is reachable when the following configuration is enabled:

• CONFIG_HTTP_SERVER_WEBSOCKET

That means not every Zephyr deployment is necessarily exposed. Systems that do not use the HTTP server, or that use it without WebSocket support, may not be reachable through this code path. From a defender perspective, configuration scoping matters because many embedded fleets are built from highly customized firmware images and feature flags.

There is an important documentation limitation here: based on the research note provided, the exact affected version range and the exact fixed version number were not reliably retrievable from the primary-source text available in this session. The upstream GitHub Security Advisory exists at GHSA-wgr4-9pwq-94vj, and Zephyr’s official vulnerabilities page exists, but the source text available here did not expose the precise release boundaries. Because the user asked for specific affected ranges and the fixed version number, the only accurate statement is:

• Affected version range: unknown from currently available source text in this session
• Fixed version: unknown from currently available source text in this session

In the absence of authoritative version details, defenders should assume that any Zephyr build incorporating the vulnerable HTTP server WebSocket code path may be affected until validated against the upstream advisory and release notes. For practical triage, that means identifying all firmware builds using Zephyr HTTP server plus WebSocket support, then mapping those builds to the exact upstream Zephyr commit, tag, or vendor fork in use.

Technical Notes

Check Zephyr build configuration artifacts for WebSocket support:

grep -R "CONFIG_HTTP_SERVER_WEBSOCKET=y" build/ zephyr/ .config 2>/dev/null

If you maintain source-based firmware trees, search for HTTP server and WebSocket enablement together:

grep -R "CONFIG_HTTP_SERVER_WEBSOCKET" .
grep -R "http_server" .

A minimal Kconfig-style indicator of exposure looks like this:

CONFIG_HTTP_SERVER=y
CONFIG_HTTP_SERVER_WEBSOCKET=y

Root Cause and Exploitability

The core bug is an unsafe C string-handling sequence. A user-controlled Sec-WebSocket-Key header is copied into a fixed-size buffer using a bounded copy operation that may fail to append a terminating \0 when the source string exactly fills the destination. Later in the WebSocket upgrade flow, that buffer is copied again to a local stack buffer and passed to strlen(). If there is no NUL byte in-bounds, strlen() continues reading beyond the buffer.

The next step is what elevates this from a simple parsing defect to a serious memory corruption issue. The application then concatenates the WebSocket magic string to compute the expected handshake material. If the string length calculation already ran past the valid boundary, subsequent writes can also occur out of bounds. Per the NVD description, this results in out-of-bounds read and write on stack memory.

For exploitation analysis, denial of service is the most defensible outcome to assume immediately. Stack corruption can crash the HTTP handling thread or the whole device, depending on build and runtime architecture. Potential code execution is plausible but not guaranteed. Real exploitability will depend on architecture, compiler behavior, stack canaries, memory layout, optimization level, and whether downstream vendors applied additional hardening.

At the time of writing, the research note confirms no public proof of concept was identified from the retrieved sources, and no confirmed in-the-wild exploitation was identified. The CVE is also not currently listed in CISA KEV. That should not be misread as low risk. Instead, it means defenders must prioritize based on exposure and impact, not on public exploitation headlines.

Technical Notes

The vulnerable header is explicitly named in the advisory context:

Sec-WebSocket-Key: <attacker-controlled value>

A high-level pseudocode representation of the flaw pattern is:

char key_buf[FIXED];
strncpy(key_buf, user_header, sizeof(key_buf));   // may omit NUL

char stack_buf[FIXED];
memcpy(stack_buf, key_buf, sizeof(stack_buf));

size_t len = strlen(stack_buf);                   // OOB read if no NUL
strcat(stack_buf, WS_MAGIC);                      // possible OOB write

Exploitation Status and Defender Assumptions

Based on the research note, there is no confirmed public PoC and no confirmed in-the-wild exploitation for CVE-2026-5067 from the sources retrieved in this session. The CVE is also not currently present in the CISA Known Exploited Vulnerabilities catalog. Those are useful facts, but they are not a reason to de-prioritize response.

In the absence of confirmed exploitation data, defenders should assume that exploit development is feasible enough to matter. The vulnerability is remotely reachable, unauthenticated, and located in an HTTP parsing and upgrade flow that can often be exercised repeatedly. That combination is routinely attractive to attackers and researchers. For exposed devices, the prudent posture is to prioritize inventory, exposure reduction, and patch validation now rather than wait for broader public reporting.