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