Phoenix Contact PLCnext CVE-2025-41670

Exploitation requires an authenticated low-privileged local user (CVSS PR:L) who can write to the specific user-writable filesystem locations from which the privileged PLCnext system service loads configuration and application-related files; the attacker must be able to create or modify those files and then have (or wait for) the privileged service process them. Limiting factors: an existing low-privileged foothold/account on the controller is mandatory, no user interaction from a victim is needed (UI:N), and the affected firmware must be earlier than 2026.0.3. Note the data conflict - the CVSS vector lists AV:N (network) but the description describes purely local filesystem manipulation, so a remote unauthenticated path is not supported by the description and the network classification should be confirmed with the vendor.

Signals here are mixed and should be weighed carefully. CVSS 4.0 rates this 8.7 (High) with full High impact to confidentiality, integrity and availability of the vulnerable component (VC:H/VI:H/VA:H) and PR:L (a valid low-privileged account is required, UI:N). However, the published CVSS vector lists AV:N (network) while the description explicitly states a LOCAL user manipulating local filesystem files - this is a material conflict; the described mechanic is local privilege escalation, so the AV:N classification should be verified against the vendor advisory (VDE-2026-050). EPSS is only 0.03% (9th percentile), there is no KEV listing and no public exploit identified at time of analysis, which argues against imminent mass exploitation. Net: this is a meaningful hardening priority for OT/ICS operators because the affected assets are PLCs and the impact is full compromise of a privileged service, but it is not a drop-everything internet-facing emergency - it requires an existing local foothold, so realistic risk is gated by who already has low-privileged access to these controllers.

An attacker who already holds a low-privileged account on a PLCnext controller writes a malicious configuration or application file into a user-writable directory that the elevated system service trusts. When that privileged service next reads and processes the planted file, it acts on attacker-controlled content and the attacker gains the service's elevated privileges on the device. No public exploit code is available at time of analysis, and exploitation requires existing local access rather than remote unauthenticated reach.