CVE-2026-23747: Golioth Firmware SDK Buffer Overflow

CVE-2026-23747 Overview

CVE-2026-23747 is a stack-based buffer overflow vulnerability in the Golioth Firmware SDK affecting versions 0.10.0 through 0.21.x. The vulnerability exists in the Payload Utils component, specifically within the golioth_payload_as_int() and golioth_payload_as_float() helper functions. These functions copy network-supplied payload data into fixed-size stack buffers using memcpy() with a length derived from payload_size. The critical flaw is that length validation checks are guarded by assert() statements, which are compiled out in release builds, allowing unbounded payload sizes to trigger stack buffer overflows.

Critical Impact

Attackers can trigger denial of service conditions by sending oversized payloads (greater than 12 bytes for int or 32 bytes for float conversions) via LightDB State on_payload callbacks, either through a malicious server or man-in-the-middle attack.

Affected Products

• Golioth Firmware SDK version 0.10.0 through 0.21.x
• IoT devices running affected SDK versions with LightDB State functionality enabled
• Systems using golioth_payload_as_int() or golioth_payload_as_float() payload utilities

Discovery Timeline

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

Technical Details for CVE-2026-23747

Vulnerability Analysis

This stack-based buffer overflow (CWE-121) vulnerability occurs due to insufficient input validation in the Golioth Firmware SDK's payload utility functions. The golioth_payload_as_int() and golioth_payload_as_float() functions are designed to convert raw byte payloads into native C types (int32_t and float, respectively). However, the implementation relies on assert() statements to validate payload sizes before performing memcpy() operations into fixed-size stack buffers.

In debug builds, these assertions would catch oversized payloads and terminate execution safely. However, when compiled for release (production) environments—where NDEBUG is typically defined—the assert() macros expand to nothing, removing all size validation. This allows an attacker to supply payloads exceeding the expected buffer sizes (12 bytes for integers, 32 bytes for floats), causing memcpy() to write beyond the stack buffer boundaries.

The vulnerability is remotely exploitable through the LightDB State on_payload callback mechanism, which processes data received over the network. An attacker with network access—either through a compromised server or man-in-the-middle position—can craft malicious payloads to trigger the overflow, resulting in stack corruption and denial of service.

Root Cause

The root cause is improper reliance on debug-only assertions for security-critical input validation. The vulnerability stems from using assert() for bounds checking in the payload conversion utilities. Since assertions are intended for debugging and are removed in release builds through compiler optimization, the safety checks are eliminated precisely when they are most needed—in production deployments. Proper input validation should use runtime checks that persist regardless of build configuration.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability through two primary scenarios:

1. Malicious Server Attack: If an attacker controls or compromises the Golioth cloud service endpoint, they can send crafted LightDB State payloads to connected IoT devices
2. Man-in-the-Middle Attack: An attacker positioned between the IoT device and the legitimate server can intercept and modify payload data in transit

The attack payload must exceed the expected buffer sizes—more than 12 bytes for golioth_payload_as_int() or more than 32 bytes for golioth_payload_as_float()—to trigger the stack overflow and cause a crash.

// Security patch in include/golioth.h - src: split lightdb into state and stream
 #include "golioth_status.h"
 #include "golioth_client.h"
 #include "golioth_log.h"
-#include "golioth_lightdb.h"
+#include "golioth_lightdb_state.h"
+#include "golioth_lightdb_stream.h"
 #include "golioth_rpc.h"
 #include "golioth_ota.h"
+#include "golioth_payload_utils.h"
 #include "golioth_fw_update.h"
 #include "golioth_settings.h"
 #include "golioth_debug.h"

Source: GitHub Commit 48f521b

// Security patch in include/golioth_payload_utils.h - src: split lightdb into state and stream
+/*
+ * Copyright (c) 2023 Golioth, Inc.
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ */
+
+#pragma once
+
+#include <stdbool.h>
+#include <stdint.h>
+
+
+/// @defgroup golioth_payload_utils golioth_payload_utils
+/// Functions for converting JSON types into C types
+/// @{
+
+/// Convert raw byte payload into an int32_t
+///
+/// @param payload Pointer to payload data
+/// @param payload_size Size of payload, in bytes
+///
+/// @return int32_t value returned from strtol(payload, NULL, 10)
+int32_t golioth_payload_as_int(const uint8_t* payload, size_t payload_size);
+
+/// Convert raw byte payload into a float
+///
+/// @param payload Pointer to payload data
+/// @param payload_size Size of payload, in bytes
+///
+/// @return float value returned from strtof(payload, NULL)

Source: GitHub Commit 48f521b

Detection Methods for CVE-2026-23747

Indicators of Compromise

• Unexpected device crashes or reboots coinciding with LightDB State synchronization events
• Network traffic containing unusually large payload sizes (exceeding 12 bytes for integer values or 32 bytes for float values) in CoAP or MQTT communications to Golioth endpoints
• Stack corruption signatures in device crash logs or memory dumps
• Abnormal patterns in server-to-device communication indicating potential MITM activity

Detection Strategies

• Monitor firmware logs for crash events associated with golioth_payload_as_int() or golioth_payload_as_float() function calls
• Implement network traffic analysis to detect oversized payload transmissions targeting IoT devices using the Golioth SDK
• Deploy SentinelOne Singularity for IoT to provide behavioral analysis and crash detection on supported embedded platforms
• Audit connected device firmware versions against the vulnerable range (0.10.0 through 0.21.x)

Monitoring Recommendations

• Enable verbose logging on IoT devices to capture payload processing events and potential crash indicators
• Implement TLS certificate pinning to reduce MITM attack surface for server communications
• Use network segmentation to isolate IoT devices and monitor cross-segment traffic for anomalies
• Establish baseline behavioral patterns for device communication to identify deviations indicative of exploitation attempts

How to Mitigate CVE-2026-23747

Immediate Actions Required

• Upgrade all affected devices to Golioth Firmware SDK version 0.22.0 or later immediately
• Audit deployed firmware to identify all instances running vulnerable SDK versions (0.10.0 through 0.21.x)
• Implement network-level payload size validation as a defense-in-depth measure while patching is in progress
• Review and restrict network access to IoT device communication channels to trusted endpoints only

Patch Information

The vulnerability has been addressed in commit 48f521b and is fully resolved in Golioth Firmware SDK version 0.22.0. The fix refactors the LightDB functionality by splitting it into separate state and stream components and introduces proper payload utilities with runtime bounds checking that persists in release builds.

For detailed patch information, refer to:

• GitHub Commit 48f521b
• GitHub Release v0.22.0

Additional security advisories are available from:

• SecMate Disclosure SECMATE-2025-0015
• VulnCheck Advisory

Workarounds

• If immediate patching is not possible, implement application-level payload size validation before calling golioth_payload_as_int() or golioth_payload_as_float() functions
• Consider compiling firmware with assertions enabled (-UNDEBUG) as a temporary measure, though this may impact performance
• Deploy network-level filtering to reject oversized payloads before they reach vulnerable devices
• Use TLS with mutual authentication and certificate pinning to mitigate MITM attack vectors

# Configuration example - Verify SDK version and plan upgrade
# Check current Golioth SDK version in your project
grep -r "golioth-firmware-sdk" west.yml || grep -r "golioth" CMakeLists.txt

# Update to patched version v0.22.0
cd path/to/your/project
west config manifest.project-filter -- +golioth-firmware-sdk
west update golioth-firmware-sdk

# Alternatively, update west.yml manifest to reference v0.22.0
# revision: v0.22.0