Apache PLC4X CVE-2026-102508

Requires the application to use the OPC UA driver of Apache PLC4X (PLC4J) at versions 0.9.0 through 0.13.1, and the attacker must hold a man-in-the-middle network position between the OPC UA client and server (the AT:P attack requirement). Exploitation is aided by insecure defaults rather than misconfiguration: the default security policy is None across all affected versions; from 0.12.0 the driver silently downgrades to a weaker-than-configured security policy; and from 0.13.0 endpoint selection prefers the weakest matching endpoint. Critically, even operators who explicitly enabled signing/encryption remain exposed because 0.9.0-0.11.0 only log failed signature checks while 0.12.0-0.13.1 invert the check (rejecting valid, accepting invalid) and accept server certificates with no trust anchor. The limiting factors are the required on-path position and that the fully-fixed behavior only exists in 1.0.0.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) scores 9.2 (Critical), reflecting an unauthenticated network attacker who can fully compromise confidentiality, integrity and availability of the OPC UA secure channel. The single meaningful brake is AT:P - the attacker must already hold a man-in-the-middle position between the PLC4X client and the OPC UA server, which is a real precondition rather than a trivial one. No EPSS score, no CISA KEV listing, and no public exploit code were supplied, so exploitation status is: no public exploit identified at time of analysis. This is a genuine priority for OT/ICS environments despite the missing exploitation telemetry, because the flaw defeats exactly the cryptographic protections operators believe they have enabled and directly harvests user credentials; the version-dependent behavior (inverted signature check in 0.12.0-0.13.1) is particularly insidious because it silently converts a security control into an anti-control. The residual limiter is the on-path requirement - on a flat, unauthenticated OT segment (common for PLC traffic) that requirement is weak, but across routed/segmented networks it is a substantial barrier. Reported by Apache directly, so the affected-version range and fix are authoritative.

An attacker who has gained a foothold on the OT/industrial LAN carrying PLC4X-to-OPC-UA traffic (e.g., via ARP spoofing or a compromised switch) positions themselves between the PLC4J client and the OPC UA server. They intercept the unauthenticated GetEndpoints discovery response and substitute their own certificate, so the client encrypts the operator password to the attacker; forged or invalid message signatures are either only logged (0.9.0-0.11.0) or actively accepted (0.12.0-0.13.1), letting the attacker impersonate the server and read, forge, or modify secure-channel traffic. No public proof-of-concept is identified, but the attack requires only a standard on-path toolkit.