CVE-2026-92899 is a medium severity vulnerability in Apache WSS4J where the Nonce value in UsernameTokens is stored as raw base64 text, but authentication uses decoded bytes. This allows an attacker who captures an authenticated request to modify the Nonce by adding a space, bypassing the replay cache and reusing the token until it expires. The issue affects deployments with a nonce replay cache configured and tokens using password digest. Fixed versions are 4.0.2, 3.0.6, and 2.4.4.
CVE-2026-92121 is a vulnerability in Apache WSS4J's streaming (StAX) code where a signature reference using the WS-Security STR-Transform causes an internal flag to remain set incorrectly. This leads the WS-SecurityPolicy enforcer to stop verifying signed parts for the remainder of the message, allowing a policy requiring the SOAP Body to be signed to be falsely satisfied even if the Body is unsigned. The DOM code is not affected. Versions 4.0.2, 3.0.6, and 2.4.4 include fixes for this issue.
CVE-2026-89238 is a critical vulnerability in Apache WSS4J that allows an attacker to exploit EncryptedHeader child confusion. This flaw can cause an attacker-controlled plaintext element to be treated as the decrypted header, resulting in incorrect confidentiality coverage and potential policy bypass. The vulnerability affects multiple versions and has been fixed in Apache WSS4J versions 4.0.2, 3.0.6, and 2.4.4.
An integer overflow in WSS4J's DER bounds check lets an oversized allocation pass validation. An unauthenticated attacker can send a SOAP message carrying an X.509 certificate whose SubjectKeyIdentifier extension declares a length of 0x7FFFFFFF; WSS4J decodes this while resolving the signature's key reference, before the message is authenticated, so an eleven-byte extension triggers a 2 GB allocation. Repeated requests exhaust server memory.
Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue.
CVE-2026-87830 is a critical vulnerability in Apache WSS4J's StAX streaming WS-SecurityPolicy validator. It allows certain relative or unsupported XPath expressions to bypass expected signature or encryption requirements in SOAP messages. This can lead to loss of confidentiality and integrity of these messages. The issue is fixed in versions 4.0.2, 3.0.6, and 2.4.4.
Apache WSS4J versions prior to 4.0.2, 3.0.6, and 2.4.4 improperly validate attacker-controlled derived-key lengths and offsets. This flaw allows the use of cryptographically weak keys or causes excessive CPU and memory consumption when processing crafted WS-Security messages. The issue is fixed by enforcing minimum and maximum key lengths and offset limits. Users should upgrade to fixed versions to mitigate the risk.
CVE-2026-94002 is a high-severity vulnerability in Apache MINA SSHD's sshd-sftp component affecting versions from 0.9.0 up to but not including 2.20.0, and 3.0.0-M1 up to but not including 3.0.0-M6. The issue arises because the SFTP client does not verify that replies correspond to requests it sent, allowing a malicious server to send unsolicited replies that accumulate in memory, potentially exhausting client resources. Upgrading to versions 2.20.0 or 3.0.0-M6 or later mitigates this issue.
CVE-2026-94029 is a server-side memory exhaustion vulnerability in Apache MINA SSHD affecting versions from 1.0.0 up to but not including 2.20.0 and from 3.0.0-M1 up to but not including 3.0.0-M6. The flaw exists in the sshd-sftp component during the SFTP v6 check-file-name/check-file-handle extension. Using a very small block size on a large file causes the server to accumulate a large reply message fully in memory, potentially exhausting server memory and causing a denial of service. The issue is fixed in versions 2.20.0 and 3.0.0-M6 by imposing a maximum limit on the size of the reply message.
Apache MINA SSHD is a Java library for client-side and server-side SSH. SSH servers can be configured to require multi-authentication schemes, for instance two different public keys, not just one. In OpenSSH, this would be done by setting in sshd_config AuthenticationMethods "publickey,publickey". Apache MINA SSHD provides an equivalent configuration mechanism.
In Apache MINA SSHD versions up to 2.19.0 and 3.0.0-M1 to 3.0.0-M5 the server code in component sshd-core does not enforce that the two public keys presented are different. A user can thus successfully authenticate with only one of the two key pairs required by presenting this single key twice. This is a partial authentication bypass.
Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue.
Authentication bypass via LDAP injection in component sshd-ldap in Apache MINA SSHD versions 1.2.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5.
Apache MINA SSHD is a Java library for client-side and server-side SSH.
The optional sshd-ldap component provides support for integrating
password and publickey authentication on the server side with an LDAP
server.
sshd-ldap is an optional component. SSH servers implemented with Apache
MINA SSHD are affected only if they use sshd-ldap and do configure it to be used for password of public key authentication.
Other Apache MINA SSHD servers are not affected.
Lack of escaping LDAP filter metacharacters enabled successful authentication with username "*" and password "*".
Users are recommended to upgrade affected applications to version 2.20.0 or 3.0.0-M6, which fix this issue by properly escaping filter parameters according to RFC 4515.
A missing check in LdapPasswordAuthenticator in component sshd-ldap in Apache MINA SSHD versions 1.2.0 to 2.19.0 or 3.0.0-M1 to 3.0.0-M5 bypassed authentication checks.
Apache MINA SSHD is a Java library for client-side and server-side SSH. The optional sshd-ldap component provides support for integrating password and publickey authentication on the server side with an LDAP server.
sshd-ldap is an optional component. SSH servers implemented with Apache MINA SSHD are affected only if they use sshd-ldap and do configure an LdapPasswordAuthenticator to be used for password authentication. Normal password authentication via the built-in mechanisms in sshd-core is _not_ affected by this vulnerability, which concerns only LdapPasswordAuthenticator.
Users are recommended to upgrade affected applications to version 2.20.0 or 3.0.0-M6, which fix this issue.
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.
Integer Overflow, Improper Validation of Array Index, Uncontrolled Recursion and Memory Allocation with Excessive Size Value in the Go implementation of Apache PLC4X (PLC4Go) allow a malicious device, or an attacker able to inject network traffic, to crash or exhaust the memory of the client application,
causing a denial of service.
The individual defects are:
- Generated parsers pre-allocate arrays with the element count claimed on the wire (0.13.0 through 0.13.1).
- Transport read helpers allocate buffers of the size claimed on the wire without an upper bound.
- ADS and KNXnet/IP response handling indexes into received data without checking its length, causing a panic.
- ADS and EIP frame-length handling accepts, or arithmetically wraps to, a length of zero, breaking message framing.
- Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Java implementation is covered by CVE-2026-102509 https://cveprocess.apache.org/cve5/CVE-2026-102509 .
Additionally, length and position arithmetic in generated serializers was performed in 16-bit integers. If an application forwards attacker-influenced payloads larger than 8 KB, the length field wraps, and the remainder of the payload may be interpreted by the receiving device (for example, an ADS PLC) as
additional, independent protocol messages.
This issue affects Apache PLC4X: 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.
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.
Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to read, forge or modify secure-channel traffic, including user credential ssent by the client.
The defect manifests differently depending on the version:
- In 0.9.0 through 0.11.0 a failed message-signature check is only logged and never enforced, and there is no mechanism to verify the server certificate: it is taken from the unauthenticated GetEndpoints discovery response and used to encrypt the user's password.
- In 0.12.0 through 0.13.1 the signature check is inverted (valid signatures are rejected, invalid ones accepted), and server certificates are accepted without a trust anchor by default.
- In all affected versions the default security policy is None. Starting with 0.12.0 the driver additionally continues silently at a weaker security policy than the one configured, and starting with 0.13.0 endpoint selection prefers the weakest matching endpoint.
Users checking only for one of these mechanisms may wrongly conclude they are unaffected.
This issue affects Apache PLC4X: from 0.9.0 before 1.0.0.
Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 verifies message signatures correctly, refuses to connect unless the server certificate can be verified against a configured trust store or pinned certificate, defaults to Basic256Sha256 with SignAndEncrypt, and fails the
connection if the negotiated security policy is weaker than the configured one.
CVE-2026-97395 is a vulnerability in Apache Polaris versions prior to 1.8.0 that allows an authenticated user with permission to create or update Iceberg table properties to manipulate FileIO client settings such as s3.endpoint in table metadata. This can cause server-side storage requests to be redirected to an attacker-controlled endpoint, potentially exposing authentication credentials. The vulnerability affects deployments where table writers are not trusted to configure storage endpoints. A patch is available, and since Apache Polaris is a cloud service, the vendor manages remediation.
An improper authorization check in Apache DolphinScheduler allows an authenticated user to use the batch-copy and batch-move endpoints to operate on workflows in projects for which they lack the required permissions. This may allow the user to copy or move workflows from unauthorized projects.
This issue affects Apache DolphinScheduler: before 3.4.3.
Users are recommended to upgrade to version 3.4.3, which fixes the issue.
An incorrect authorization check in Apache DolphinScheduler allows an authenticated user with only read permission for a project to modify a workflow instance in that project through the PUT /projects/{projectCode}/workflow-instances/{id} endpoint. The endpoint does not enforce the write permission required for this operation, allowing the user to make unauthorized changes to workflow instances.
This issue affects Apache DolphinScheduler: before 3.4.3.
Users are recommended to upgrade to version 3.4.3, which fixes the issue.
An improper authorization vulnerability exists in the handling of sub-workflow tasks. An authenticated user who does not have permission to access a target project can reference and invoke a workflow belonging to that project through a sub-workflow task.
The system does not properly verify whether the user has permission to execute the referenced workflow or access its project. As a result, the user can bypass project-level authorization controls and cause workflows in unauthorized projects to be executed.
Successful exploitation may allow unauthorized execution of workflow tasks and access to the resources or data available to the target workflow.
This issue affects Apache DolphinScheduler: before 3.4.3.
Users are recommended to upgrade to version 3.4.3, which fixes the issue.
CVE-2026-82804 is a high-severity OS command injection vulnerability in Apache DolphinScheduler before version 3.4.3. It arises from insufficient neutralization of shell metacharacters in the scriptPath parameter used in a shell command. An authenticated user can exploit this by crafting a resource filename with shell command substitution syntax, leading to arbitrary command execution with DolphinScheduler service privileges. The issue is fixed in version 3.4.3.