Researchers from Nozomi Networks Labs identified four memory-corruption vulnerabilities in the PROFINET Discovery and basic Configuration Protocol (DCP) implementation running on the Siemens SCALANCE LPE9403 industrial PC, using an emulation-driven fuzzing technique combining process snapshots, the Unicorn CPU emulator and AFL++. These security vulnerabilities affect SCALANCE LPE9403 firmware up to version V4.0 HF0 and are tracked as CVE-2025-40575 through CVE-2025-40578, with each assigned a CVSS 4.0 score of 5.3. The flaws comprise an uninitialized-value vulnerability, a NULL pointer dereference and two out-of-bounds read vulnerabilities.
Nozomi noted that the LPE9403 is a rugged, Debian-based Linux industrial PC designed for deployment close to physical processes, where it can collect and preprocess data from PLCs (programmable logic controllers) and field devices and act as a gateway between OT networks and SCADA (supervisory control and data acquisition), manufacturing execution systems or cloud services. The vulnerabilities reside in the LPE9403’s DCP daemon, which runs as a root process, is unauthenticated and is bound to all three device interfaces, Nozomi said. An attacker on the same Layer 2 network segment could send specially crafted Ethernet packets to crash the daemon.
As PROFINET DCP operates at Layer 2 and supports device discovery and basic network configuration, exploitation could make devices appear unreachable to SCADA systems or, during initial deployment, prevent a device from obtaining an IP address. Nozomi’s researchers used snapshot fuzzing to capture the process’s userspace memory and CPU registers before network-packet parsing, load that state into Unicorn and repeatedly mutate inputs through AFL++; the campaign ultimately uncovered four distinct memory-corruption issues. Siemens has fixed the vulnerabilities in the latest SCALANCE LPE9403 firmware, with Nozomi recommending firmware updates and network segmentation for affected deployments.
“The device targeted in this research is the Siemens SCALANCE LPE9403, an industrial ‘Local Processing Engine’ (LPE). It is a rugged industrial PC running a Debian-based Linux operating system, designed to be deployed close to the physical process, for example, in machine cabinets, on production lines, or in field control panels,” the researchers wrote in a recent Nozomi blog post. “In typical deployments, the LPE acts as an edge device: it collects and pre-processes data from PLCs and field devices, runs monitoring or security applications, and serves as a gateway between the OT network and higher-level systems such as SCADA, MES, or cloud-based services.”
They mentioned that in a representative factory automation scenario, a device like the SCALANCE LPE9403 may aggregate PROFINET traffic from multiple controllers and IO devices, perform local analysis or anomaly detection, and forward selected information to central monitoring systems. Its position in the network and its role as a data and control hub make the security of its exposed services particularly relevant.
The four memory corruption vulnerabilities identified in the DCP service allow a remote, unauthenticated attacker on an adjacent network (the same Layer 2 segment) to crash the daemon by sending specially crafted Ethernet packets.
“Because the DCP service is used for device discovery and retrieving device information, an attacker could, in some deployment scenarios, effectively blind SCADA systems by making the device appear unreachable,” according to the researchers. “Furthermore, if DCP is used during initial network deployment, an attacker could crash the service and prevent the device from obtaining an IP address.”
On the Siemens SCALANCE LPE9403, DCP can configure network settings such as the IP address without requiring a DHCP server. During commissioning, the DCP server can operate in write mode, but write access is disabled after the Admin password is changed. The server remains active for device discovery and reading network configuration. The SCALANCE LPE runs AArch64 Linux, with the DCP service operating as a native user-space daemon, dcpd[dot]bin, bound to all three device interfaces, P1, P2 and P3C, and listening for Layer 2 DCP traffic. Nozomi Networks Labs considered the service an attractive fuzzing target because it is reachable through every device interface, runs as root and does not require authentication.
Nozomi said it considered several approaches to fuzzing the service, including isolating parsing routines with LD_PRELOAD and using QEMU for instrumentation. Because the service is relatively small, the researchers chose snapshot fuzzing. The approach involved reverse engineering the executable to identify key functions, taking a snapshot of the process’s user-space memory and registers before it receives network input, loading that state into the Unicorn CPU emulator, and creating a harness to inject input into memory and execute the code. The researchers then used unicornafl to instrument the program and AFL++ to perform the fuzzing. They chose the standard Unicorn engine over alternatives such as Qiling to keep the setup simple and avoid introducing additional complexity or noise.
Snapshot fuzzing drives a program or operating system to a specific execution point, captures its CPU, register and memory state, and repeatedly restores that snapshot while mutating inputs. Its main advantage is that researchers can bypass time-consuming or nondeterministic steps required to reach the target code, allowing fuzzing to begin from a deterministic and repeatable state.
The approach also creates challenges around selecting the right snapshot point and handling interactions outside the captured state. Since the snapshot cannot account for events that occurred before it, the chosen execution point is critical. If only user-space state is captured, system calls and other external interactions must be intercepted and modeled to provide realistic responses. These interactions can include file access, keyboard input, hardware sensors or network interfaces. Ideally, the snapshot is taken where the target code has minimal dependence on external systems and performs as much processing as possible in memory.
“A typical pitfall when using this technique to fuzz user-space Linux programs is handling Thread Local Storage (TLS). Many libc features rely on TLS (for example, the stack canary). If we don’t model TLS correctly, the snapshot may fail to execute properly as soon as it calls a libc function,” the researchers identified. “Because the TLS is architecture-dependent, the way we handle it depends heavily on the platform the snapshot runs on. Fortunately, on Linux AArch64 the TLS pointer is stored in the register tpidr_el0, which is easily accessible from user space and can be retrieved by our GDB plugin. In this case, setting up TLS is simply a matter of restoring tpidr_el0 to the value observed in GDB.”
They added that the TLS setup can require more work on other architectures. For example, on x64 the TLS pointer is held at fs:0, organizations must configure the FS segment register correctly in Unicorn for the snapshot to behave as expected.
The team couldn’t stub the entire Linux kernel, so they took an iterative approach: they registered Unicorn hooks on every instruction to build a shadow call stack, then another hook to catch system calls. When the snapshot triggered an unimplemented syscall, they’d analyze the stack trace and add a stub. This process continued even during fuzzing; whenever the fuzzer discovered a new syscall, the crash would reveal what needed implementing next. The overhead was significant because the target executable opened and parsed configuration files while processing packets, requiring stubs for socket, mkdirat, write, sendto, plus libc functions like fopen, fclose, getline, calloc, and free, plus internal functions like LED control.
The researchers detailed that the device’s kernel-level BPF filter would drop malformed packets before they reached userspace, a detail that could waste fuzzing cycles on unreachable code paths. The team extracted the filter from the device and reverse-engineered its logic: it validates Ethernet type 0x8892 (PROFINET) at offset 12 or 16, then checks bytes 18–19 or 14–15 against specific values (0xFEFE, 0xFEFD, 0xFEFF, 0xFEFC). Rather than emulate BPF inside their harness, they reimplemented the filter in Python and used it to validate every generated input before feeding it to the emulator.
The fuzzing harness loads the snapshot, registers all hooks, and provides two critical callbacks to AFL++: a place_input_callback that validates input size and BPF compliance, and a harness function that actually runs the emulation from the saved PC. This keeps the fuzzer efficient by rejecting bad inputs before emulation starts. With corpus data extracted from legitimate pcap captures, the team launched AFL++ and began finding crashes. The performance wasn’t exceptional, but it was sufficient—proof that careful snapshot selection and incremental stub implementation could make fuzzing an otherwise complex embedded binary tractable.
Siemens has addressed these vulnerabilities through security patches for the SCALANCE LPE9403 firmware and published a security report. Asset owners and operators are strongly urged to update affected Siemens SCALANCE LPE9403 devices with the newer version of the firmware, implement network segmentation to limit exposure of systems, and monitor network traffic for the presence of vulnerable assets.
“To help organizations promptly identify whether the devices with the vulnerable firmware are present in their environment, asset owners can rely on the advanced capabilities of Nozomi Networks OT/IoT Security Platform,” the post mentioned. “The platform provides deep visibility into network traffic and host activities, enabling effective vulnerability and threat detection across OT networks. This proactive monitoring empowers security teams to respond to vulnerabilities and attacks swiftly and effectively, minimizing the impact of attacks targeting critical networks.”
