CVE-2026-23747
Received Received - Intake
Stack-Based Buffer Overflow in Golioth Firmware SDK Causes DoS

Publication date: 2026-02-26

Last updated on: 2026-02-27

Assigner: VulnCheck

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-26
Last Modified
2026-02-27
Generated
2026-05-07
AI Q&A
2026-02-26
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
golioth golioth_firmware_sdk to 0.22.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-121 A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-23747 is a stack-based buffer overflow vulnerability in the Golioth Firmware SDK versions 0.10.0 up to but not including 0.22.0. It exists in the Payload Utils component, specifically in the helper functions golioth_payload_as_int() and golioth_payload_as_float(). These functions copy network-supplied payload data into fixed-size stack buffers using memcpy(), with the length of the copy derived from the payload_size parameter.

The vulnerability arises because the only length checks are implemented using assert() statements, which are removed in release builds. This means memcpy() may copy an unbounded amount of data, leading to a stack buffer overflow when payloads exceed 12 bytes for integers or 32 bytes for floats.

This overflow can cause the application to crash or result in denial of service. The vulnerability can be exploited via the LightDB State on_payload interface by a malicious server or a man-in-the-middle attacker.


How can this vulnerability impact me? :

This vulnerability can lead to a stack buffer overflow, which may cause the affected application to crash or become unavailable, resulting in a denial of service.

An attacker, such as a malicious server or a man-in-the-middle, can exploit this flaw by sending oversized payloads through the LightDB State on_payload interface, triggering the overflow.

While the vulnerability does not directly impact confidentiality or integrity, the denial of service can disrupt normal operations and availability of the system using the Golioth Firmware SDK.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': "This vulnerability involves a stack-based buffer overflow in the Golioth Firmware SDK's Payload Utils when processing network-supplied payloads larger than expected sizes. Detection would involve monitoring or inspecting network traffic interacting with the LightDB State on_payload interface for unusually large payloads exceeding 12 bytes for integers or 32 bytes for floats."}, {'type': 'paragraph', 'content': 'Since the vulnerability is triggered by payloads sent from a malicious server or a man-in-the-middle attacker, one detection approach is to capture and analyze CoAP traffic to the affected device, focusing on payload sizes in LightDB State messages.'}, {'type': 'paragraph', 'content': 'Specific commands to detect this might include using network packet capture tools such as tcpdump or Wireshark to filter and inspect CoAP packets:'}, {'type': 'list_item', 'content': "tcpdump -i <interface> -s 0 -w capture.pcap 'udp port 5683'"}, {'type': 'list_item', 'content': 'Then analyze capture.pcap in Wireshark, filtering for LightDB State payloads and checking payload sizes.'}, {'type': 'paragraph', 'content': 'Additionally, monitoring device logs or crash reports for stack overflow or crash symptoms related to payload processing may help detect exploitation attempts.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation step is to upgrade the Golioth Firmware SDK to version 0.22.0 or later, where the vulnerability has been fixed in commit 48f521b.

If upgrading immediately is not possible, consider implementing network-level protections such as filtering or blocking suspicious or oversized payloads targeting the LightDB State on_payload interface to prevent exploitation.

Additionally, avoid using release builds that compile out assert() checks without additional length validation, and consider adding explicit payload size checks before memcpy() operations in the Payload Utils.

Monitoring for unusual crashes or denial of service symptoms related to payload processing can also help in early detection and response.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart