SecMate was built for cases where source code cannot leave the operator’s environment and where repeatedly handing a model a large repository is too expensive. Our current workflow runs gpt-oss. It does not give the model a repository and hope for the best. It first recovers the program relations that matter, then gives the model a small question with the relevant source attached.

We do not call this model agnostic. The prompts, tools, context, and validation process are tuned for the models we use today. Switching to another model family, such as DeepSeek or Qwen, would require integration and evaluation work. Adopting a new version of a model already in use would also require evaluation and, if its interface or behavior changed, integration work. For a fixed source revision, build configuration, semantic models, candidate query, and evidence package, the graph extraction is repeatable. The model’s conclusion remains a judgment.

We presented this work at LeHack 2026 in From USB to ESP: Security Vulnerabilities in Espressif Firmware. This post is the analysis part: three vulnerabilities in Espressif USB host drivers that SecMate found automatically with this workflow. Researchers validated them, completed responsible disclosure, and received CVE assignments. The cases span bounds, lifetime, and concurrency.

The Engineering Problem

These constraints are common in product security. The source may contain customer intellectual property, fall under an NDA, or live in an environment with data residency requirements. Sending it to an external model service may be prohibited. Some teams also want control over what leaves their environment. That can include whether a provider attaches provenance metadata to generated files. Anthropic’s marking of generated images is one current example [20]. Cost matters too. A security analysis reads the same repository repeatedly as it follows paths, revisits callers and callees, and gathers support for each result.

SecMate was built for those constraints. Its analysis and inference run inside infrastructure controlled by the operator. The workflow uses the open-weight gpt-oss-20b and gpt-oss-120b models. OpenAI states that the smaller model can run with 16 GB of memory and that the larger model fits on a single 80 GB GPU [1].

Keeping inference local solves where it runs. It does not decide what code the model should see. A repository that is too large or noisy for a hosted model is still too large or noisy on premises.

Why Reduce Before Reasoning

Security bugs are rarely contained in one function. A length can enter through a parser, cross several fields, influence an allocation, and later reach a copy. A pointer can be stored in a structure, freed during teardown, and used again through a local alias.

Giving a model every file leaves it with two jobs: discover which code matters, then decide whether that code is vulnerable. The first job consumes most of the context and must be repeated for every candidate. It also makes the result difficult to audit because the model’s conclusion is no longer attached to a small, inspectable path.

SecMate treats the first job as program analysis. It indexes an exact source revision with its build context and semantic models. For each candidate, it extracts the relevant calls, control conditions, values, aliases, and source locations into a small package for review.

A frontier model can search with rg, open files, and follow a hypothesis. That is useful. Without an equivalent persistent analysis layer, it must find and retain those relationships while it investigates. SecMate keeps them outside the model.

For a fixed analysis configuration, that extraction follows the same graph relations every time. A reviewer can inspect the source path without rerunning the model.

Method: From Repository to Evidence Slice

Here is the path from a USB descriptor to a reportable finding.

Figure 1. The pipeline used in this article. The model reviews a focused hypothesis. A researcher decides whether it supports disclosure.

1. Build a program index

Full-codebase analysis is not a glob over sources and headers. For this C/C++ work, the unit is a translation unit plus the compilation command used for it. Headers are interpreted under specific macro definitions, include paths, and build options. The same .c file may appear more than once under different configurations. Clang’s JSON compilation database records those per-translation-unit commands [18]. Other languages need an equivalent front end for their compilation or runtime model. SecMate starts from an exact commit, the compilation commands, the macros and configuration in force, and any generated sources. The frontend preprocesses and parses the translation units, records source spans, resolves declarations and types, and links calls across files where the available information permits it.

Every node retains its file, line, and column. In this C/C++ analysis, it also retains the relevant build variant, translation unit, and macro expansion context. Within a run, a reviewer can open the exact line and build variant behind a claim.

That scope is part of the result. Conditional compilation, generated sources, missing build metadata, function pointers, and unresolved external code can all limit coverage. They must remain visible as unresolved facts instead of being silently treated as complete.

2. Build the AST, then identify what it is missing

The Abstract Syntax Tree records declarations, expressions, calls, assignments, and scopes. A call node shows that call syntax exists. It does not necessarily identify every function that can run. An if node records a branch. It does not establish which later statements the condition controls.

Figure 2. The syntax tree of the three files involved in the HID finding. It records local syntax, but not resolved cross-file control flow, data flow, or call/return behavior. The descriptor length read in one function and the release and later use in another are not related by those semantic edges here.

Security analysis therefore needs relations that are not present in the AST:

A CFG over-approximates possible execution order. It does not prove that every graph path is feasible. Alias and indirect call resolution are approximations too. Those limits matter when a candidate is validated.

3. Enrich the graph

The Code Property Graph described by Yamaguchi and colleagues brings syntax, control flow, and program dependence into one queryable representation [5]. At repository scale, the graph also needs resolved symbols and types, call and return relations, and alias information. Control and data dependence support slicing, which retains the statements relevant to a chosen operation and value [2] [3]. Interprocedural traversal must preserve call and return context instead of accepting arbitrary paths through the call graph [4].

Not every relation has the same status. Syntax and source spans come from the frontend. Control flow, dependence, call targets, and aliases are computed. Context-sensitive call and return relations, alias results, and classifications such as allocations, releases, copies, and locks sit on top of the base graph. Modern CPG specifications describe those calculated layers as overlays [17]. A parser error and an imprecise alias result create different kinds of uncertainty.

Figure 3. The same nodes, now carrying execution order, value flow, and resolved calls. The graph can now be traversed from an attacker-controlled source to a sink across file and function boundaries.

4. Run security analyses on the CPG

Lifetime is not an AST edge. To find a use-after-free, the analysis has to connect object identity, aliases, execution order, a release, and a later use of the same object. The same applies to the other bug classes:

• a bounds analysis starts at a copy or write and recovers the input length, destination extent, governing checks, and interprocedural path;
• a lifetime analysis connects allocation, aliases, release, replacement, and later use of the same abstract object;
• a race or double-free analysis identifies a candidate overlap between task or callback paths, then compares their access to shared state and the synchronization that should order them.

The graph does not know on its own that usb_host_transfer_free() ends an object’s lifetime, that usb_host_transfer_alloc() creates or replaces one, or that a project function provides synchronization. SecMate gets that knowledge from API and semantic models. They cover allocators, releases, copies, writes, locking primitives, and project functions. Those models are explicit inputs to the analysis.

Figure 4. Entry points, sinks, and lifetime operations such as the release are not syntactic facts. API and semantic models classify them on the graph before any vulnerability traversal runs.

Each analysis follows only the relations relevant to its question. Resolved call and return context stays with the path. So do the branch conditions. Before disclosure, the researcher checks concurrency eligibility, path feasibility, alias precision, and build coverage.

Figure 5. The lifetime traversal starts at the release and keeps the entry point, the governing branch, the reallocation, and the later uses. Those nodes and their edges become the evidence slice; the rest of the graph never reaches the model.

5. Materialize the evidence slice

For each candidate, SecMate collects the source nodes, call chain, control predicates, data or alias edges, and unresolved assumptions needed for review. The local model sees that package, not the repository. It tests a specific vulnerability hypothesis against the extracted path. A researcher then checks the source path, attack preconditions, and exploitability claim before disclosure.

The graph recovers program relations. The analysis selects the relevant path. The model reviews that path. Candidate discovery and path extraction happen before model review. A SecMate researcher validates every claim before it is reported. The model’s output is one input to that review.

This is what one such package looks like for the use-after-free presented later in this article:

Figure 6. A sanitized evidence package for the HID use-after-free: hypothesis, bounded path, object lifetime, governing condition, and the facts the analysis could not resolve. This package is what the local model reviews, and what the researcher audits afterward.

LLMxCPG and codebadger also use CPGs to guide repository investigation [6] [7].

Applying the Method to Espressif USB Host

