CVE-2026-23749: Golioth Firmware SDK DoS Vulnerability

CVE-2026-23749 Overview

CVE-2026-23749 is an out-of-bounds read vulnerability affecting Golioth Firmware SDK versions 0.19.1 prior to 0.22.0. The flaw exists due to improper null termination of a blockwise transfer path in the blockwise_transfer_init() function. When a path with a length equal to CONFIG_GOLIOTH_COAP_MAX_PATH_LEN is provided, the function copies it using strncpy() without guaranteeing a trailing NUL byte, leaving ctx->path unterminated. A subsequent strlen() call on this buffer in golioth_coap_client_get_internal() can read past the end of the allocation, resulting in a crash or denial of service condition.

Critical Impact

An out-of-bounds read in the Golioth Firmware SDK can cause application crashes and denial of service on IoT devices using this firmware SDK when processing blockwise CoAP transfers with maximum-length paths.

Affected Products

• Golioth Firmware SDK versions 0.19.1 to 0.21.x
• IoT devices and embedded systems utilizing affected Golioth Firmware SDK versions
• Applications implementing CoAP blockwise transfers with Golioth SDK

Discovery Timeline

• 2026-02-26 - CVE CVE-2026-23749 published to NVD
• 2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-23749

Vulnerability Analysis

This vulnerability is classified as CWE-170 (Improper Null Termination). The root issue lies in the blockwise_transfer_init() function within src/coap_blockwise.c, which fails to properly ensure null termination when copying path strings at the boundary condition.

The strncpy() function in C does not guarantee null termination when the source string length equals or exceeds the specified maximum length. In this case, when a path of exactly CONFIG_GOLIOTH_COAP_MAX_PATH_LEN characters is provided, the buffer is filled completely without a terminating NUL byte. Subsequent string operations like strlen() will then read beyond the allocated buffer boundaries until a null byte is encountered in adjacent memory, causing undefined behavior.

While the input is application-controlled rather than network-controlled by default, this still presents a risk in scenarios where path values are derived from configuration or semi-trusted sources. The impact is limited to denial of service through application crashes.

Root Cause

The vulnerability stems from a classic C programming error involving strncpy() and improper buffer size calculation. The function allocated a buffer of CONFIG_GOLIOTH_COAP_MAX_PATH_LEN bytes and used the same value as the strncpy() length parameter, leaving no room for the null terminator when the input string exactly matches this maximum length. This is a common source of off-by-one errors in embedded C code.

Attack Vector

The attack vector requires local access as the vulnerable input is application-controlled. An attacker would need to influence the path parameter passed to the blockwise transfer initialization function. This could occur through:

1. Manipulating application configuration files that define CoAP resource paths
2. Exploiting other application logic that constructs paths dynamically
3. In some deployment scenarios, through indirect control of path values via application APIs

The attack complexity is increased by the prerequisite of controlling the path input and ensuring it meets the exact maximum length condition.

// Security patch from src/coap_blockwise.c
// Source: https://github.com/golioth/golioth-firmware-sdk/commit/0e788217ab4b61a7c1d9fadd1b4a40f5f538a26d

     {
         return -EINVAL;
     }
-    strncpy(ctx->path, path, CONFIG_GOLIOTH_COAP_MAX_PATH_LEN);
+    strncpy(ctx->path, path, CONFIG_GOLIOTH_COAP_MAX_PATH_LEN + 1);

     ctx->client = client;
     ctx->path_prefix = path_prefix;

The fix increases the strncpy() length parameter by one to account for the null terminator, ensuring the path is always properly terminated regardless of input length.

Detection Methods for CVE-2026-23749

Indicators of Compromise

• Application crashes or unexpected terminations during CoAP blockwise transfer operations
• Memory access violations or segmentation faults in firmware logs referencing golioth_coap_client_get_internal() or related functions
• Repeated device reboots when processing specific CoAP resource paths

Detection Strategies

• Implement runtime memory sanitizers (AddressSanitizer) during development and testing to catch out-of-bounds reads
• Monitor application stability and crash reports for patterns involving CoAP path processing
• Review firmware logs for memory access errors or abnormal terminations in Golioth SDK components
• Audit source code for strncpy() usage patterns without proper null termination checks

Monitoring Recommendations

• Enable verbose logging for CoAP operations to capture path lengths being processed
• Implement watchdog monitoring for unexpected firmware crashes on IoT devices
• Track device uptime metrics to identify denial of service patterns
• Set up crash dump collection and analysis for embedded devices where possible

How to Mitigate CVE-2026-23749

Immediate Actions Required

• Update Golioth Firmware SDK to version 0.22.0 or later immediately
• Review all CoAP resource paths configured in applications to ensure they are well under CONFIG_GOLIOTH_COAP_MAX_PATH_LEN
• If immediate update is not possible, apply the patch from commit 0e788217ab4b61a7c1d9fadd1b4a40f5f538a26d
• Validate input path lengths before passing to blockwise transfer functions

Patch Information

The vulnerability is fixed in Golioth Firmware SDK version 0.22.0. The fix is available in commit 0e788217ab4b61a7c1d9fadd1b4a40f5f538a26d. Organizations should update to the patched version by pulling the latest release from the Golioth Firmware SDK v0.22.0 Release.

For technical details on the vulnerability and fix, refer to the VulnCheck Advisory and the Secmate Disclosure SECMATE-2025-0017.

Workarounds

• Enforce path length validation at the application layer to ensure paths are always shorter than CONFIG_GOLIOTH_COAP_MAX_PATH_LEN
• Reduce CONFIG_GOLIOTH_COAP_MAX_PATH_LEN configuration value if shorter paths are acceptable for your use case
• Implement defensive null termination after any strncpy() calls in custom code interfacing with the SDK
• Consider input sanitization wrappers around blockwise transfer initialization functions

# Configuration example - Verify Golioth SDK version and update
# Check current SDK version in your project
grep -r "GOLIOTH_FIRMWARE_SDK_VERSION" .

# Update to patched version using west (Zephyr)
west update golioth-firmware-sdk

# Or update manifest to use v0.22.0 or later
# revision: v0.22.0