CVE-2026-18416 in Zephyr
Summary
by MITRE • 09/28/2026
The CoAP link-format helper match_path_uri() in subsys/net/lib/coap/coap_link_format.c compares a registered resource path against the URI carried in a Uri-Query href= option. That URI is not NUL terminated, but the inner character loop advanced its index k once per path character without ever testing it against the option length len. When a registered path segment is longer than the supplied URI and the URI is a prefix of it, the loop reads uri[len] and beyond, past the end of the option value.
The path is reached from coap_well_known_core_get_len() and coap_well_known_core_get() via match_queries_resource(), i.e. by any unauthenticated GET /.well-known/core?href=/<prefix> request to a device that serves /.well-known/core (for the CoAP server subsystem, CONFIG_COAP_SERVER_WELL_KNOWN_CORE, default y) and has at least one resource that declares struct coap_core_metadata attributes.
The over-read does not reach the receive buffer. The well-known-core builders parse the query into a stack-local struct coap_option, whose value is a fixed array (value[12], or CONFIG_COAP_EXTENDED_OPTIONS_LEN_VALUE bytes) that the option bytes are copied into, so uri points into that copy. Reading past len therefore reads the unused, uninitialized tail of the array and, when the option fills it, the bytes just past it in the same stack frame. (In the ZoAP library of v1.8.0 to v1.9.x the option value was instead a pointer into the received packet, and the over-read ran past the option inside the packet buffer.)
The impact is bounded. The number of bytes read past the end is limited by the length of the resource path segment, and each additional byte is only read if it happens to equal the next path character, so in practice the over-read is one byte. It also cannot influence the response: returning a match requires the final compared index to be len - 1 or len, both in bounds, so out-of-bounds bytes only ever steer the loop to the next candidate resource. The consequence is undefined behaviour, not information disclosure and not a matching error.
The fix adds a k >= len guard at the top of the inner loop, so every uri[k] dereference is within the option value while still allowing a trailing * wildcard to match a longer path.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in the CoAP link-format helper function match_path_uri represents an out-of-bounds read condition rooted in improper input validation and boundary checking during URI query processing. This flaw exists within the subsys/net/lib/coap/coap_link_format.c module, specifically affecting devices that enable the CONFIG_COAP_SERVER_WELL_KNOWN_CORE configuration option by default. The vulnerability is triggered when a client sends an unauthenticated GET request to the /.well-known/core endpoint with a Uri-Query parameter containing an href attribute. In this scenario, the system attempts to match the provided URI against registered resource paths that include coap_core_metadata attributes. The core technical failure lies in the character-by-character comparison loop within match_path_uri(), which iterates through characters of the supplied URI without verifying whether the current index remains within the bounds defined by the option's length field.
From a technical perspective, the issue arises because the URI extracted from the Uri-Query href= option is not NUL terminated, yet the inner character loop advances its index k for every character in the registered path segment without checking against the actual length of the supplied URI data. When a registered path segment is longer than the provided URI and the URI serves as a prefix to that path, the comparison logic continues beyond the valid memory region allocated for the option value. In versions prior to the fix, particularly within the ZoAP library range v1.8.0 to v1.9.x, this over-read extended into the received packet buffer itself due to pointer-based allocation strategies. However, in later implementations where the option value is copied into a fixed-size stack-local array such as struct coap_option with a value[12] or CONFIG_COAP_EXTENDED_OPTIONS_LEN_VALUE byte capacity, the out-of-bounds read targets uninitialized memory within that stack frame rather than network packet data. This distinction significantly alters the risk profile but does not eliminate the underlying flaw of accessing memory outside declared boundaries.
The operational impact of this vulnerability is constrained by several mitigating factors inherent to the comparison logic and memory layout. The number of bytes accessed beyond the valid length is strictly limited by the difference between the registered path segment length and the URI length, often resulting in only a single byte being read past the end boundary. Furthermore, because the loop condition requires subsequent characters to match exactly for progression, out-of-bounds reads do not influence the final matching outcome unless those specific memory contents coincidentally align with expected path characters. Consequently, this behavior results in undefined execution paths rather than direct information disclosure or authentication bypasses. The system does not leak sensitive data from adjacent buffers because the read operations are confined to stack-local structures and uninitialized tail bytes that lack exploitable content for meaningful extraction.
This vulnerability maps directly to CWE-125, which describes out-of-bounds read conditions where software reads memory beyond allocated boundaries. Additionally, it aligns with MITRE ATT&CK technique T1083, specifically the file and directory discovery subtechnique, as an attacker could potentially use this flaw to probe resource structures or infer system configuration through side-channel effects if combined with other vulnerabilities. Although the immediate impact is limited to undefined behavior without direct data exfiltration capabilities, such memory safety violations are frequently precursors to more severe exploits like buffer overflows or arbitrary code execution in different contexts. The lack of proper boundary checks during string comparison operations remains a critical security anti-pattern that undermines the integrity of network protocol implementations.
Mitigation strategies focus on enforcing strict input validation and implementing robust bounds checking within all iterative processing loops. The primary remediation involves adding an explicit guard condition at the start of the inner character loop to ensure that the index k never exceeds len, thereby preventing any access beyond the valid option value boundaries. This adjustment preserves legitimate functionality such as wildcard matching for trailing characters while eliminating the unsafe memory access pattern. Developers should also consider adopting static analysis tools capable of detecting out-of-bounds reads during compilation and implementing fuzzing campaigns targeting CoAP query parsing routines to identify similar boundary errors across other protocol handlers. Regular security audits focusing on string manipulation functions in embedded network stacks are essential to maintain resilience against these types of logic-based memory safety violations.