Spoofed ADS discovery responses redirect PLC connections in Apache PLC4X (PLC4Go/PLC4J)
AI analysis
Apache PLC4X's ADS device discovery trusts the AmsNetId claimed inside a UDP discovery response instead of the datagram's actual source IP, so an attacker on the network who can send a single spoofed response can make the discovering application connect its next ADS session — including any configured route credentials — to an attacker-chosen host, even one outside the local network. The same discovery listeners are trivially deniable: a malformed datagram panics the PLC4Go ADS listener, crashes the PLC4J ADS and EtherNet/IP discoverers, or makes the PLC4J Modbus discoverer spin and consume a CPU core on a partial response. Exploitation requires the application to call the opt-in discovery API and, for the credential-redirect path, to act on the discovered entries, with an attacker able to reach the discovering host via UDP (CVSS 4.0: 8.5, adjacent network, user interaction required). Affected consumers are applications built on PLC4Go 0.11.0–0.9.x-era releases and PLC4J drivers before 1.0.0; upgrading to Apache PLC4X 1.0.0 fixes all variants by deriving the connection address from the datagram source and logging a warning on mismatch. No public proof of concept is known and the issue is not in the CISA KEV catalog.
What to do: Upgrade to Apache PLC4X 1.0.0, which derives the discovery connection address from the datagram's source IP and hardens the PLC4Go/PLC4J listeners against malformed responses. Until then, only invoke discovery on trusted, segmented OT networks, firewall the discovery UDP ports so untrusted hosts cannot send datagrams to the discovering machine, and treat discovered AmsNetId entries with suspicion. After upgrading, monitor for the new AmsNetId-vs-source-address mismatch warnings as an indicator of spoofing attempts, and rotate any ADS route credentials if discovery has run on an untrusted segment.
Affected
| Apache PLC4X PLC4Go (Go module github.com/apache/plc4x/plc4go, ADS discovery) | >= 0.11.0, < 1.0.0 |
| Apache PLC4X PLC4J ADS driver | >= 0.10.0, < 1.0.0 |
| Apache PLC4X PLC4J Modbus driver | >= 0.10.0, < 1.0.0 |
| Apache PLC4X PLC4J EtherNet/IP driver | >= 0.11.0, < 1.0.0 |
Description
Improper Verification of Source of a Communication Channel in the ADS discovery of the Go implementation of Apache PLC4X (PLC4Go) allows an attacker able to send UDP datagrams to the discovering host to redirect subsequent connections to an arbitrary, attacker-chosen address. The discovery result's connection address was derived from the AmsNetId claimed in the response body rather than from the datagram's actual source address. One spoofed discovery response can therefore insert an inventory entry pointing at any host, including hosts outside the local network, and an application that connects to discovered devices will open its ADS session, including any configured route credentials, to that host. Additionally, discovery listeners in both implementations can be disabled by a single malformed datagram: - In PLC4Go ADS discovery, a short version block causes a panic that ends the listener for the rest of the discovery call, so legitimate devices answering afterwards are not reported. - In PLC4J, the ADS and EtherNet/IP discoverers stop on an unhandled exception from a malformed response. - The PLC4J Modbus discoverer can be made to spin indefinitely, consuming a CPU core, by a scanned host that sends a partial response. Exploitation requires the application to invoke the discovery API, which is opt-in, and for the connection redirect, to act on the discovered items. This issue affects Apache PLC4X: PLC4Go from 0.11.0 before 1.0.0; PLC4J ADS and Modbus drivers from 0.10.0 before 1.0.0; PLC4J EtherNet/IP driver from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases. Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 derives the connection address from the datagram's source address and logs a warning when the claimed AmsNetId disagrees with it.