ESP-IDF is Espressif’s development framework for its systems-on-chip [10]. The esp-usb repository contains USB host and device class drivers distributed through the ESP Component Registry [11].

We focused on USB host mode in the HID and UVC class drivers. Espressif documents the USB Host Library as the lowest public-facing API layer of the host stack. Class drivers sit above it and handle class-specific descriptors, transfers, callbacks, and device lifecycle events [12].

A connected USB device controls the descriptors and lengths consumed during enumeration. It also controls when it disconnects and how it behaves during transfers. That makes the class-driver boundary attacker-controlled even though the attack requires physical access. The findings affect host-side drivers, not Espressif’s USB device mode.

The following sections cite the public advisories and fixing commits for the affected versions, vulnerability details, and patches.

The Espressif Findings

GitHub classifies all three advisories as Moderate. Their CVSS 3.1 base scores are 6.8, 6.4, and 6.8. The affected and fixed versions above come from the published advisories [8] [13] [15].

CVE-2025-68656: HID Descriptor Use-After-Free

The first finding shows the method on a concrete lifetime path. During enumeration, a HID device advertises wReportDescriptorLength. The host uses that value for req->wLength. If the current control transfer is too small, usb_class_request_get_descriptor() frees hid_device->ctrl_xfer and allocates a larger transfer. The local ctrl_xfer pointer was captured before the free and remains unchanged:

 1usb_transfer_t *ctrl_xfer = hid_device->ctrl_xfer;
 2const size_t ctrl_size = hid_device->ctrl_xfer->data_buffer_size;
 3
 4if (ctrl_size < (USB_SETUP_PACKET_SIZE + req->wLength)) {
 5    usb_host_transfer_free(hid_device->ctrl_xfer);
 6    HID_RETURN_ON_ERROR(
 7        usb_host_transfer_alloc(USB_SETUP_PACKET_SIZE + req->wLength,
 8                                0, &hid_device->ctrl_xfer),
 9        "Unable to allocate transfer buffer for EP0");
10}
11
12usb_setup_packet_t *setup =
13    (usb_setup_packet_t *)ctrl_xfer->data_buffer;
14setup->bmRequestType = USB_BM_REQUEST_TYPE_DIR_IN |
15                       USB_BM_REQUEST_TYPE_TYPE_STANDARD |
16                       USB_BM_REQUEST_TYPE_RECIP_INTERFACE;

The AST contains every statement above. The security evidence is in the relationships between them:

Figure 7. A single usb_host_transfer_free() releases both the urb_t and the data_buffer it owns. The local ctrl_xfer pointer was read from the field before the branch. If reallocation succeeds, the field receives a new transfer but the local pointer still refers to the released urb_t when the setup packet is written through it; if allocation fails, the error path returns before that write.

The function then writes the USB setup packet through ctrl_xfer->data_buffer. Espressif’s advisory describes attacker-controlled writes to freed heap memory, arbitrary memory corruption, and potential code execution [8].

Espressif’s fix validates the requested length, performs any required reallocation, and only then reads the field into the local pointer [9]:

 1if (req->wLength > HID_MAX_REPORT_DESC_LEN) {
 2    return ESP_ERR_INVALID_SIZE;
 3}
 4
 5// Argument checks and lock acquisition omitted.
 6if (ctrl_size < required_size) {
 7    usb_host_transfer_free(hid_device->ctrl_xfer);
 8    if (usb_host_transfer_alloc(required_size, 0,
 9                                &hid_device->ctrl_xfer) != ESP_OK) {
10        hid_device->ctrl_xfer = NULL;
11        hid_device_unlock(hid_device);
12        return ESP_ERR_NO_MEM;
13    }
14}
15
16usb_transfer_t *ctrl_xfer = hid_device->ctrl_xfer;
17usb_setup_packet_t *setup =
18    (usb_setup_packet_t *)ctrl_xfer->data_buffer;

The reported stale alias disappears when the alias is created after the field replacement. The same patch caps report descriptors at 2048 bytes, handles allocation failure, and enables tests for large report descriptors. This is the finding we took into the exploitation work.

CVE-2025-68657: HID Close-Path Race

The second HID issue is in teardown rather than descriptor parsing. USB event handling and application code can both reach hid_host_device_close() while sharing the same hid_iface_t state. Existing FreeRTOS critical sections and device_busy serialize parts of this path, but they do not make the READY-state check and transfer release one atomic operation across both callers. Two callers can therefore proceed to free the same usb_transfer_t [13].

This requires evidence from two execution paths. A single-function pattern can find the release operation, but it cannot establish competing ownership or determine whether the existing synchronization covers the state-check-to-release transition.

Figure 8. The analysis needs evidence of three things: two paths that may execute in parallel, the same abstract transfer object reached from both, and a gap in the synchronization of the state-check-to-release transition. The fix adds a mutex that covers that transition.

Espressif’s fix adds an open_close_mutex and holds it across the open and close paths, including the state check and interface removal [14]. The advisory also records an important practical limit: the READY-to-free window is estimated at 0.1 to 1 microsecond, while detach handling and application reaction occur on a millisecond scale. The proof of concept widened that window to demonstrate the issue deterministically [13].

CVE-2025-68622: UVC Descriptor Stack Overflow

The UVC finding is a direct bounds path in print_vs_frame_mjpeg_desc(). When configuration-descriptor printing is enabled, the function reads the device-controlled bLength and copies that many bytes into raw_desc[25], a 100-byte stack buffer:

1uint32_t raw_desc[25];
2uint32_t desc_size = ((const uvc_frame_desc_t *)_desc)->bLength;
3memcpy(raw_desc, _desc, desc_size);

A UVC frame descriptor can contain a variable-length frame-interval array. The vulnerable code did not compare desc_size with sizeof(raw_desc) before the copy. A malicious camera could therefore corrupt the stack during enumeration when CONFIG_UVC_PRINTF_CONFIGURATION_DESCRIPTOR was enabled [15].

Figure 9. A bounds finding appears when a device-controlled copy length is not checked against the destination extent on the analyzed path. Here the destination holds 100 bytes and no predicate on that path relates the two. The build condition is part of the evidence because the vulnerable path is compiled only when descriptor printing is enabled.

Espressif fixed the issue in commit 77a38b1 by removing the temporary stack copy and reading the descriptor directly. The commit applies the same change to both MJPEG and frame-based descriptor printers [16].

Fixes

Users of the affected components should update usb_host_hid to 1.1.0 or later and usb_host_uvc to 2.4.0 or later. Products that vendor or fork these components should verify that the three fixing commits are present rather than relying only on package metadata.

The three findings also show why one generic code excerpt is not enough for automated vulnerability research. The UVC overflow needs a source, destination extent, and missing bound. The HID use-after-free needs object identity across an alias, free, field replacement, and later use. The close-path race needs two potentially concurrent teardown paths over the same shared object and the synchronization governing their state-check-to-release transition.

Static analysis identifies the stale write in CVE-2025-68656 and reconstructs the device-controlled path to it. Turning that into a working exploit asked a different set of questions: allocator behavior, heap reuse, and how much a malicious USB device actually controls on the ESP32 target. That is where the analysis stops and the target-specific work begins.

References

• [1] OpenAI. “Introducing gpt-oss.” August 5, 2025. Product and model specifications

• [2] Mark Weiser. “Program Slicing.” IEEE Transactions on Software Engineering, 1984. DOI

• [3] Jeanne Ferrante, Karl J. Ottenstein, and Joe D. Warren. “The Program Dependence Graph and Its Use in Optimization.” ACM Transactions on Programming Languages and Systems, 1987. DOI

• [4] Thomas Reps, Susan Horwitz, and Mooly Sagiv. “Precise Interprocedural Dataflow Analysis via Graph Reachability.” POPL, 1995. DOI

• [5] Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. “Modeling and Discovering Vulnerabilities with Code Property Graphs.” IEEE Symposium on Security and Privacy, 2014. Paper

