CVE-2026-102509 in PLC4X
Summary
by MITRE • 09/30/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability in question represents a critical failure in resource management within the Java implementation of Apache PLC4X, specifically affecting versions from 0.10.0 up to but not including 1.0.0. This flaw encompasses multiple related defects categorized under Memory Allocation with Excessive Size Value and Uncontrolled Recursion, which collectively allow an attacker to cause a denial of service by exhausting the memory or stack space of the client application. The core issue stems from the library's approach to parsing incoming data streams without sufficient validation against actual resource constraints before allocation occurs. In industrial control systems where PLC4X is often deployed, such vulnerabilities are particularly dangerous because they can disrupt critical operations and lead to significant downtime if exploited effectively by a malicious actor or an impersonated device on the network.
A primary technical flaw involves length-prefixed byte strings being allocated based solely on the size value claimed in the wire data prior to verifying that this claim matches the actual amount of data received. This practice, present from version 0.10.0 through 0.13.1, means that a malicious client can send a header indicating an extremely large payload size while providing little or no actual data. The server-side parser will then attempt to allocate memory for this massive buffer immediately, leading to rapid exhaustion of available heap space and potentially causing the application to crash via OutOfMemoryError exceptions. This behavior aligns with CWE-789: Memory Allocation with Excessive Size Value, where insufficient validation of input parameters leads to excessive resource consumption.
Furthermore, array fields within generated protocol parsers pre-allocate lists based on element counts specified in the incoming data rather than limiting them to a reasonable maximum or validating against expected bounds. This defect allows a single field containing an inflated count value to trigger allocations of multi-gigabyte sizes. Since this parser logic is shared across all PLC4J drivers, any driver processing such malformed input becomes susceptible to resource exhaustion attacks. The OPC UA driver has been verified as a pre-authentication attack vector for these issues, meaning that exploitation can occur before the client establishes trust with the server or authenticates its identity. This characteristic maps closely to CWE-770: Allocation of Resources Without Limits or Throttling, highlighting the absence of safeguards against unbounded resource consumption during data processing phases.
The severity of this vulnerability is compounded by the fact that these defects are reachable before authentication in the OPC UA driver. During the establishment of a secure channel and session, the offending data is parsed while the server's identity has not yet been bound to the connection. Consequently, configuring a trusted server certificate does not prevent exploitation because an attacker can impersonate the target device during this early handshake phase. This undermines traditional security assumptions that trust established through certificates protects against subsequent malicious inputs. The inability to distinguish between legitimate and illegitimate traffic at this stage allows attackers to launch denial-of-service attacks without needing valid credentials, significantly lowering the barrier for entry.
Additional contributing factors include the accumulation of message chunks in the OPC UA driver without enforcing negotiated limits on chunk count or total message size, observed from version 0.12.0 through 0.13.1. This lack of enforcement allows attackers to flood the system with numerous small messages that collectively overwhelm available resources. Similarly, pre-allocation of collections using element counts received directly from servers exposes the application to further memory exhaustion risks if those counts are artificially inflated. These issues reflect a broader pattern of trusting unvalidated input data for critical resource allocation decisions, which is a common pitfall in network protocol implementations and relates to CWE-20: Improper Input Validation.
Another significant aspect of this vulnerability cluster involves recursive protocol types being parsed without any limit on nesting depth. This lack of recursion control can lead to stack overflow errors as the parser attempts to process deeply nested structures sent by an attacker. While similar issues in other implementations like Go are tracked under CVE-2026-102510, this specific instance affects Java-based deployments and highlights the need for explicit depth limits when handling recursive data formats. This defect corresponds to CWE-674: Uncontrolled Recursion, where insufficient control over recursion levels leads to system instability or crashes due to stack exhaustion.
The operational impact of these vulnerabilities is severe, primarily resulting in denial-of-service conditions that can disrupt industrial processes relying on PLC communication. Attackers do not need authentication privileges to exploit these flaws, making them accessible to any network participant who can inject crafted packets into the communication stream. The combination of excessive memory allocation and uncontrolled recursion creates a potent vector for destabilizing applications quickly and reliably. For organizations using Apache PLC4X in production environments, this represents a critical risk that must be addressed promptly to maintain system availability and integrity.
Mitigation strategies focus primarily on upgrading to version 1.0.0 or later of Apache PLC4X, which resolves these issues by implementing proper validation checks before resource allocation and enforcing limits on recursion depth and message sizes. Until an upgrade is feasible, organizations should consider network-level mitigations such as rate limiting incoming connections from untrusted sources and deploying intrusion detection systems capable of identifying anomalous packet structures indicative of this exploitation attempt. Additionally, configuring application servers to run with restricted memory quotas can help contain the impact of successful attacks by preventing a single compromised process from consuming all available system resources. Regular security audits and penetration testing should also be conducted to identify similar patterns in custom protocol implementations that may share these weaknesses.