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’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