• [6] Ahmed Lekssays, Hamza Mouhcine, Khang Tran, Ting Yu, and Issa Khalil. “LLMxCPG: Context-Aware Vulnerability Detection Through Code Property Graph-Guided Large Language Models.” 34th USENIX Security Symposium, 2025. Paper and presentation

• [7] Ahmed Lekssays. “Bridging Code Property Graphs and Language Models for Program Analysis.” Software Vulnerability Management Workshop @ ICSE 2026. Paper

• [8] Espressif. “USB Host HID Descriptor Use-After-Free Vulnerability.” GHSA-2pm2-62mr-c9x7

• [9] Espressif. “Changed the handling of reallocating ctrl_xfer buffer on large report descriptors” (81b37c9, November 25, 2025). Fix commit

• [10] Espressif. “Espressif IoT Development Framework.” Repository

• [11] Espressif. “Espressif ESP-USB.” Repository

• [12] Espressif. “USB Host.” ESP-IDF Programming Guide. Documentation

• [13] Espressif. “Double-Free Race Condition in USB Host HID Device Close Path.” GHSA-gp8r-qjfr-gqfv

• [14] Espressif. “Fixed race condition in hid_host_device_close()” (cd28106, January 9, 2026). Fix commit

• [15] Espressif. “Stack buffer overflow in UVC descriptor printing.” GHSA-g65h-9ggq-9827

• [16] Espressif. “Fixed potential buffer overflow in descriptor printing” (77a38b1, November 21, 2025). Fix commit

• [17] The Code Property Graph specification. “Overlays.” Specification

• [18] Clang. “JSON Compilation Database Format Specification.” Documentation

• [19] Anthropic. “Assessing Claude Mythos Preview’s cybersecurity capabilities.” April 2026. Research

• [20] Anthropic. “How Claude marks AI-generated content.” Support documentation

The SecMate Team

Tuya is an IoT platform vendor. Its developer documentation describes a public-cloud platform for smart-device development, covering hardware development tools, app tools, cloud services, and smart-industry development [1].

SecMate found four vulnerabilities in arduino-tuyaopen [2], Tuya’s Arduino framework for connected devices. The issues affect DNS parsing, Tuya Data Point handling, Wi-Fi credential storage, and UDP packet reception: CVE-2026-28519, CVE-2026-28521, CVE-2026-28520, and CVE-2026-28522.

The bugs are in reusable framework libraries. They do not form one exploit chain, and the evidence does not support a claim that every TuyaOpen device is affected.

All four issues were fixed in commit 54ac201 on February 25, 2026 [6]. The fixes later shipped in the 1.2.1 release line [8].

Vulnerability Map

Affected Code and Use Cases

The vulnerable implementations referenced in this post are from public repository code around commit eaec2c903e2e629f9c53da789c39e12ea226d0b2 [2]. Public history places the affected paths between August and November 2024, with fixes landing on February 25, 2026 [3] [4] [5] [6].

arduino-tuyaopen ships as an Arduino board package for targets including t2, t3, t5, ln882h, and esp32 [2]. The relevant libraries are used for captive-portal DNS handling, UDP packet reception, Wi-Fi connection fallback, and Tuya cloud DP processing.

At a reachability level, the DNS and UDP issues are adjacent-network issues: the attacker must be on the same LAN or AP-side network path as the device. The WiFiMulti issue is a local Wi-Fi/provisioning issue: the device must consume attacker-controlled AP or Wi-Fi credential data. The TuyaIoT DP issue is a device-control-path issue: attacker-controlled DP event data must reach the device through the Tuya cloud path.

A product does not inherit all four attack paths by default. Exposure depends on whether the affected library is present in the firmware and connected to the corresponding attacker-controlled input.

Recommendations

• Update arduino-tuyaopen to the 1.2.1 release line or later, or to a commit containing 54ac201.
• If TuyaOpen libraries were vendored into firmware, check whether the February 25, 2026 fixes are present.
• If firmware exposes captive-portal DNS handling, reject malformed or oversized QNAME inputs before copying into fixed buffers.
• If firmware uses WiFiUDP, test receive paths under allocation failure and low-memory conditions.
• Treat Wi-Fi provisioning data and Tuya DP indexes as untrusted unless the application enforces bounds before calling framework helpers.

Timeline

Takeaway

The common issue is not Tuya cloud. It is memory safety in reusable firmware framework code. DNS helpers, UDP receive paths, Wi-Fi provisioning helpers, and cloud-event accessors often become part of product firmware.

The highest-confidence impacts are same-network memory corruption where the DNS helper is exposed, denial of service in UDP receive paths under low-memory conditions, and memory-safety failures in helper APIs that downstream firmware may treat as safe building blocks.

For the full list of our disclosures, see our disclosure page at secmate.dev/disclosures.

References

• [1] Tuya. “Tuya Developer Platform.” Documentation

• [2] Tuya. “arduino-tuyaopen repository.” Repository

• [3] Tuya. “add ble&wifi libraries (b6d68ec, August 6, 2024).” Commit

• [4] Tuya. “add http mqtt (89be820, November 21, 2024).” Commit

• [5] Tuya. “Update TuyaIoT libraries (53bf5bc, August 27, 2024).” Commit

• [6] Tuya. “Fix security issues (54ac201, February 25, 2026).” Commit

• [7] Tuya SRC. “Announcement 32.” Announcement page

• [8] Tuya. “1.2.0 to 1.2.1 comparison.” Repository diff

The SecMate Team

SecMate found seven vulnerabilities in Renesas FSP [1], the Flexible Software Package for Renesas RA microcontrollers [2]. FSP is the vendor software stack for RA devices and bundles BSP code, HAL drivers, middleware, and security integrations, including hardware-backed cryptography and Mbed TLS support.

In the v6.1.0 FSP codebase we analyzed at commit ed247f90fb9bc390ebd36f1a0b7847b0ff44f322 [3], we found issues in RSA verification, the hardware-accelerated AES-XTS path, GCM decrypt handling, and the RMAC receive path. These are implementation flaws in FSP integration code around hardware-backed cryptography and networking. They are not flaws in AES, GCM, CCM, XTS, or RSA as algorithms.

Advisory Map

The AES-XTS advisory covers two findings, one in the encrypt finalization path and one in the decrypt finalization path.

Affected Builds and Use Cases

SecMate’s published disclosure advisories are available on the SecMate disclosures page [4]. The table above links both the SecMate advisory and the corresponding Renesas public advisory for each vulnerability group.

These cryptography-related findings do not apply to every RA build. In FSP, the accelerated AES and AEAD paths are compiled for devices with SCE5, SCE5B, SCE7, SCE9, or RSIP support, and the XTS path is excluded on RA2 parts.

In downstream products, these APIs may be used for signature verification, authenticated decryption, encrypted storage, firmware update, or other security-sensitive processing. Exposure therefore depends on whether untrusted inputs can reach those wrappers.

The RMAC finding is separate from the cryptographic code paths. It affects products using the Ethernet receive API if application code provides a buffer smaller than the received frame.

Renesas PSIRT acknowledged the reports and published public advisories on GitHub.

Recommendations

• If you use affected RA builds, review the Renesas advisories and update to FSP v6.3.0 or later.
• In downstream products, check whether untrusted inputs can reach FSP wrappers used for signature verification, authenticated decryption, encrypted storage, or firmware update handling.
• Add negative tests for malformed signatures, AEAD metadata, XTS lengths, and oversized Ethernet frames.
• If you use r_rmac, verify that receive buffers are sized for the largest frame your product accepts.

Timeline

Takeaway

The common thread is not broken cryptography. It is memory safety in the FSP code that exposes cryptographic and Ethernet functionality to RA applications. Hardware-backed cryptography still depends on the surrounding integration code.

For the full list of our disclosures, see our disclosure page [4]. If you are building embedded systems and want to find vulnerabilities before attackers do, reach out.

References

• [1] Renesas. “Renesas Flexible Software Package.” GitHub. Repository

• [2] Renesas. “Renesas Flexible Software Package Documentation.” Documentation

