# CVE-2026-102511: Server-side request forgery in Apache PLC4X > Attackers can spoof discovery responses to redirect connections to arbitrary hosts or cause denial of service in Apache PLC4X applications using opt-in discovery APIs. - **Severity:** High 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`) - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Local or same network only - **Victim action needed:** A user has to click or open something - **Fix available:** No - **Published:** 30 Sep 2026 - **Updated:** 30 Sep 2026 - **Also known as:** GHSA-jfxw-f7pw-76rc ## What is CVE-2026-102511? CVE-2026-102511 is a high-severity server-side request forgery vulnerability in Apache PLC4X, published on 30 Sep 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link. ### Official 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. Weakness: CWE-940 (Improper Verification of Source of a Communication Channel), CWE-835 (Loop with Unreachable Exit Condition), CWE-248 (Uncaught Exception), CWE-129 (Improper Validation of Array Index) ## Which versions are affected by CVE-2026-102511? ## How do I fix CVE-2026-102511? No fix has been published for CVE-2026-102511 yet. Limit exposure of the affected software until one is available. ## Is CVE-2026-102511 being exploited? There is no known exploitation of CVE-2026-102511 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2026-102511 and fix it if it is affected. What it is: CVE-2026-102511 is a high-severity server-side request forgery vulnerability in Apache PLC4X, published on 30 Sep 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link. Exploitation: There is no known exploitation of CVE-2026-102511 in the wild and no public exploit code. Affected product: Apache PLC4X. No package-level version data is available, so check the vendor advisory linked from the reference page. Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2026-102511/ (Markdown: https://insights.sbomify.com/CVE-2026-102511/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2026-102511 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-102511 - OSV: https://osv.dev/vulnerability/CVE-2026-102511 --- From sbomify Insights: https://insights.sbomify.com/CVE-2026-102511/ Summaries are generated and may contain mistakes; the official description above is the record.