Zephyr's HTTP server (subsys/net/lib/http) provides a static-filesystem resource type (HTTPRESOURCETYPESTATICFS, available when CONFIGFILESYSTEM is enabled) that serves files from a configured root directory. Before this fix, both the HTTP/1 and HTTP/2 front-ends placed the raw, attacker-controlled request path into client->urlbuffer (assembled in onurl() for HTTP/1 and copied verbatim from the :path pseudo-header for HTTP/2) without resolving ./.. segments. The static-FS handler then built the on-disk filename by directly concatenating the configured root with that raw URL (snprintk(fname, ..., "%s%s", staticfsdetail->fspath, client->urlbuffer) at httpserverhttp1.c:603 and httpserverhttp2.c:490) and opened it with fsopen(fname, FSOREAD). Because the handler is reached via wildcard/leading-dir (fnmatch FNMLEADINGDIR) or fallback resource matching, a request such as GET /<prefix>/../../<file> is dispatched to the handler and, after the underlying filesystem (e.g. LittleFS/FAT) resolves the .. segments, escapes the configured web root, letting an unauthenticated remote client read arbitrary readable files on the mounted volume (information disclosure). The HTTP server requires no TLS or authentication to reach this path. The fix adds httpserverremovedot_segments(), which canonicalizes the path portion of the URL before resource lookup in both protocol handlers, neutralizing the traversal. Affects releases v4.0.0 through v4.4.0 for deployments that register a static-filesystem resource.
{
"cna_assigner": "zephyr",
"cwe_ids": [
"CWE-22"
],
"unresolved_ranges": [
{
"source": "AFFECTED_FIELD",
"extracted_events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.5.0"
}
]
}
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/8xxx/CVE-2026-8023.json"
}