• [3] Renesas. “FSP v6.1.0 analyzed commit” (ed247f90fb9bc390ebd36f1a0b7847b0ff44f322). Commit

• [4] SecMate. “Disclosures.” Disclosure page

• [5] Renesas. “FSP v6.3.0.” GitHub Releases. Release

The SecMate Team

SecMate’s automated analysis found six vulnerabilities in Siemens SICAM SIAPP SDK before version 2.1.7. The set includes one out-of-bounds write in shipped sample code, one stack buffer overflow in the shipped DemoProject, two stack overflows in UNIX socket path handling, one command injection in UNIX socket permission handling, and one uncontrolled file or socket deletion issue caused by unchecked unlink().

SIAPP SDK is Siemens’ development kit for building custom containerized applications that run on SICAM A8000 equipment used in substation automation, distribution grids, and other power-automation environments. These findings concern the SIAPP SDK path for custom applications; they do not, by themselves, imply that the core SICAM A8000 firmware or Siemens-provided standard functionality is affected by default.

Taken together, the bugs fall into two buckets: four issues in the SDK’s UNIX socket helper code and two in sample applications Siemens ships as part of the developer workflow.

Exploitability depends on how downstream applications use the SDK, whether untrusted input reaches the affected paths, and whether hardening measures are applied.

In the public repository history, five of the six affected code paths trace back to the initial public commit on June 10, 2020 and remained there until Siemens fixed them in SIAPP SDK 2.1.7 on January 16, 2026. That is 2,046 days in the public repository.

The sixth affected code path appears later, on March 19, 2021, and remained until the same 2.1.7 fix, for 1,764 days in the public repository.

Siemens published these issues in advisory SSA-903736 on March 10, 2026 [1].

What Is SICAM SIAPP SDK?

SIAPP SDK is Siemens’ development kit for building and emulating SIAPPs, containerized applications intended to run on the SICAM A8000 family [2] [3] [4] [5]. Siemens’ documentation describes SIAPP as an application model for CP-8031 and CP-8050 processor modules; developers build an app as a Docker image, emulate it locally, and then load it onto the device [3] [4].

The SDK includes:

• build and emulation tooling
• an EdgeData API for exchanging signals with the platform [6]
• example applications such as DemoProject, DemoSshd, and CodeSnippets
• a local simulation environment for testing SIAPP behavior off-device

Siemens markets SICAM A8000 for substation automation, distribution grids, renewable integration, and industrial power [5]. This equipment is used to monitor and control parts of the electrical grid and adjacent industrial power systems. Its SIAPP material describes use cases such as transformer controllers, energy-storage optimization, weather-driven renewable control, and energy-trading optimization [4], and the launch material frames the platform for customers such as major energy suppliers, municipal utilities, and industrial companies [7]. The SIAPP SDK is the official development kit for building custom applications in that environment.

The developer workflow in the repository is straightforward [3]:

1. Write a SIAPP project with a Dockerfile
2. Build it with build.py
3. Test it with run.py and the local simulation flow
4. Deploy it to a SICAM A8000 target

The SDK ships starter applications to accelerate that process. DemoProject is a small web application exposing configured signals. DemoSshd is a test container with SSH access. CodeSnippets contains small example programs showing how to use the EdgeData API. That matters because this is the code developers are most likely to copy into real projects.

Siemens’ advisory is careful on scope: these are not generic internet-wide bugs in every installation. As Siemens states, they are exploitable if the API is used improperly or hardening measures are not applied [1]. In practice, that puts weight on the SDK itself, because developers learn the safe and unsafe paths from the code Siemens ships.

Public Repository Timeline

Five of the six vulnerabilities trace back to the initial public commit on June 10, 2020 [8] [10]:

• CVE-2026-25569 in CodeSnippets/src/helper.c
• CVE-2026-25571 in edgedataapi/src/edgedata.cpp
• CVE-2026-25572 in edgedataapi/src/edgedata.cpp
• CVE-2026-25573 in edgedataapi/src/edgedata.cpp
• CVE-2026-25605 in edgedataapi/src/edgedata.cpp

The one later issue was introduced on March 19, 2021 [9]:

• CVE-2026-25570 in DemoProject/src/demo.cpp

Four of the six vulnerabilities live in the UNIX socket IPC helper code used by the SDK. The other two live in sample applications Siemens ships as part of the developer workflow.

Vulnerability #1: CodeSnippets Helper Out-of-Bounds Write (CVE-2026-25569 [11])

Location: helper_get_edgedata_text() in CodeSnippets/src/helper.c
Introduced: ff331c2 on June 10, 2020
Fixed: e4edda8 on January 16, 2026
Siemens advisory: CVSS v3.1 7.4 [1]

This issue is in the CodeSnippets sample application, not in the shared IPC helper. The helper helper_get_edgedata_text() formats multiple fields into a caller-provided buffer and advances pos using each snprintf() return value without validating truncation:

1pos += (uint32_t)snprintf(&edgedata_to_text[pos], (max_len_edgedata_to_text-pos), "Topic: %s", edge_data->topic);
2pos += (uint32_t)snprintf(&edgedata_to_text[pos], (max_len_edgedata_to_text-pos), ", Type:");
3pos += helper_get_data_type_text(edge_data, &edgedata_to_text[pos], (max_len_edgedata_to_text-pos));

If a topic exceeds remaining space, pos can move beyond the real buffer boundary, and subsequent writes can go out of bounds. In the shipped examples, discover.c, subscribe.c, and simple_dido.c call this helper with fixed 300-byte stack buffers, so oversized topic strings can trigger stack corruption.

Vulnerability #2: DemoProject Floating-Point Formatting Stack Overflow (CVE-2026-25570 [12])

Location: convert_value_to_str() in DemoProject/src/demo.cpp
Introduced: 4139bfb on March 19, 2021
Fixed: e4edda8 on January 16, 2026
Siemens advisory: CVSS v3.1 7.4 [1]

This issue is in the DemoProject sample application. convert_value_to_str() writes to fixed-size buffers (including char value_str[50]) and used unbounded sprintf() for floating-point values:

1case E_EDGE_DATA_TYPE_FLOAT32:
2   sprintf(out_value, "%f", value->float32);
3   sprintf(out_type, "FLOAT32");
4   break;
5case E_EDGE_DATA_TYPE_DOUBLE64:
6   sprintf(out_value, "%lf", value->double64);
7   sprintf(out_type, "DOUBLE64");
8   break;

Large floating-point values can expand to strings longer than 50 bytes, causing stack overflow in value_str. The formatter is used in /edgedata/get and /edgedata/get_events response paths, so oversized DOUBLE64 values can trigger memory corruption during XML serialization.

Vulnerability #3: Client UNIX Socket Path Overflow (CVE-2026-25571 [13])

Location: edgedata_ipc_unix_client_connect() in edgedataapi/src/edgedata.cpp
Introduced: ff331c2 on June 10, 2020
Fixed: e4edda8 on January 16, 2026
Siemens advisory: CVSS v3.1 5.1 [1]

This is a client-side length validation issue in the shared UNIX socket helper. edgedata_ipc_unix_client_connect() copies a caller-provided socket path into sockaddr_un.sun_path using strcpy() without bounds checking:

1strcpy(addr.sun_path, fd->read_channel_name.c_str());

On Linux, sun_path is fixed-size (commonly 108 bytes). Longer paths can overflow the stack buffer before connect(). Exploitation depends on downstream integration: if untrusted or oversized input is passed into this API, the overflow is reachable.

Vulnerability #4: Server UNIX Socket Path Overflow (CVE-2026-25572 [14])

Location: edgedata_ipc_unix_server_listen() in edgedataapi/src/edgedata.cpp
Introduced: ff331c2 on June 10, 2020
Fixed: e4edda8 on January 16, 2026
Siemens advisory: CVSS v3.1 5.1 [1]

This is the server-side twin of the previous bug. The same unbounded copy is used when preparing the server socket address:

1strcpy(addr.sun_path, fd->read_channel_name.c_str());

