CVE-2025-32402 Overview
CVE-2025-32402 is an out-of-bounds write vulnerability [CWE-787] affecting RT-Labs P-Net version 1.0.1 and earlier. P-Net is an open-source PROFINET device stack used to implement industrial IO devices that communicate over Ethernet. An attacker can send a malicious Remote Procedure Call (RPC) packet to a vulnerable device and trigger a crash. The flaw is remotely reachable, requires no authentication, and impacts availability of affected industrial endpoints.
Critical Impact
A single malicious RPC packet can crash any IO device built on RT-Labs P-Net 1.0.1 or earlier, disrupting industrial control processes that depend on PROFINET communication.
Affected Products
- RT-Labs P-Net version 1.0.1
- RT-Labs P-Net versions earlier than 1.0.1
- Industrial IO devices and embedded systems linking against the p-net PROFINET stack
Discovery Timeline
- 2025-05-07 - CVE-2025-32402 published to the National Vulnerability Database (NVD)
- 2025-05-13 - Last updated in NVD database
Technical Details for CVE-2025-32402
Vulnerability Analysis
The vulnerability resides in the RPC packet parsing logic of the RT-Labs P-Net PROFINET stack. PROFINET uses DCE/RPC over UDP for connection establishment and parameter exchange between controllers and IO devices. An attacker on the same network segment as a vulnerable device can craft an RPC packet whose fields drive the stack to write past the bounds of a target buffer.
The out-of-bounds write corrupts adjacent memory in the embedded device, leading to a crash of the PROFINET stack or the host process. Because IO devices are typically deployed on flat industrial networks, the attack does not require credentials or user interaction. Successful exploitation produces a denial-of-service condition that halts the affected device and any physical process it controls.
Root Cause
The defect is classified under [CWE-787] Out-of-bounds Write. The P-Net RPC parser fails to validate length or offset fields supplied in attacker-controlled RPC packets before writing decoded data into fixed-size internal structures. When the supplied values exceed the destination buffer, the stack writes beyond allocated memory.
Attack Vector
The attack vector is network-based and unauthenticated. An attacker sends a crafted PROFINET DCE/RPC packet to UDP services exposed by the IO device. Because PROFINET devices commonly sit on routable OT networks alongside engineering workstations, any compromised host on the same broadcast domain can deliver the payload. See the Nozomi Networks Vulnerability Advisory for additional technical context.
No verified proof-of-concept code is publicly available.
Refer to the Nozomi Networks advisory for protocol-level details.
Detection Methods for CVE-2025-32402
Indicators of Compromise
- Unexpected restarts, watchdog resets, or stack traces on PROFINET IO devices running p-net
- Malformed DCE/RPC packets targeting UDP ports used by PROFINET on the OT segment
- Repeated PROFINET connection establishment failures preceding device crashes
Detection Strategies
- Deploy OT-aware network monitoring that parses PROFINET DCE/RPC traffic and alerts on oversized or malformed length fields
- Correlate device offline events from SCADA/HMI systems with packet captures of inbound RPC traffic
- Baseline normal PROFINET RPC sources and flag packets originating from unexpected hosts
Monitoring Recommendations
- Log all PROFINET RPC sessions at OT network boundaries and forward to a centralized SIEM for retention
- Monitor IO device health counters and availability metrics for crash-restart patterns
- Alert on new MAC or IP addresses initiating PROFINET communications inside the cell network
How to Mitigate CVE-2025-32402
Immediate Actions Required
- Inventory all IO devices and firmware images that embed RT-Labs p-net version 1.0.1 or earlier
- Restrict PROFINET traffic to trusted controllers using VLAN segmentation and OT firewall rules
- Isolate vulnerable IO devices from engineering, IT, and remote-access networks until patched
Patch Information
Upgrade RT-Labs P-Net to a version later than 1.0.1 that contains the bounds-checking fix. Device vendors that statically link p-net must rebuild and reissue firmware. Consult the Nozomi Networks Vulnerability Advisory and RT-Labs project releases for the fixed version reference.
Workarounds
- Apply strict ingress filtering so only authorized PROFINET controllers can reach IO device RPC ports
- Enable PROFINET Security Class features where supported by the device and controller
- Use unidirectional gateways or data diodes between OT cells and higher-level networks to block crafted RPC packets
# Example: restrict PROFINET DCE/RPC to a known controller using iptables on a Linux-based gateway
iptables -A FORWARD -p udp --dport 34964 -s 10.10.20.5 -d 10.10.20.0/24 -j ACCEPT
iptables -A FORWARD -p udp --dport 34964 -d 10.10.20.0/24 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


