{"id":"CVE-2026-82391","aliases":["EUVD-2026-123035"],"status":"published","title":"Out-of-bounds write in Zephyr HTTP/2 server static-filesystem handler via corrupted receive-buffer length","description":"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 \u0026client-\u003edata_len as the file_size out-parameter of http_server_find_file(). client-\u003edata_len is the count of unprocessed bytes remaining in the fixed-size per-connection receive buffer client-\u003ebuffer[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.\n\nThe 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-\u003edata_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-\u003ecursor, so it can choose which fabricated frame the state machine consumes next by appending bytes after its request.\n\nThe 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-\u003ebuffer, client-\u003ecursor, client-\u003edata_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-\u003efd, client-\u003ebuffer + client-\u003edata_len, sizeof(client-\u003ebuffer) - client-\u003edata_len, 0) underflows its size argument, writing attacker-supplied data of attacker-chosen length out of bounds.\n\nThe 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.","severity":{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical","assessor":"cna","from":"cve"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-787"],"published":"2026-11-10T22:07:39Z","modified":"2026-11-10T22:07:39Z","products":[{"vendor":"zephyrproject","product":"zephyr"},{"vendor":"zephyrproject-rtos","product":"zephyr"}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/4e0a5f38b14dba5891fb558c49a526f9f6a3cc29","tags":["patch"]},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8jrg-wx88-g75j"}],"sources":{"cve":[{"id":"CVE-2026-82391","title":"Out-of-bounds write in Zephyr HTTP/2 server static-filesystem handler via corrupted receive-buffer length","description":"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 \u0026client-\u003edata_len as the file_size out-parameter of http_server_find_file(). client-\u003edata_len is the count of unprocessed bytes remaining in the fixed-size per-connection receive buffer client-\u003ebuffer[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.\n\nThe 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-\u003edata_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-\u003ecursor, so it can choose which fabricated frame the state machine consumes next by appending bytes after its request.\n\nThe 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-\u003ebuffer, client-\u003ecursor, client-\u003edata_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-\u003efd, client-\u003ebuffer + client-\u003edata_len, sizeof(client-\u003ebuffer) - client-\u003edata_len, 0) underflows its size argument, writing attacker-supplied data of attacker-chosen length out of bounds.\n\nThe 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.","status":"published","published":"2026-11-10T22:07:39.047Z","modified":"2026-11-10T22:07:39.047Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-787"],"updated_at":"2026-11-10T23:49:31.388877Z"}],"euvd":[{"id":"EUVD-2026-123035","description":"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 \u0026client-\u003edata_len as the file_size out-parameter of http_server_find_file(). client-\u003edata_len is the count of unprocessed bytes remaining in the fixed-size per-connection receive buffer client-\u003ebuffer[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.\n\nThe 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-\u003edata_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-\u003ecursor, so it can choose which fabricated frame the state machine consumes next by appending bytes after its request.\n\nThe 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-\u003ebuffer, client-\u003ecursor, client-\u003edata_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-\u003efd, client-\u003ebuffer + client-\u003edata_len, sizeof(client-\u003ebuffer) - client-\u003edata_len, 0) underflows its size argument, writing attacker-supplied data of attacker-chosen length out of bounds.\n\nThe 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.","status":"published","published":"2026-11-10T22:07:39Z","modified":"2026-11-10T22:07:39Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical"}],"updated_at":"2026-11-10T23:24:16.163953Z"}],"nvd":[{"id":"CVE-2026-82391","description":"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 \u0026client-\u003edata_len as the file_size out-parameter of http_server_find_file(). client-\u003edata_len is the count of unprocessed bytes remaining in the fixed-size per-connection receive buffer client-\u003ebuffer[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.\n\nThe 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-\u003edata_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-\u003ecursor, so it can choose which fabricated frame the state machine consumes next by appending bytes after its request.\n\nThe 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-\u003ebuffer, client-\u003ecursor, client-\u003edata_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-\u003efd, client-\u003ebuffer + client-\u003edata_len, sizeof(client-\u003ebuffer) - client-\u003edata_len, 0) underflows its size argument, writing attacker-supplied data of attacker-chosen length out of bounds.\n\nThe 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.","status":"published","published":"2026-11-10T22:21:05.71Z","modified":"2026-11-10T22:21:05.823Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-787"],"updated_at":"2026-11-11T00:21:54.825455Z"}]}}