If a downstream application accepts an untrusted socket path and forwards it into the SDK, the server helper can overflow the stack before bind() runs. As with the client-side variant, the default examples do not expose this path directly to attackers; the precondition is still misuse at the API boundary.

Vulnerability #5: UNIX Socket Helper Command Injection (CVE-2026-25573 [15])

Location: edgedata_ipc_unix_server_listen() in edgedataapi/src/edgedata.cpp
Introduced: ff331c2 on June 10, 2020
Fixed: e4edda8 on January 16, 2026
Siemens advisory: CVSS v3.1 7.4 [1]

This issue is more serious because the vulnerable code does not just mishandle memory. It builds shell commands from caller-controlled strings and executes them:

1(void)snprintf(cmd, sizeof(cmd), "chown %s %s", user, addr.sun_path);
2(void)system(cmd);
3(void)snprintf(cmd, sizeof(cmd), "chmod 777 %s", addr.sun_path);
4(void)system(cmd);

If an application exposes user or channel_name to untrusted input, shell metacharacters become part of the command line interpreted by /bin/sh. This is not an abstract quoting issue. The helper literally concatenates caller-controlled data into a shell command and runs it.

As with the path overflows, exploitability depends on integration. The repository examples do not themselves expose arbitrary remote input for these parameters. But once a downstream application lets an untrusted user influence socket ownership or socket path values, the bug becomes command injection.

Vulnerability #6: Unchecked unlink() in UNIX Socket Setup (CVE-2026-25605 [16])

Location: edgedata_ipc_unix_server_listen() in edgedataapi/src/edgedata.cpp
Introduced: ff331c2 on June 10, 2020
Fixed: e4edda8 on January 16, 2026
Siemens advisory: CVSS v3.1 6.7 [1]

Before binding the server socket, the helper called:

1unlink(fd->read_channel_name.c_str());

There was no validation that the path pointed to an existing socket, no restriction to a dedicated socket directory, and no lstat() / S_ISSOCK guard. If a downstream application lets an untrusted party influence channel_name, the process can be induced to delete any file or socket it has permission to remove.

This does not automatically mean arbitrary file deletion from the network. The vulnerable operation is local to the API boundary, so the precondition is still that a caller passes untrusted data into the helper. But once that happens, the delete happens before the bind, with no type check at all.

What Siemens Fixed in 2.1.7

The SIAPP SDK 2.1.7 commit includes direct fixes in the affected code paths:

• strcpy() on sun_path was replaced with explicit length checks and bounded copies
• unconditional unlink() was replaced with lstat() and socket-type validation
• shell-based chown and chmod calls were replaced with getpwnam(), chown(), and chmod()
• sprintf() was replaced with bounded snprintf(), and the float formatting was changed from %f / %lf to %g
• the CodeSnippets helper was rewritten to check truncation after each append and to cap copied topic length

Disclosure Timeline

Closing Thoughts

Several of these patterns sat for years in a vendor SDK used to build software for power-automation environments.

Four of these vulnerabilities were in reusable UNIX socket SDK code, and two were in sample applications shipped to show developers how to build on the platform.

For SDK maintainers, especially in embedded and industrial systems, the lesson is simple: helper APIs and sample projects are part of the security boundary.

References

• [1] Siemens ProductCERT. “SSA-903736: Multiple vulnerabilities in SICAM SIAPP SDK before V2.1.7.” Published March 10, 2026. Advisory

• [2] Siemens. “siapp-sdk.” GitHub repository

• [3] Siemens. “SIAPP SDK README.” Repository documentation

• [4] Siemens. “SICAM application - SIAPP.” Product page

• [5] Siemens. “Automation and remote terminal units - SICAM A8000 Series.” Product page

• [6] Siemens. “EDGEDATAAPI.md.” Repository documentation

• [7] Siemens Press. “Siemens launches new platform to create customer-specific apps for distribution grids.” Published July 7, 2020. Press release

• [8] Siemens. “initial commit” (ff331c2, June 10, 2020). Commit

• [9] Siemens. “SIAPP SDK 1.1.1” (4139bfb, March 19, 2021). Commit

• [10] Siemens. “SIAPP SDK 2.1.7” (e4edda8, January 16, 2026). Commit

• [11] NVD. “CVE-2026-25569.” National Vulnerability Database. CVE

• [12] NVD. “CVE-2026-25570.” National Vulnerability Database. CVE

• [13] NVD. “CVE-2026-25571.” National Vulnerability Database. CVE

• [14] NVD. “CVE-2026-25572.” National Vulnerability Database. CVE

• [15] NVD. “CVE-2026-25573.” National Vulnerability Database. CVE

• [16] NVD. “CVE-2026-25605.” National Vulnerability Database. CVE

• [17] Email correspondence between SecMate and Siemens ProductCERT regarding siapp-sdk, January 3, 2026 to March 25, 2026. On file.

The SecMate Team

We discovered four memory safety vulnerabilities in Golioth’s Firmware SDK and Pouch BLE protocol: an unauthenticated BLE heap overflow, an integer underflow causing out-of-bounds reads, a stack buffer overflow guarded only by assert(), and an off-by-one strncpy bug. Each is independently triggerable under its own preconditions.

Three of the four chain together into a path from unauthenticated BLE proximity to remote code execution. Golioth’s defense-in-depth blocks this chain: server certificate validation (CONFIG_POUCH_VALIDATE_SERVER_CERT) is enabled by default and rejects injected certificates at step two.

What is Golioth?

Golioth [1] is an IoT device infrastructure platform for fleet management, OTA updates, data routing, and device monitoring. It ships two open-source products relevant to this research:

The Golioth Firmware SDK [1] is a C library for device-to-cloud communication over CoAP/DTLS [3]. It supports LightDB State (device-shadow key/value store), OTA firmware updates, logging, and settings. The SDK targets Zephyr RTOS, nRF Connect SDK, ESP-IDF, and Infineon ModusToolbox, running on hardware including the nRF9160, nRF52840, and ESP32.

Golioth Pouch [2] is a non-IP protocol for device-to-cloud communication through BLE gateways. Pouch uses BLE GATT for the device-to-gateway leg, with end-to-end encryption to the Golioth cloud. It is designed around an untrusted gateway model: gateways relay data but cannot inspect it. A BLE GATT server on the device exchanges certificates with a gateway, which then brokers the encrypted session.

SecMate’s automated analysis identified four memory safety vulnerabilities spanning both products.

One finding is particularly worth highlighting: a stack buffer overflow whose only bounds check is assert(), which the C standard defines as a debugging aid and which is compiled out of every release build. This pattern, using assert() as a security boundary, is common across embedded codebases and is almost always a vulnerability in production.

Architecture Overview

Firmware SDK: Device to Cloud

The Firmware SDK handles all cloud communication over CoAP/DTLS. The device authenticates to Golioth using a pre-provisioned certificate or PSK, then exchanges CoAP messages for state synchronization (LightDB State), firmware updates, and telemetry. Payloads arrive as raw byte buffers with an associated payload_size, and the parsing code trusts that relationship implicitly. The vulnerable code paths are in lightdb_state.c, payload_utils.c, coap_blockwise.c, and coap_client.c.

Pouch: Non-IP Gateway Protocol

Pouch is a non-IP protocol designed to route device traffic through BLE gateways to the Golioth cloud. Its security model is built around an untrusted gateway assumption: gateways are treated as opaque relays that forward data but cannot inspect or modify it, thanks to end-to-end encryption between the device and cloud. This is a deliberate design choice: the protocol explicitly considers the scenario where an intermediary gateway is compromised.

What makes the first vulnerability particularly notable is that Pouch’s threat model accounts for gateway compromise but not for unauthenticated BLE-level write access. The server certificate characteristic is registered with BT_GATT_PERM_WRITE, meaning any BLE client in range can write to it without pairing, bonding, or encryption. The untrusted gateway model protects data in transit, but the certificate exchange itself has no access control. This is the entry point for the attack chain.

