Six Vulnerabilities in Siemens SICAM SIAPP SDK

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

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

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.

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

Jan 3, 2026
SecMate reports six vulnerabilities to Siemens ProductCERT, including two affecting example code only [17]
Jan 5, 2026
Siemens ProductCERT confirms the case was opened as #33016 on the first business day after the January 3 report [17]
Jan 16, 2026
Siemens fixes all six issues in SIAPP SDK 2.1.7 [10]
Mar 10, 2026
Siemens publishes advisory SSA-903736 covering CVE-2026-25569, CVE-2026-25570, CVE-2026-25571, CVE-2026-25572, CVE-2026-25573, and CVE-2026-25605 [1]

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