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.
Security readout for executives and security teams
Plain-English summary
Some devices built with vulnerable Golioth Firmware SDK versions can crash when they receive oversized network payloads. The issue is most relevant where device payloads may come from a malicious server or a man-in-the-middle path. The provided sources identify denial of service, not data theft or code execution.
Executive priority
Prioritize remediation for deployed IoT products where device availability matters or server trust boundaries are complex. This is a moderate denial-of-service risk, not a confirmed active exploitation emergency based on the supplied sources.
Technical view
In SDK 0.10.0 before 0.22.0, golioth_payload_as_int() and golioth_payload_as_float() copy network payloads into fixed stack buffers. Release builds can remove assert-based length checks, allowing payloads over 12 or 32 bytes to overflow the stack and crash the device.
Likely exposure
Exposure is likely limited to products using affected Golioth Firmware SDK versions and these Payload Utils helpers, especially through LightDB State on_payload handling. Devices not using the affected SDK range or helper paths are not shown as affected by the supplied evidence.
Exploitation context
KEV is false, and the bundle does not provide evidence of active exploitation. The described attack requires a malicious server or MITM condition, with no privileges or user interaction. Public technical writeups exist, so vulnerable deployments should be treated as practically testable.
Researcher notes
The key weakness is CWE-121 caused by assert-only bounds checks around memcpy into fixed stack buffers. The CVSS 4.0 score is 6.3 with network reachability, low complexity, attack requirements present, and low availability impact. Evidence supports crash/DoS only.
Mitigation direction
Upgrade Golioth Firmware SDK to v0.22.0 or later where available.
Confirm patched forks include commit 48f521bcc0187ada2b9cbdad31dc380e6c7b7332.
Review Golioth release notes and vendor guidance for additional remediation details.
Rebuild and redeploy firmware images that include affected SDK code.
Reduce exposure to untrusted server or MITM paths until devices are updated.
Validation and detection
Inventory firmware images and dependency manifests for Golioth Firmware SDK versions before 0.22.0.
Search code for golioth_payload_as_int() and golioth_payload_as_float() usage.
Confirm LightDB State on_payload paths do not process untrusted oversized payloads on vulnerable builds.
Verify updated firmware contains the v0.22.0 fix or the named patch commit.
Track crashes or resets around LightDB State payload handling as possible indicators.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-121: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-121 · source CWE mapping
Stack-based Buffer Overflow
Stack-based Buffer Overflow represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.