{"cve":"CVE-2026-102511","nvd":{"published":"2026-09-30T09:17:14.467","modified":"2026-09-30T17:16:40.860","status":"Awaiting Analysis","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 \naddress 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\nwill open its ADS session, including any configured route credentials, to that host.\n\nAdditionally, discovery listeners in both implementations can be disabled by a single malformed datagram:\n- 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.\n- In PLC4J, the ADS and EtherNet/IP discoverers stop on an unhandled exception from a malformed response.\n- The PLC4J Modbus discoverer can be made to spin indefinitely, consuming a CPU core, by a scanned host that sends a partial response.\n\nExploitation requires the application to invoke the discovery API, which is opt-in, and for the connection redirect, to act on the discovered items.\n\nThis 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.\n\nUsers 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.","cvss_v4":{"vector":"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","score":8.5},"cvss_v3":null,"cwes":["CWE-129","CWE-248","CWE-835","CWE-940"],"references":["https://lists.apache.org/thread.html/g692j4fklrbo80stjr5ll8xghrwszthf","http://www.openwall.com/lists/oss-security/2026/09/30/7"],"products":[],"source":"nvd","synced_at":"2026-10-19T22:56:48.555445741+00:00"},"epss":{"cve":"CVE-2026-102511","score":0.00182,"percentile":0.07698,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}