CVE-2026-23747 in Firmware SDK
Summary
by MITRE • 02/26/2026
Golioth Firmware SDK version 0.10.0 prior to 0.22.0, fixed in commit 48f521b, contain a stack-based buffer overflow in Payload Utils. The golioth_payload_as_int() and golioth_payload_as_float() helpers copy network-supplied payload data into fixed-size stack buffers using memcpy() with a length derived from payload_size. The only length checks are guarded by assert(); in release builds, the asserts are compiled out and memcpy() may copy an unbounded payload_size. Payloads larger than 12 bytes (int) or 32 bytes (float) can overflow the stack, resulting in a crash/denial of service. This is reachable via LightDB State on_payload with a malicious server or MITM.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/26/2026
The vulnerability identified as CVE-2026-23747 affects the Golioth Firmware SDK version 0.10.0 through 0.21.0, representing a critical stack-based buffer overflow flaw within the Payload Utils component. This issue stems from insufficient input validation mechanisms in the golioth_payload_as_int() and golioth_payload_as_float() helper functions that process network-supplied data. The flaw manifests when these functions utilize memcpy() to copy payload data into fixed-size stack buffers without adequate bounds checking, creating a potential attack vector that can be exploited by malicious actors. The vulnerability specifically targets the stack memory allocation pattern where buffer sizes are determined at compile time but data copying operations rely on runtime payload_size values that are not properly validated.
The technical implementation of this vulnerability demonstrates a classic buffer overflow scenario where assert() statements serve as the primary validation mechanism but are effectively neutralized in release builds due to compiler optimizations. This design flaw creates a dangerous condition where network data of arbitrary size can be copied into stack buffers with predetermined maximum sizes of 12 bytes for integer conversions and 32 bytes for floating-point conversions. When payloads exceed these thresholds, the memcpy() operations overwrite adjacent stack memory, potentially corrupting program execution flow and leading to application crashes or system instability. The vulnerability is particularly concerning because it operates entirely within the legitimate data processing pathways of the SDK, making it difficult to detect through standard security scanning mechanisms.
The operational impact of this vulnerability extends beyond simple denial of service conditions to potentially enable more sophisticated attack vectors within the IoT ecosystem. An attacker capable of performing man-in-the-middle attacks or compromising the server component in LightDB State communications can craft malicious payloads that trigger the buffer overflow conditions. This scenario is particularly dangerous in embedded IoT environments where devices may not have robust error handling or recovery mechanisms, potentially leading to persistent service disruptions. The vulnerability affects devices that rely on Golioth's firmware SDK for state management and data processing, creating cascading effects across connected IoT networks where compromised devices could serve as entry points for broader attacks. The issue aligns with CWE-121 Stack-based Buffer Overflow, which specifically addresses buffer overflows occurring in stack memory regions, and represents a direct violation of secure coding practices recommended by the Software Engineering Institute.
Mitigation strategies for this vulnerability require immediate attention through version upgrades to 0.22.0 or later, which includes the fixed commit 48f521b that addresses the buffer overflow conditions. Organizations should implement comprehensive network monitoring to detect anomalous payload patterns that might indicate exploitation attempts, particularly in LightDB State communication channels. Additional defensive measures include implementing network segmentation to limit exposure of vulnerable devices, deploying intrusion detection systems capable of identifying malformed payload data, and establishing robust firmware update mechanisms that can quickly deploy patches. The vulnerability also highlights the importance of implementing proper input validation at multiple levels including runtime bounds checking, memory safety mechanisms, and secure coding practices that prevent the use of unsafe functions like memcpy() without proper size validation. Organizations should conduct thorough security assessments of their IoT deployments to identify all instances of the affected SDK version and prioritize remediation efforts based on risk exposure and criticality of affected devices.