CVE-2026-23747
Stack-Based Buffer Overflow in Golioth Firmware SDK Causes DoS
Publication date: 2026-02-26
Last updated on: 2026-02-27
Assigner: VulnCheck
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| golioth | golioth_firmware_sdk | to 0.22.0 (exc) |
Helpful Resources
Exploitability
| 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.