Skip to content
Fencer Intel
high 8.5

CVE-2026-102511 json

Apache PLC4X, Apache PLC4X, Apache PLC4X, Apache PLC4X: ADS discovery accepts spoofed responses and derives the connection target from them

published last mo. modified last mo. also EUVD-2026-89680

cvss
8.5
version 4.0, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 7%
public exploits
0
none known

Summary

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.

Patch / fix

  • Apache Software Foundation Apache PLC4X 1.0.0

Is CVE-2026-102511 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
total
Assessed
last mo.

Exploit prediction

0.18% chance of exploitation in the next 30 days, higher than 7% of all scored CVEs (FIRST EPSS, 2026-11-09).

CVSS scores

assigned by version score vector
CNA 4.0 8.5 CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
CNA 4.0 8.5 CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Affected products

  • Apache Software Foundation Apache PLC4X

Classification

Weakness
  • CWE-940 Improper Verification of Source of a Communication Channel
  • CWE-129 Improper Validation of Array Index
  • CWE-248 Uncaught Exception
  • CWE-835 Loop with Unreachable Exit Condition

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.