CVE-2026-102511
Received Received - Intake

Improper Verification of Source in Apache PLC4X Discovery

Publication date: 2026-09-30

Last updated on: 2026-09-30

Assigner: Apache Software Foundation

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-09-30
Last Modified
2026-09-30
Generated
2026-09-30
AI Q&A
2026-09-30
EPSS Evaluated
N/A
NVD
CVE-2026-102511
EUVD
EUVD-2026-89680

Affected Vendors & Products

Showing 2 associated CPEs
Vendor Product Version / Range
apache plc4x From 0.11.0 (inc) to 1.0.0 (exc)
apache plc4x From 0.10.0 (inc) to 1.0.0 (exc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-835 The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
CWE-940 The product establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.
CWE-129 The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
CWE-248 An exception is thrown from a function, but it is not caught.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability involves improper verification of the source of a communication channel in Apache PLC4X's ADS discovery (Go implementation). An attacker sending UDP datagrams can manipulate the discovery process to redirect connections to an arbitrary address by spoofing the source address in the response. The system uses the claimed AmsNetId in the response rather than the actual datagram source, allowing inventory entries to point to any host, even outside the local network. Additionally, malformed datagrams can disable discovery listeners in both PLC4Go and PLC4J, preventing legitimate devices from being reported or causing resource exhaustion.

Detection Guidance

This vulnerability involves improper verification of UDP datagram sources in Apache PLC4X discovery. Detection requires monitoring for unexpected ADS discovery responses or malformed datagrams targeting PLC4X services. Check logs for discovery listener crashes or CPU spikes during scans. Use network monitoring tools like Wireshark to inspect UDP traffic on ports used by PLC4X (typically 48896 for ADS). Look for spoofed AmsNetId responses or malformed packets causing crashes.

Impact Analysis

If you use Apache PLC4X with affected versions (PLC4Go <1.0.0, PLC4J ADS/Modbus/EtherNet/IP <1.0.0), an attacker could intercept or redirect connections to discovered devices. This may lead to unauthorized access to sensitive data or systems, as the application might connect to attacker-controlled hosts using configured route credentials. Malformed datagrams could also disrupt discovery, causing missed devices or system resource exhaustion.

Compliance Impact

This vulnerability could lead to unauthorized access to sensitive data, violating confidentiality requirements in GDPR and HIPAA. If exploited, it may result in data breaches, exposing personal or health information. Compliance with these regulations requires ensuring data integrity and confidentiality, which this vulnerability undermines by allowing attackers to redirect connections to malicious hosts.

Mitigation Strategies

Upgrade all affected Apache PLC4X components to version 1.0.0 or later. Disable discovery APIs if not required. Implement network segmentation to restrict UDP traffic to trusted PLC devices. Monitor for unusual discovery traffic or crashes in PLC4X services. Apply input validation for discovery responses to reject malformed packets.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-102511. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart