---
id: "CVE-2026-82391"
page: "https://infrastack.ai/live/CVE-2026-82391"
kind: "vulnerability"
aliases: ["CVE-2026-82391"]
title: "Zephyr HTTP/2 server: static file request lets remote attackers corrupt memory"
severity: "critical"
cvss: 9.1
epss: null
exploited: false
status: "open"
category: "runtime"
products: [{"name": "zephyr", "fixed": ["4.3.2", "4.5.0"], "affected": ">= 4.0.0, < 4.3.2; >= 4.4.0, < 4.5.0", "ecosystem": "vendor"}]
ecosystems: []
tags: ["embedded", "http-server", "http2", "iot", "runtime", "zephyr"]
not_affected_if: ["http1-or-http3-only", "http2-disabled", "no-static-fs"]
published_at: "2026-11-10T22:21:05+00:00"
first_seen_at: "2026-11-10T22:27:30+00:00"
updated_at: "2026-11-10T22:29:15+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82391", "first_seen_at": "2026-11-10T22:27:30+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-10T22:29:10+00:00"}]
exploit_sources: []
---

# Zephyr HTTP/2 server: static file request lets remote attackers corrupt memory

Link for people: https://infrastack.ai/live/CVE-2026-82391 (this .md is for agents)

The HTTP/2 front end of the Zephyr HTTP server overwrites its own connection receive length with a static file's size when serving any file. That lets an unauthenticated remote client trigger out-of-bounds reads and writes and likely crash the device or run code.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:zephyr affected >= 4.0.0, < 4.3.2; >= 4.4.0, < 4.5.0 fixed 4.3.2, 4.5.0

## How to check

1. Check your Zephyr version: affected are >= 4.0.0 and < 4.3.2, and >= 4.4.0 and < 4.5.0 (v3.7 is not affected).
2. Check the build config for CONFIG_HTTP_SERVER=y, CONFIG_HTTP_SERVER_VERSION_2=y (default), and CONFIG_FILE_SYSTEM=y.
3. Check whether the app registers an HTTP_RESOURCE_TYPE_STATIC_FS resource. If it does, a single HTTP/2 GET for a file larger than CONFIG_HTTP_SERVER_CLIENT_BUFFER_SIZE (256 by default) triggers the bug.
4. In a patched tree, grep -rn '&client->data_len' subsys/ finds no file_size out-parameter use.

## Fix

Upgrade Zephyr to 4.3.2 (4.3 line) or 4.5.0 (4.4/4.5 line). Fix: handle_http2_static_fs_resource() uses a local size_t file_size instead of &client->data_len (commit 4e0a5f3). Zephyr v3.7 is not affected. Workaround until upgraded: disable CONFIG_HTTP_SERVER_VERSION_2 or do not register HTTP_RESOURCE_TYPE_STATIC_FS resources.

## Timeline

- 2026-11-10T22:27:30+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-82391
- 2026-11-10T22:29:10+00:00 analyst — Restated zephyr product as one row covering both ranges.

## Documents

- [advisory] Vendor advisory: github.com https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8jrg-wx88-g75j
- [fix] Patch: github.com https://github.com/zephyrproject-rtos/zephyr/commit/4e0a5f38b14dba5891fb558c49a526f9f6a3cc29

## From the sources

The HTTP/2 front-end of the Zephyr HTTP server aliased connection receive state as a scratch output. In subsys/net/lib/http/http_server_http2.c, handle_http2_static_fs_resource() passed &client->data_len as the file_size out-parameter of http_server_find_file(). client->data_len is the count of unprocessed bytes remaining in the fixed-size per-connection receive buffer client->buffer[CONFIG_HTTP_SERVER_CLIENT_BUFFER_SIZE] (256 bytes by default), an invariant every frame handler and the socket receive path rely on. Serving any static file therefore replaced that bounded value with the file's on-disk size, and nothing resets it afterwards.

The defect is reached by an unauthenticated HTTP/2 GET for any file under the web root, in applications that register a static-filesystem resource (HTTP_RESOURCE_TYPE_STATIC_FS) with CONFIG_FILE_SYSTEM=y; CONFIG_HTTP_SERVER_VERSION_2 is enabled by default and no TLS or credentials are required on this path. Once client->data_len exceeds the buffer size, the frame dispatch loop in subsys/net/lib/http/http_server_core.c keeps parsing past the end of the received data, and the peer controls the bytes at client->cursor, so it can choose which fabricated frame the state machine consumes next by appending bytes after its request.

The inflated length defeats the only guards on the buffer. parse_http_frame_header() and the per-frame handlers read and skip up to a 24-bit frame length beyond the buffer (out-of-bounds read); the compaction memmove(client->buffer, client->cursor, client->data_len) at the end of request handling copies the file-size number of bytes into the 256-byte buffer, overflowing the rest of struct http_client_ctx — including the current_detail/current_stream pointers, the parser_settings function-pointer table and the inactivity_timer work handler — and the adjacent client contexts in static memory; and the subsequent zsock_recv(client->fd, client->buffer + client->data_len, sizeof(client->buffer) - client->data_len, 0) underflows its size argument, writing attacker-supplied data of attacker-chosen length out of bounds.

The impact is remote memory corruption in the server's single address space: at minimum a crash or hang of the device, and plausibly control-data overwrite leading to code execution. The HTTP/1 and HTTP/3 static-filesystem handlers already used a local variable and are unaffected; the fix makes the HTTP/2 handler use a local size_t file_size as well.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_