Apache Plc4X
Monthly
Improper verification of the source of ADS discovery responses in Apache PLC4X (CWE-940) allows an attacker on the adjacent network to redirect subsequent connections to an arbitrary host by spoofing a UDP discovery response, potentially exposing ADS route credentials. Affected versions are PLC4Go 0.11.0-<1.0.0, PLC4J ADS/Modbus 0.10.0-<1.0.0, and PLC4J EtherNet/IP 0.11.0-<1.0.0. Exploitation requires the consuming application to invoke the opt-in discovery API and act on discovered items; no public exploit identified at time of analysis. Upgrade to 1.0.0 to fix.
Memory exhaustion and parser panics in the Go implementation of Apache PLC4X (PLC4Go) allow a malicious PLC device, or an attacker able to inject or spoof frames on the industrial network path, to crash or exhaust the client application, resulting in denial of service. The flaws affect Go module github.com/apache/plc4x/plc4go from 0.11.0 up to but not including 1.0.0 and include unbounded wire-claimed array and buffer allocations, unchecked indexing of ADS and KNXnet/IP responses, zero-length framing that breaks ADS and EIP message boundaries, unlimited recursion in recursive protocol types, and 16-bit length/position arithmetic in generated serializers that wraps and can cause payloads larger than 8 KB to be mis-framed. CVSS vector indicates no authentication is required (PR:N) and no public exploit has been identified at time of analysis; exploitation is limited to environments where a PLC4Go client talks to untrusted or attacker-reachable industrial endpoints, and impact is availability only.
Denial of service in Apache PLC4X (PLC4J Java) from 0.10.0 before 1.0.0 allows a remote, unauthenticated attacker who can impersonate an OPC UA server to exhaust the client application's memory or stack during connection setup. The defects are triggered while the secure channel and session are established, before server identity is bound, so trusting a configured server does not prevent exploitation. No public exploit identified at time of analysis; vendor CVSS 4.0 score is 8.7 and the independent CVSS 3.1 assessment confirms AV:N/AC:L/PR:N/UI:N with availability-only impact (A:H).
Man-in-the-middle attackers can impersonate the OPC UA server to Apache PLC4X (PLC4J) client applications and read, forge or modify secure-channel traffic - including the user credentials the client sends - affecting versions 0.9.0 through 0.13.1, with the fix landing in 1.0.0. Unauthenticated network attackers holding an on-path position (the AT:P requirement) benefit from insecure defaults: the security policy defaults to None in every affected release, 0.9.0-0.11.0 only log failed message-signature checks and never verify the server certificate taken from the unauthenticated GetEndpoints response, while 0.12.0-0.13.1 invert the signature check (rejecting valid signatures and accepting invalid ones) and accept server certificates with no trust anchor; from 0.12.0 the driver also silently continues at a weaker policy than configured, and from 0.13.0 endpoint selection prefers the weakest matching endpoint. Rated 9.2 (Critical) under CVSS 4.0 and high-severity under the independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H); no public exploit code identified at time of analysis.
Improper verification of the source of ADS discovery responses in Apache PLC4X (CWE-940) allows an attacker on the adjacent network to redirect subsequent connections to an arbitrary host by spoofing a UDP discovery response, potentially exposing ADS route credentials. Affected versions are PLC4Go 0.11.0-<1.0.0, PLC4J ADS/Modbus 0.10.0-<1.0.0, and PLC4J EtherNet/IP 0.11.0-<1.0.0. Exploitation requires the consuming application to invoke the opt-in discovery API and act on discovered items; no public exploit identified at time of analysis. Upgrade to 1.0.0 to fix.
Memory exhaustion and parser panics in the Go implementation of Apache PLC4X (PLC4Go) allow a malicious PLC device, or an attacker able to inject or spoof frames on the industrial network path, to crash or exhaust the client application, resulting in denial of service. The flaws affect Go module github.com/apache/plc4x/plc4go from 0.11.0 up to but not including 1.0.0 and include unbounded wire-claimed array and buffer allocations, unchecked indexing of ADS and KNXnet/IP responses, zero-length framing that breaks ADS and EIP message boundaries, unlimited recursion in recursive protocol types, and 16-bit length/position arithmetic in generated serializers that wraps and can cause payloads larger than 8 KB to be mis-framed. CVSS vector indicates no authentication is required (PR:N) and no public exploit has been identified at time of analysis; exploitation is limited to environments where a PLC4Go client talks to untrusted or attacker-reachable industrial endpoints, and impact is availability only.
Denial of service in Apache PLC4X (PLC4J Java) from 0.10.0 before 1.0.0 allows a remote, unauthenticated attacker who can impersonate an OPC UA server to exhaust the client application's memory or stack during connection setup. The defects are triggered while the secure channel and session are established, before server identity is bound, so trusting a configured server does not prevent exploitation. No public exploit identified at time of analysis; vendor CVSS 4.0 score is 8.7 and the independent CVSS 3.1 assessment confirms AV:N/AC:L/PR:N/UI:N with availability-only impact (A:H).
Man-in-the-middle attackers can impersonate the OPC UA server to Apache PLC4X (PLC4J) client applications and read, forge or modify secure-channel traffic - including the user credentials the client sends - affecting versions 0.9.0 through 0.13.1, with the fix landing in 1.0.0. Unauthenticated network attackers holding an on-path position (the AT:P requirement) benefit from insecure defaults: the security policy defaults to None in every affected release, 0.9.0-0.11.0 only log failed message-signature checks and never verify the server certificate taken from the unauthenticated GetEndpoints response, while 0.12.0-0.13.1 invert the signature check (rejecting valid signatures and accepting invalid ones) and accept server certificates with no trust anchor; from 0.12.0 the driver also silently continues at a weaker policy than configured, and from 0.13.0 endpoint selection prefers the weakest matching endpoint. Rated 9.2 (Critical) under CVSS 4.0 and high-severity under the independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H); no public exploit code identified at time of analysis.