Apache PLC4Go CVE-2026-102510

No authentication required (PR:N), but exploitation requires the attacker to be a malicious/compromised PLC device that the PLC4Go client connects to, or to be able to inject/spoof frames on the industrial network path (on-path or same-segment). The vulnerable component is the PLC4Go CLIENT parsing attacker-controlled ADS, KNXnet/IP, or EIP protocol responses - so exposure is limited to deployments where a Go application using github.com/apache/plc4x/plc4go (versions 0.11.0 up to but not including 1.0.0) communicates with untrusted or attacker-reachable industrial endpoints. The secondary 16-bit serializer-wrap defect additionally requires the application to forward attacker-influenced payloads larger than 8KB. Limiting factors: this is not a listening/server-side service exposed to the open internet, impact is denial of service only, and it is confined to the Go implementation.

This is a genuine but availability-only concern. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) confirms remote, unauthenticated, low-complexity attacks with no confidentiality or integrity impact - every listed defect (integer overflow, unbounded array/buffer pre-allocation, unchecked indexing panics, zero-length framing, unbounded recursion) results in a crash or memory exhaustion, i.e. denial of service. The 8.7 score is driven entirely by VA:H combined with the easy network vector; there is no code-execution or data-disclosure component. No EPSS score, KEV listing, SSVC decision, or POC is provided in the input, so exploitation status is: no public exploit identified at time of analysis. A notable nuance is the trust model: the primary threat is a malicious or spoofed PLC/device (or an on-path attacker injecting traffic) crashing the PLC4Go CLIENT, not a server-side exposed service - this limits the exposed attack surface to environments where the Go client talks to untrusted or compromised industrial endpoints. The secondary 16-bit serializer wrap defect could allow attacker-influenced >8KB payloads to be re-interpreted as additional protocol messages by a downstream device (e.g. an ADS PLC), a subtle integrity risk on the device side, but the vendor scored the overall issue as availability-only. Net: real and worth patching for anyone running PLC4Go against untrusted OT networks, but not a widespread internet-facing emergency.

A malicious or compromised PLC (or an attacker able to inject/spoof frames on the industrial network) sends a crafted ADS, KNXnet/IP, or EIP response to a PLC4Go client application. The response claims an enormous element/buffer count, contains a truncated field that is indexed out of bounds, wraps a length field to zero, or nests recursive protocol types without limit - causing the client to over-allocate memory, panic, or exhaust resources and crash. No POC is provided in the input and no authentication is required (PR:N).