CVE-2025-32404 is a medium severity (CVSS 4.8) out of bounds write 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-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 record repeats the text of CVE-2025-32403. The advisory lists the same impact, vector and solution. Treat them as two entries to close, both resolved by P-Net 1.0.2, and also check CVE-2025-32401.
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
Memory safety bugs in protocol stacks tend to cluster. When a parser trusts a length or an index from a packet in one place, the same habit often shows up in neighbouring code. This is the second out of bounds write reported against the same library, and the advisory describes the same result: memory corruption on a device that receives 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.
