CVE-2026-23748 Overview
CVE-2026-23748 is an integer underflow vulnerability (CWE-191) affecting the Golioth Firmware SDK, specifically in the LightDB State string parsing functionality. When processing a string payload, a payload_size value less than 2 can cause a size_t underflow when computing the number of bytes to copy (nbytes). The subsequent memcpy() operation reads past the end of the network buffer, which can crash the device. This condition is reachable from the on_payload function, and the golioth_payload_is_null() check does not block payloads where payload_size==1. A malicious server or man-in-the-middle attacker can trigger a denial of service condition on affected IoT devices.
Critical Impact
A malicious server or MITM attacker can cause device crashes via out-of-bounds memory reads, resulting in denial of service for IoT devices running affected firmware SDK versions.
Affected Products
- Golioth Firmware SDK version 0.10.0
- Golioth Firmware SDK versions prior to 0.22.0
- IoT devices using vulnerable Golioth Firmware SDK versions
Discovery Timeline
- 2026-02-26 - CVE CVE-2026-23748 published to NVD
- 2026-02-26 - Last updated in NVD database
Technical Details for CVE-2026-23748
Vulnerability Analysis
The vulnerability resides in the src/lightdb_state.c file within the Golioth Firmware SDK. During LightDB State string parsing, the code attempts to remove leading and trailing quotation marks from string values by calculating the number of bytes to copy as payload_size - 2. However, no validation exists to ensure that payload_size is at least 2 bytes before performing this arithmetic operation.
When payload_size is 0 or 1, the subtraction payload_size - 2 causes an integer underflow because size_t is an unsigned type. This results in an extremely large value (near the maximum value of size_t), which is then used as the length parameter for memcpy(). The subsequent memory copy operation reads far beyond the allocated network buffer boundaries, leading to an out-of-bounds read condition that crashes the device.
The vulnerability is exploitable over the network, as it can be triggered by either a malicious server or an attacker in a man-in-the-middle position who can inject crafted payloads with undersized string values.
Root Cause
The root cause is insufficient input validation before performing arithmetic operations on the payload_size variable. The code assumed string payloads would always be at least 2 bytes (accounting for opening and closing quotation marks) without explicitly verifying this precondition. The existing golioth_payload_is_null() function does not guard against the edge case where payload_size equals 1, allowing the vulnerable code path to be reached.
Attack Vector
The attack can be executed remotely over the network. An attacker with the ability to control or intercept server-to-device communications can craft a malicious LightDB State response containing a string payload with payload_size of 0 or 1. When the vulnerable device processes this payload through the on_payload callback, the integer underflow triggers an out-of-bounds memory read, causing the device to crash and resulting in a denial of service condition.
break;
case LIGHTDB_GET_TYPE_STRING:
{
- // Remove the leading and trailing quote to get the raw string value
+ if (payload_size < 2)
+ {
+ /* Strings must be wrapped in quotation marks */
+ GLTH_LOGE(TAG, "Received invalid string");
+ break;
+ }
+
+ /* Remove the leading and trailing quote to get the raw string value */
size_t nbytes = min(ldb_response->buf_size - 1, payload_size - 2);
memcpy(ldb_response->buf, payload + 1 /* skip quote */, nbytes);
ldb_response->buf[nbytes] = 0;
Source: GitHub Commit Update
Detection Methods for CVE-2026-23748
Indicators of Compromise
- Unexpected device crashes or reboots during LightDB State operations
- Memory access violation logs or crash dumps indicating out-of-bounds reads in lightdb_state.c
- Network traffic containing abnormally small string payloads (0-1 bytes) in LightDB State responses
- Repeated device disconnection and reconnection patterns indicating DoS conditions
Detection Strategies
- Monitor firmware SDK version inventory to identify devices running Golioth Firmware SDK versions prior to 0.22.0
- Implement network intrusion detection rules to flag LightDB State responses with suspicious payload sizes
- Deploy endpoint monitoring to detect crash patterns associated with memory access violations in IoT device firmware
- Review device logs for error messages related to string parsing failures in LightDB operations
Monitoring Recommendations
- Enable crash reporting and telemetry on IoT devices to capture memory violation events
- Monitor network traffic between IoT devices and Golioth servers for anomalous payload patterns
- Implement device health monitoring to detect unexpected reboot cycles indicative of denial of service attacks
- Configure alerting for devices running firmware SDK versions below the patched release
How to Mitigate CVE-2026-23748
Immediate Actions Required
- Update Golioth Firmware SDK to version 0.22.0 or later immediately
- Inventory all IoT devices and firmware deployments using Golioth Firmware SDK to identify affected systems
- Prioritize firmware updates for devices exposed to untrusted networks or operating in environments where MITM attacks are feasible
- Implement network segmentation to isolate vulnerable IoT devices from potential attackers
Patch Information
The vulnerability has been fixed in Golioth Firmware SDK version 0.22.0. The security patch (commit d7f55b38) adds explicit validation to ensure payload_size is at least 2 bytes before performing the subtraction operation. If the validation fails, the code logs an error message and safely exits the string processing path without performing the vulnerable memcpy() operation.
For more details, see the GitHub Commit Update and GitHub Release v0.22.0.
Additional security advisories are available from VulnCheck Security Advisory and Secmate Disclosure SECMATE-2025-0016.
Workarounds
- Implement TLS certificate pinning to prevent man-in-the-middle attacks that could inject malicious payloads
- Deploy network-level filtering to block potentially malicious LightDB State responses before they reach devices
- Isolate affected devices behind firewalls that restrict communication to trusted Golioth infrastructure only
- Consider disabling LightDB State functionality temporarily if not critical to device operation until patches can be applied
# Configuration example
# Update Golioth Firmware SDK to patched version
# In your project's west.yml or dependencies configuration:
manifest:
projects:
- name: golioth-firmware-sdk
url: https://github.com/golioth/golioth-firmware-sdk
revision: v0.22.0
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