Vulnerability #1: BLE GATT Server Certificate Heap Overflow (CVE-2026-23750 [4])

Location: server_cert_write() in server_cert_characteristic.c (Golioth Pouch)

This is the lead vulnerability and the entry point for the full chain. Any BLE client within radio range can trigger it: no pairing, no bonding, no authentication of any kind.

The Bug

The server_cert_write handler processes incoming BLE GATT writes to the server certificate characteristic. When the first fragment arrives, it allocates a fixed-size heap buffer. For every fragment, it blindly appends the payload:

 1// server_cert_characteristic.c:105-153
 2static ssize_t server_cert_write(struct bt_conn *conn,
 3                                 const struct bt_gatt_attr *attr,
 4                                 const void *buf,
 5                                 uint16_t len,
 6                                 uint16_t offset,
 7                                 uint8_t flags)
 8{
 9    struct golioth_ble_gatt_server_cert_ctx *ctx = attr->user_data;
10    bool is_first = false;
11    bool is_last = false;
12    const void *payload = NULL;
13    ssize_t payload_len =
14        golioth_ble_gatt_packetizer_decode(buf, len, &payload, &is_first, &is_last);
15
16    if (0 >= payload_len)
17    {
18        return BT_GATT_ERR(BT_ATT_ERR_UNLIKELY);
19    }
20
21    if (is_first)
22    {
23        free((void *) ctx->cert.buffer);
24        ctx->cert.buffer = malloc(CONFIG_POUCH_SERVER_CERT_MAX_LEN);  // Fixed-size allocation
25        ctx->cert.size = 0;
26    }
27
28    if (!ctx->cert.buffer)
29    {
30        return BT_GATT_ERR(BT_ATT_ERR_INSUFFICIENT_RESOURCES);
31    }
32
33    // ** VULNERABILITY: No check that ctx->cert.size + payload_len
34    //    <= CONFIG_POUCH_SERVER_CERT_MAX_LEN **
35    memcpy((void *) &ctx->cert.buffer[ctx->cert.size], payload, payload_len);
36    ctx->cert.size += payload_len;
37    // ...
38}

The critical issue is the memcpy call: it copies payload_len bytes into ctx->cert.buffer at offset ctx->cert.size without ever checking whether the cumulative size exceeds CONFIG_POUCH_SERVER_CERT_MAX_LEN. The packetizer decode function returns a length derived directly from the GATT write size. No upper bound is enforced.

The Permission Model

The characteristic is registered with:

1// server_cert_characteristic.c:155-161
2GOLIOTH_BLE_GATT_CHARACTERISTIC(server_cert,
3                                (const struct bt_uuid *) &golioth_ble_gatt_server_cert_chrc_uuid,
4                                BT_GATT_CHRC_READ | BT_GATT_CHRC_WRITE,
5                                BT_GATT_PERM_READ | BT_GATT_PERM_WRITE,  // No auth/encryption
6                                server_cert_serial_read,
7                                server_cert_write,
8                                &server_cert_chrc_ctx);

BT_GATT_PERM_WRITE grants write access to any connected BLE client. Compare this with BT_GATT_PERM_WRITE_ENCRYPT or BT_GATT_PERM_WRITE_AUTHEN, which require an encrypted link or authenticated pairing respectively. The weakest permission level was chosen.

Impact

An attacker can overflow the heap buffer in two ways:

1. Single large write: Send a GATT write whose decoded payload exceeds CONFIG_POUCH_SERVER_CERT_MAX_LEN in one shot.
2. Fragmented overflow: Send multiple fragments whose cumulative size exceeds the allocation.

On MCUs with deterministic heap layouts (no ASLR), the immediate impact is a crash (denial of service). Depending on the allocator implementation and heap layout, heap metadata corruption may also enable controlled overwrites, but exploitation reliability varies by target and configuration.

Beyond heap overflow, there is a subtler but equally dangerous impact: certificate injection. If the attacker writes a valid but attacker-controlled certificate within the buffer bounds (no overflow needed, just a normal-sized write), the device will accept it via pouch_server_certificate_set() and use it for subsequent encrypted sessions. This establishes a man-in-the-middle position without triggering any crash. Certificate injection opens the door to everything that follows.

Note: Pouch provides a server certificate validation option (CONFIG_POUCH_VALIDATE_SERVER_CERT, enabled by default) that checks injected certificates against an embedded CA. When this validation is active, the certificate injection is rejected. The attack chain requires this validation to be disabled, a configuration the build system explicitly warns against for production use.

Vulnerability #2: LightDB State String Underflow Out-of-Bounds Read (CVE-2026-23748 [5])

Location: lightdb_state.c (Golioth Firmware SDK)

Chain Context

With a rogue certificate injected via Vulnerability #1 and server certificate validation disabled, the attacker can sit in the middle of the device encrypted session to the Golioth cloud. From this position, they can craft arbitrary CoAP responses to any LightDB State query the device makes.

The Bug

When the SDK receives a LightDB State response for a string value, it strips the surrounding JSON quotes by copying from payload + 1 for payload_size - 2 bytes:

1// lightdb_state.c:408-414
2case LIGHTDB_GET_TYPE_STRING:
3{
4    // Remove the leading and trailing quote to get the raw string value
5    size_t nbytes = min(ldb_response->buf_size - 1, payload_size - 2);  // <-- UNDERFLOW
6    memcpy(ldb_response->buf, payload + 1 /* skip quote */, nbytes);
7    ldb_response->buf[nbytes] = 0;
8}
9break;

The Math

payload_size is a size_t, an unsigned type. When the server responds with a 1-byte payload:

payload_size = 1

payload_size - 2 = 1 - 2
                 = (size_t)(-1)
                 = 0xFFFFFFFF  (on 32-bit MCU)
                 = 4,294,967,295

The min() macro then selects ldb_response->buf_size - 1 (the smaller value, e.g., 63 or 127 depending on the caller’s buffer). The memcpy then reads that many bytes starting from payload + 1, which is already one byte past the end of the actual 1-byte payload buffer.

Why This Passes the Null Check

The code does check for null payloads before reaching this path:

1// lightdb_state.c:387-391
2if (golioth_payload_is_null(payload, payload_size))
3{
4    ldb_response->is_null = true;
5    return;
6}

But golioth_payload_is_null() only returns true for NULL pointers, zero-length payloads, or payloads starting with the string "null". A 1-byte payload like '"' passes through.

Impact

The memcpy reads buf_size - 1 bytes from memory adjacent to the payload buffer. On embedded devices with flat memory models, this can leak:

• DTLS session keys stored nearby in heap memory
• WiFi/BLE credentials
• Other application secrets

Even without useful data in adjacent memory, the out-of-bounds read will likely fault on unmapped regions, causing a device crash (DoS).

Vulnerability #3: Assert-Guarded Memcpy Stack Buffer Overflow (CVE-2026-23747 [6])

Location: golioth_payload_as_int() / golioth_payload_as_float() in payload_utils.c (Golioth Firmware SDK)

Chain Context

Still operating as MITM via the injected certificate, the attacker crafts an oversized integer or float payload in response to a LightDB State query.

The Bug

The payload parsing helpers use assert() as their sole bounds check:

 1// payload_utils.c:15-23
 2int32_t golioth_payload_as_int(const uint8_t *payload, size_t payload_size)
 3{
 4    // Copy payload to a NULL-terminated string
 5    char value[12] = {};
 6    assert(payload_size <= sizeof(value));   // <-- Only defense
 7    memcpy(value, payload, payload_size);    // <-- Unbounded in release
 8
 9    return strtol(value, NULL, 10);
10}
11
12// payload_utils.c:25-33
13float golioth_payload_as_float(const uint8_t *payload, size_t payload_size)
14{
15    // Copy payload to a NULL-terminated string
16    char value[32] = {};
17    assert(payload_size <= sizeof(value));   // <-- Only defense
18    memcpy(value, payload, payload_size);    // <-- Unbounded in release
19
20    return strtof(value, NULL);
21}

