AI analysis
Apache PLC4X's Java implementation (PLC4J) from 0.10.0 through 0.13.1 contains five related resource-exhaustion defects — allocating length-prefixed byte strings from claimed wire lengths before validation, pre-allocating parser lists and collections from attacker-supplied element counts, accumulating OPC UA message chunks without enforcing negotiated limits, and parsing recursive types without a nesting-depth cap. A malicious or impersonated PLC device or OPC UA server can trigger multi-gigabyte allocations or stack exhaustion by sending a single forged length/count field or oversized chunked message, crashing the connecting client application — the impact is denial of service only (CVSS 4.0 8.7, availability-only). Critically, in the OPC UA driver the offending data is parsed while the secure channel and session are still being established, before the server's identity is bound, so configuring a trusted server does not stop an attacker who can impersonate one. Any Java application embedding PLC4X 0.10.0–0.13.1 is affected: the generated-parser defect is shared by all PLC4J drivers, with the OPC UA driver the verified pre-authentication path (chunk-accumulation defect 0.12.0–0.13.1). No public PoC or known exploitation exists and the CVE is not in CISA's KEV catalog; the fix shipped in version 1.0.0, with the analogous Go implementation flaw tracked separately as CVE-2026-102510.
What to do: Upgrade every use of PLC4X/PLC4J to 1.0.0, auditing dependency trees in gateways and custom applications for plc4j artifacts in the 0.10.0–0.13.1 range, and patch the Go implementation separately per CVE-2026-102510. Do not rely on trusted-server or certificate configuration as a mitigation — the malformed data is parsed before the server's identity is bound — so instead use network segmentation and endpoint ACLs to keep clients from being redirected to or intercepted by attacker-controlled endpoints until patched. Watch connecting client JVMs for OutOfMemoryError or StackOverflowError as a possible indicator of exploitation attempts.
Affected
| Apache PLC4X (PLC4J, Java implementation) | 0.10.0 through 0.13.1 (all versions from 0.10.0 before 1.0.0) |
| Apache PLC4X OPC UA driver (chunk-accumulation defect only) | 0.12.0 through 0.13.1 |
Estimated exposure
unknown — embedded library, no public deployment counts — PLC4J ships as a Java dependency inside third-party industrial clients and gateways rather than as a scannable network service, and no install, download, or market-share figures are available to size the affected population.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
Memory Allocation with Excessive Size Value, Allocation of Resources Without Limits, and Uncontrolled Recursion in the Java implementation of Apache PLC4X (PLC4J) allow a malicious or impersonated device to exhaust the memory or stack of the client application, causing a denial of service. In the OPC UA driver these defects are reachable before authentication: the offending data is parsed while the secure channel and session are being established, before the server's identity has been bound to it. Configuring a trusted server therefore does not prevent exploitation by an attacker who can impersonate it. The individual defects are: - Length-prefixed byte strings are allocated at the size claimed on the wire before the length is checked against the data actually received (0.10.0 through 0.13.1). - Array fields in generated protocol parsers pre-allocate a list with the element count claimed on the wire, allowing a single count field to trigger a multi-gigabyte allocation. This parser is shared by all PLC4J drivers; the OPC UA driver is the verified pre-authentication path (0.10.0 through 0.13.1). - The OPC UA driver accumulates message chunks without enforcing the negotiated maximum chunk count and message size (0.12.0 through 0.13.1). - The OPC UA driver pre-allocates collections using element counts received from the server (0.10.0 through 0.13.1). - Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Go implementation is covered by CVE-2026-102510 https://cveprocess.apache.org/cve5/CVE-2026-102510 . This issue affects Apache PLC4X: from 0.10.0 before 1.0.0. Users are recommended to upgrade to version 1.0.0, which fixes the issue.