CVE-2026-94639 is a high-severity vulnerability in Apache Thrift before version 0.25.0. It involves improper handling of exceptional conditions in the Java bindings, specifically allocation of resources without limits or throttling and uncaught exceptions. This flaw can lead to resource exhaustion or application instability. The issue is fixed in Apache Thrift version 0.25.0.
CVE-2026-94635 is a high-severity vulnerability in Apache Thrift prior to version 0.25.0. It involves allocation of resources without limits or throttling due to improper handling of length parameter inconsistencies in the Lua bindings. This flaw can lead to resource exhaustion. The issue is fixed in Apache Thrift version 0.25.0.
In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
CVE-2026-63578 is a resource exhaustion vulnerability in the Legion of the Bouncy Castle Inc. bc-csharp library before version 2.7.0. It occurs in the password-based private-key decryption function (PbeUtilities.GenerateCipherParameters) where an attacker can supply an encrypted private key with an iteration count near 2^31. This count is taken from unauthenticated algorithm parameters without an upper bound, causing excessive CPU consumption and denial of service. The vulnerability affects PKCS#5 PBES1 and PBES2 (PBKDF2), PKCS#12 PBE algorithms, and CMS password recipients. The issue is fixed in version 2.7.0.
CVE-2026-63572 is a high-severity vulnerability in Legion of the Bouncy Castle Inc.'s bc-csharp library before version 2.7.0. It involves allocation of resources without limits during PKCS#12 keystore loading, allowing an attacker to cause denial of service via CPU exhaustion by supplying a specially crafted PKCS#12 file with a very high iteration count. This iteration count is used in key derivation before password verification, leading to excessive CPU usage. The vulnerability affects the Pkcs12Store.Load method and Pkcs12Utilities.ConvertToDefiniteLength. Versions from 0 up to but not including 2.7.0 are affected.
Allocation of resources without limits or throttling in the CMP/CRMF password-based MAC verifier (PKMacBuilder) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker to cause a denial of service through CPU exhaustion via a CMP message or CRMF certificate request whose PBMParameter declares a very large iteration count, because PKMacBuilder enforced its iteration-count ceiling only when the caller had supplied an explicit maximum through the PKMacBuilder(IPKMacPrimitivesProvider, int) constructor. With any other constructor, ProtectedPkiMessage.Verify and CertificateRequestMessage.IsValidSigningKeyPop performed as many hash iterations as the sender requested, up to about 2^31, before the MAC could be checked.
CVE-2026-68496 is a high-severity vulnerability in the Smile parser component of FasterXML jackson-dataformats-binary. The parser fails to enforce the maxNameLength limit on JSON object property names, allowing an attacker to submit a Smile document with an unboundedly long property name. This leads to uncontrolled memory allocation and potential denial of service due to memory exhaustion. The issue affects multiple jackson-dataformats-binary versions starting from 2.16.0 where the constraint was introduced but not enforced. No special privileges are required to exploit this vulnerability.
CVE-2026-68495 is a high-severity vulnerability in the CBOR parser of FasterXML jackson-dataformats-binary. The parser does not enforce the maxNameLength limit when decoding JSON object property names in CBOR format, allowing an attacker to submit a property name of unbounded length. This can lead to memory exhaustion and denial of service due to unbounded memory allocation during parsing. No special privileges are required beyond the ability to submit data to the parser. The issue affects multiple versions starting from 2.16.0 where the maxNameLength constraint was introduced but not enforced in this parser. The vulnerability is tracked alongside a related Smile parser defect under the same vendor advisory.
Allocation of resources without limits or throttling vulnerability in batch-requests plugin in Apache APISIX.
An unauthenticated caller can drive a gateway worker into OOM via a route where the batch-requests plugin is used and the batch endpoint is publicly exposed. This issue affects Apache APISIX: from 1.3.0 through 3.18.0.
Users are recommended to upgrade to version 3.19.0, which fixes the issue.
CVE-2026-102993 is a high-severity vulnerability in the pypdf Python library prior to version 6.17.0. It involves uncontrolled resource consumption caused by processing crafted PDF files with unusually large Roman page-label values. This leads to excessive memory use and potential application unavailability. The issue is fixed in pypdf version 6.17.0.
The CODESYS Gateway Client allocates memory based on a size field in a gateway response without enforcing an appropriate upper limit. An unauthenticated remote attacker controlling a malicious gateway can exploit this behavior to trigger excessive memory consumption, resulting in a denial-of-service condition thus leading to a total loss of availablity.
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.
CVE-2026-93996 is a vulnerability in Apache MINA SSHD's sshd-scp component that allows uncontrolled resource consumption. The SCP protocol handler did not limit the length of protocol lines, enabling a malicious peer to send a never-ending line without line feed characters. This causes the receiver to allocate excessive memory, potentially leading to an OutOfMemoryError and application crash. Versions up to 2.19.0 and from 3.0.0-M1 to 3.0.0-M5 are affected. Upgrading to versions 2.20.0 or 3.0.0-M6 mitigates the issue by enforcing an upper limit on SCP protocol line length.
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.
Pexip Infinity before 41.0 is affected by improper input validation in the signaling implementation which allows a remote attacker to trigger a software abort resulting in a denial of service. Exploitation of this issue requires accessing a gateway call from a WebRTC/API client.