These functions are called directly from the network-facing on_payload() callback:

1// lightdb_state.c:395-396
2case LIGHTDB_GET_TYPE_INT:
3    *ldb_response->i = golioth_payload_as_int(payload, payload_size);
4    break;

The Anti-Pattern: assert() as a Security Check

The C standard defines assert() as a debugging aid. When the macro NDEBUG is defined, which is standard practice in release/production builds, assert() expands to nothing:

// <assert.h> with NDEBUG defined:
#define assert(expression) ((void)0)

Here is what the compiler sees in each build configuration:

Debug build (assert active):

1char value[12] = {};
2// assert fires, aborts if payload_size > 12
3((payload_size <= sizeof(value)) ? (void)0 : __assert_fail(...));
4memcpy(value, payload, payload_size);

Release build (NDEBUG defined):

1char value[12] = {};
2// assert compiled away --- nothing here
3((void)0);
4memcpy(value, payload, payload_size);  // copies whatever the network sent

In the release build, memcpy copies payload_size bytes, directly controlled by the network, into a 12-byte (or 32-byte) stack buffer with no bounds check whatsoever.

Impact

On MCUs where stack canaries are not enabled (common in Zephyr and ESP-IDF default configurations for size and performance reasons), this is a textbook stack buffer overflow:

• The attacker sends a LightDB State integer response with 100+ bytes of payload.
• memcpy writes past value[12], overwriting the saved frame pointer, return address, and any other locals on the stack.
• On Cortex-M (ARM Thumb), the saved return address on the stack is loaded into the PC. The attacker controls the PC.
• With a deterministic memory layout and a known firmware image, this enables control flow hijack and potential RCE on embedded targets without common mitigations.

The float variant (value[32]) requires a slightly larger payload but is otherwise identical.

Vulnerability #4: CoAP Blockwise Unterminated Path Out-of-Bounds Read (CVE-2026-23749 [7])

Location: blockwise_transfer_init() in coap_blockwise.c (Golioth Firmware SDK)

This vulnerability is locally triggered (by the application’s own path strings) rather than network-exploitable. We include it to complete the pattern of C memory safety hazards found across the SDK.

The Bug

 1// coap_blockwise.c:76-94
 2static int blockwise_transfer_init(struct blockwise_transfer *ctx,
 3                                   struct golioth_client *client,
 4                                   const char *path_prefix,
 5                                   const char *path,
 6                                   enum golioth_content_type content_type)
 7{
 8    if (strlen(path) > CONFIG_GOLIOTH_COAP_MAX_PATH_LEN)  // allows ==
 9    {
10        return -EINVAL;
11    }
12    strncpy(ctx->path, path, CONFIG_GOLIOTH_COAP_MAX_PATH_LEN);  // no NUL if len == max
13    // ...
14}

The buffer is declared as char path[CONFIG_GOLIOTH_COAP_MAX_PATH_LEN + 1], providing space for a NUL terminator. However, when strlen(path) is exactly CONFIG_GOLIOTH_COAP_MAX_PATH_LEN:

1. The > check passes (it should be >=).
2. strncpy copies exactly CONFIG_GOLIOTH_COAP_MAX_PATH_LEN bytes and does not append a NUL terminator (this is strncpy’s documented behavior when the source length equals or exceeds the count).
3. Later, strlen(ctx->path) in coap_client.c reads past the buffer searching for a NUL byte.

This is a classic strncpy misunderstanding. Many C developers assume strncpy always NUL-terminates. It does not when the source string fills the destination.

Impact

The out-of-bounds strlen() read can cause:

• A crash if it walks into unmapped memory
• Incorrect path construction if it finds a stale NUL byte further in memory
• On safety-critical IoT devices (medical, industrial), even a locally-triggered crash can have real-world consequences

Theoretical Chain: BLE Proximity to Device Compromise

The following attack chain is theoretical. It has not been demonstrated end to end. It requires CONFIG_POUCH_VALIDATE_SERVER_CERT to be disabled, which is not default and the build system explicitly warns against for production use. With certificate validation enabled, the default, the chain breaks at step 2 and injected certificates are rejected.

That said, the chain illustrates how individual memory safety bugs compound when defense-in-depth is weakened. If certificate validation were disabled, three of the four vulnerabilities could connect into a path from unauthenticated BLE proximity to arbitrary code execution:

Step-by-Step Walkthrough

1. BLE Discovery (~10-100m range): The attacker uses a BLE scanner (e.g., nRF Connect, a custom bleak script) to discover the Golioth GATT service and the server certificate characteristic UUID.

2. Certificate Injection: The attacker writes a valid, attacker-controlled X.509 certificate to the characteristic. Because BT_GATT_PERM_WRITE requires no authentication, this succeeds on first connection. The device calls pouch_server_certificate_set() and persists the certificate. No overflow is needed for this step. The certificate just needs to be within CONFIG_POUCH_SERVER_CERT_MAX_LEN.

3. MITM Established: When the device next initiates a session to the Golioth cloud, it uses the injected certificate to authenticate the server. The attacker, holding the corresponding private key, terminates the connection from the device and opens a separate connection to the real Golioth cloud, proxying traffic between the two. This step requires CONFIG_POUCH_VALIDATE_SERVER_CERT to be disabled; with validation enabled (the default), the injected certificate is rejected against the embedded CA and the chain breaks here.

4. Exploitation: From the MITM position, the attacker waits for, or triggers, a LightDB State query from the device, then:

   • For memory disclosure (Vuln 2): Responds with a 1-byte payload to a string GET, causing the underflow and OOB read. Leaked memory may contain DTLS keys or other secrets.
   • For code execution (Vuln 3): Responds with an oversized payload to an integer GET. In release builds, the assert is gone, and memcpy overwrites the stack. On Cortex-M with no ASLR or stack canaries, the return address is overwritten with an attacker-controlled value.

Feasibility and Limitations

• BLE range constraint: The initial step requires physical proximity. In practice, directional antennas can extend BLE range significantly, and many IoT deployments are in physically accessible locations.
• Certificate persistence: Whether the injected certificate persists across reboots depends on the Pouch configuration and storage backend. If persistent, the MITM survives power cycles.
• Release build requirement: Vulnerability 3 requires that NDEBUG is defined. This is the default for production firmware on all supported platforms.
• Certificate validation: The MITM step requires CONFIG_POUCH_VALIDATE_SERVER_CERT to be disabled. This option is enabled by default and validates server certificates against an embedded CA. When enabled, certificate injection is blocked.
• Vulnerability 4 is independent: The CoAP blockwise path issue is locally triggered and is not part of this chain.

Conclusion

Four memory safety vulnerabilities across two Golioth IoT products. Each is independently triggerable under its own preconditions. The BLE heap overflow, Vuln 1, is the most immediately dangerous: any device running Pouch with BLE enabled can be crashed or have its certificate store corrupted by an unauthenticated attacker in radio range.

The theoretical chain from BLE to RCE requires certificate validation to be disabled, which is not the default. But the individual bugs do not require special configuration. A 1-byte CoAP response triggers the integer underflow. An oversized integer payload overwrites the stack in any release build. These are real risks independent of any chain.

The bugs themselves are not exotic. They are memcpy without bounds checks, assert instead of if, strncpy without NUL termination, unsigned subtraction without underflow guards. These are patterns that every C programmer learns to avoid, and that every C codebase eventually contains unless the review process catches them.

Embedded firmware needs the same level of scrutiny as kernel code. It runs with equivalent privilege (there is no lower ring on a Cortex-M), handles untrusted input from multiple interfaces (BLE, WiFi, CoAP, MQTT), and deploys to devices that may be physically accessible to attackers and difficult to update after deployment.

Disclosure and Fix

We reported all four vulnerabilities to Golioth through coordinated disclosure. The team responded promptly and confirmed all fixes before the disclosure deadline. SecMate would like to thank the Golioth team and maintainers for their responsiveness and security awareness. Fixes are available in Firmware SDK v0.22.0 and Pouch commit 1b2219a1.

