CVE-2025-32401 is a medium severity (CVSS 4.8) heap based buffer overflow in RT-Labs P-Net version 1.0.1 and earlier. A malicious RPC packet can corrupt memory on devices that use the library. Update to P-Net 1.0.2, as the Nozomi Networks advisory says.
What's affected
The NVD record and the Nozomi Networks Labs advisory both say RT-Labs P-Net version 1.0.1 or earlier is affected. The advisory says versions before 1.0.2 are affected and gives the solution as updating to version 1.0.2. The advisory is dated 5 May 2025.
P-Net is a Profinet device stack, a library that embedded makers build into industrial IO devices. So the vulnerable code does not run as a stand alone product. It lives inside firmware that uses the library. The weakness classes are CWE-122 (heap based buffer overflow) and CWE-787 (out of bounds write).
The CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L. It is reachable over the network without login, attack complexity is high, and the impact is low integrity and low availability. This entry is one of three P-Net memory safety issues published together, along with CVE-2025-32403 and CVE-2025-32404. The single upgrade to 1.0.2 covers all three according to the advisories.
The KEV flag is false, and neither source reports attacks in the wild.
How to check if you're exposed
If you build devices, search your source tree and build manifests for the library.
grep -rn "pnet\|p-net\|rt-labs" CMakeLists.txt west.yml *.cmake 2>/dev/null
git -C path/to/p-net describe 2>/dev/null
Any P-Net revision below 1.0.2 is in scope. If you operate devices and do not build them, you cannot see inside the firmware, so ask the device vendor whether their product embeds P-Net, and which version. Also list which of those devices accept Profinet RPC traffic from networks beyond the control cell.
The free in-browser dependency scan takes a manifest or lockfile and lists known CVEs for the packages in it, and the Gold directory lets you look up a CVE by id.
What to do now
- Update P-Net to 1.0.2 or later in your firmware, rebuild, and run your normal test suite.
- Ship the firmware update to devices, and track which units are still on the old build.
- If you operate affected devices, ask the vendor for an update and a date.
- Keep Profinet and industrial control traffic on isolated segments, and allow RPC traffic only from known engineering stations and controllers.
- Watch for device restarts or odd behaviour on the control network, since memory corruption can show up as crashes.
Why it matters
A heap overflow writes past the end of a block of memory that the program allocated at run time. The result can be corrupted data, a crash, or in the worst case changed program flow. The advisory describes the effect as memory corruption in devices that use the library, triggered by a malicious RPC packet.
Industrial devices are updated rarely. A library fix only helps once it has travelled from the library to the device maker, to the firmware, and then onto every unit on the plant floor. That chain is the real exposure window, and a bill of materials for firmware is what makes it possible to follow.
Quick check
Which version fixes this?
P-Net 1.0.2, according to the Nozomi Networks advisory.
Can I scan a device to find out?
Not reliably from outside. Ask the vendor, or check the firmware's software bill of materials.
Sources
Last reviewed: 19 October 2026.