Disclosure Timeline

CVE Summary

What’s Next

This is our second public disclosure, after the libcoap vulnerabilities we published earlier. These four CVEs bring our public total to six, with more findings across embedded and systems projects still in coordinated disclosure.

For the full list, see our disclosure page. If you’re building on embedded systems and want to find vulnerabilities before attackers do, reach out.

References

• [1] Golioth. “Golioth Firmware SDK” GitHub. Repository

• [2] Golioth. “Golioth Pouch” GitHub. Repository

• [3] IETF. “RFC 7252 - The Constrained Application Protocol (CoAP)” IETF Datatracker, June 2014. RFC

• [4] NVD. “CVE-2026-23750 - BLE GATT Server Certificate Heap Overflow in Golioth Pouch” National Vulnerability Database. CVE

• [5] NVD. “CVE-2026-23748 - LightDB State String Underflow OOB Read in Golioth Firmware SDK” National Vulnerability Database. CVE

• [6] NVD. “CVE-2026-23747 - Assert-Guarded Memcpy Stack Overflow in Golioth Firmware SDK” National Vulnerability Database. CVE

• [7] NVD. “CVE-2026-23749 - CoAP Blockwise Unterminated Path OOB Read in Golioth Firmware SDK” National Vulnerability Database. CVE

The SecMate Team

We discovered two memory-safety issues in libcoap, a widely deployed IoT library. The first is an out-of-bounds write in a fixed buffer reachable via proxy requests that can crash servers with a single UDP packet. The second is an out-of-bounds read in OSCORE configuration parsing that can crash the parser on malformed input. Both vulnerabilities have amplified impact on the constrained embedded devices the library was built for.

About SecMate

SecMate combines static analysis with AI to find security vulnerabilities in source code, specifically in embedded devices and low-level code.

So far, we have reported more than 60 vulnerabilities across embedded and systems projects, most still under coordinated disclosure.

Today, we are sharing two of our findings in libcoap (the first two CVEs uncovered with SecMate), a widely-used CoAP implementation for IoT devices.

What is libcoap?

libcoap [1] is a C implementation of the Constrained Application Protocol (CoAP), standardized as RFC 7252 [2]. Think of CoAP as “HTTP for IoT”: a lightweight protocol for devices that can’t afford the overhead of full HTTP/TCP stacks.

The library is mature and widely deployed:

• Supports multiple TLS backends (OpenSSL, GnuTLS, Mbed TLS, wolfSSL)
• Runs on everything from Linux servers to ESP32 microcontrollers
• Used in smart home devices, industrial sensors, and critical infrastructure

Here is the catch: the devices running libcoap are often constrained. Limited memory, no MMU, no ASLR, no stack canaries. When you find a memory-safety issue in this context, the impact is amplified.

Vulnerability #1: Static Buffer Overflow in Address Resolution (CVE-2025-34468 [3])

Location: coap_resolve_address_info() in src/coap_address.c

The Bug

This vulnerability affects libcoap servers running in proxy mode. The vulnerable function resolves hostnames for CoAP proxy requests, copying the hostname into a fixed 256-byte static buffer without checking the length:

1static char addrstr[256];  // Fixed-size static buffer
2memset(addrstr, 0, sizeof(addrstr));
3if (address && address->length)
4    memcpy(addrstr, address->s, address->length);  // No bounds check!
5else
6    memcpy(addrstr, "localhost", 9);
7getaddrinfo(addrstr, NULL, &hints, &res);

The address->length field comes directly from parsing CoAP options. An attacker controls this value.

The Attack

When a CoAP server runs in proxy mode, it accepts Proxy-Uri options that specify where to forward requests. The hostname from this URI flows directly into the vulnerable memcpy():

1. A CoAP request arrives with a Proxy-Uri option containing an oversized hostname (>256 bytes)
2. The proxy extracts the hostname and passes it to coap_resolve_address_info()
3. The function calls memcpy(addrstr, address->s, address->length) without bounds checking
4. The fixed-size buffer overflows, corrupting adjacent memory
5. The server crashes or misbehaves; the exact impact depends on layout and mitigations

Impact

On a standard Linux system, this bug is likely to crash the server (Denial of Service). On embedded devices without memory protection, memory corruption can have broader consequences, but practical exploitation depends on layout and mitigations. One UDP packet, no authentication required when proxy mode is enabled.

Vulnerability #2: Out-of-Bounds Read in OSCORE Parsing (CVE-2025-59391 [4])

Location: get_split_entry() in src/coap_oscore.c

The Bug

OSCORE (Object Security for Constrained RESTful Environments) is a security layer for CoAP. libcoap parses OSCORE configuration files that include boolean fields. The parsing code uses memcmp() with a user-controlled length:

1case COAP_ENC_BOOL:
2    if (memcmp("true", begin, end - begin) == 0)
3        value->u.value_int = 1;
4    else if (memcmp("false", begin, end - begin) == 0)
5        value->u.value_int = 0;

The problem: end - begin comes from the configuration file. If an attacker provides a value like trueAAAAAAAA... (thousands of characters), the memcmp() reads past the static string "true" into adjacent memory.

Impact

This issue requires the ability to provide malicious OSCORE configuration input, which is typically a local or trusted provisioning path rather than a network-facing vector. The realistic outcome is a crash or parse failure on malformed configs.

Theoretical Oracle Attack

In theory, if a local attacker could repeatedly provide different config files and observe success/failure signals from the parser, they could use this as an oracle to infer adjacent .rodata bytes one at a time. The diagram below illustrates what such an attack would look like:

However, this attack is impractical: OSCORE configuration is loaded from local files, so an attacker would need repeated local access to provide different config files and observe results. At that point, they likely have access that makes this leak scenario moot.

Why This Bug is Easy to Miss

This vulnerability is subtle: the out-of-bounds read in memcmp() may not crash or produce obvious symptoms during normal operation. Spotting it requires reasoning about how data flows through multiple operations, something traditional static analysis tools typically miss.

The Embedded Security Challenge

Both vulnerabilities share a common theme: they are worse on the devices libcoap is designed for.

Desktop and server systems have decades of hardening:

• ASLR randomizes memory layout
• Stack canaries detect buffer overflows
• DEP/NX prevents code execution from data segments
• Sandboxing limits blast radius

Constrained embedded devices often have none of these. A microcontroller running FreeRTOS or bare metal has:

• Flat, predictable memory layout
• No memory protection unit (MPU) or it is disabled for performance
• No operating system to enforce isolation
• Direct hardware access for any code that runs

This isn’t a criticism of libcoap. It is the reality of their target environment. But it means bugs like these deserve extra scrutiny.

Key Insight

When auditing code for constrained devices, assume the worst-case exploitation scenario. Mitigations you take for granted on desktop systems simply don't exist.

Disclosure and Fix

We reported both vulnerabilities to the libcoap maintainers through coordinated disclosure. The team responded quickly and professionally, and fixes are now available in version 4.3.5a.

Disclosure Timeline

We want to thank the libcoap team, particularly Jon Shallow, for their responsiveness in addressing these issues. The maintainer responded on the same day for both reports. Maintaining open-source security infrastructure is often thankless work, and their quick turnaround made the ecosystem safer.

What’s Next

These two CVEs are just a sample of what SecMate has found. We’re continuing to analyze embedded codebases and report vulnerabilities through coordinated disclosure.

If you’re curious about our other findings, check out our disclosure page. And if you’re building embedded systems and want to find vulnerabilities before attackers do, reach out.

References

• [1] libcoap. “libcoap - C-Implementation of CoAP” GitHub. Repository

• [2] IETF. “RFC 7252 - The Constrained Application Protocol (CoAP)” IETF Datatracker, June 2014. RFC

• [3] NVD. “CVE-2025-34468 - Static Buffer Overflow in libcoap” National Vulnerability Database. CVE

• [4] NVD. “CVE-2025-59391 - Out-of-Bounds Read in libcoap” National Vulnerability Database. CVE

The SecMate Team