Export limit exceeded: 401101 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (401101 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-86535 | 2 Apache, Redhat | 2 Thrift, Hummingbird | 2026-10-02 | 7.5 High |
| Loop with unreachable exit condition ('infinite loop'), Improperly controlled modification of object prototype attributes ('prototype pollution') vulnerability in Apache Thrift NodeJS bindings with TJSONProtocol. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | ||||
| CVE-2026-85476 | 2026-10-02 | N/A | ||
| Loop with unreachable exit condition ('infinite loop') vulnerability in Apache Thrift c_glib bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | ||||
| CVE-2026-85088 | 1 Redhat | 1 Hummingbird | 2026-10-02 | 7.4 High |
| Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift. Both libraries install a default access manager for client sockets — TSSLSocketFactory does so in C++, and the accessManager property does so in D — which compares the peer certificate against the host name that was connected to. That comparison walks the subjectAltName dNSName entries first and consults the certificate Common Name afterwards. A name that does not match yields a "skip" result rather than a rejection, so a certificate whose subjectAltName entries are all present and all non-matching falls through to the Common Name, which can then satisfy the check. RFC 6125 section 6.4.4, and RFC 9525 section 2, require that the Common Name is not consulted when a dNSName subjectAltName is present. A certificate carrying subjectAltName entries for one name and a Common Name for another is therefore accepted for a connection to the second name. Exploitation requires an attacker positioned on the network path who holds a certificate that chains to a certificate authority in the client's trust store and whose Common Name matches the connected host name. Public certificate authorities have not issued on Common Name alone for many years, so this is principally a concern for deployments using a private or enterprise public-key infrastructure. This issue affects the C++ library of Apache Thrift from 0.7.0 through 0.24.0 and the D library from 0.9.0 through 0.24.0. Users should upgrade to 0.25.0. | ||||
| CVE-2026-85087 | 1 Apache | 1 Thrift | 2026-10-02 | N/A |
| Improper certificate validation, Return of wrong status code vulnerability in Apache Thrift python bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | ||||
| CVE-2026-85086 | 1 Redhat | 1 Hummingbird | 2026-10-02 | 7.4 High |
| Improper certificate validation, Initialization of a resource with an insecure default vulnerability in Apache Thrift perl bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | ||||
| CVE-2026-83745 | 1 Redhat | 1 Hummingbird | 2026-10-02 | 7.5 High |
| Memory allocation with excessive size value, Improper handling of length parameter inconsistency vulnerability in Apache Thrift nodejs and D lang bindings. Both bindings' WebSocket server transports read the payload length out of the frame header and allocate that many bytes immediately, without checking that the bytes have arrived. A single ~14-byte frame therefore commits as much memory as it cares to declare -- measured at 513 MiB against the Node.js server and 2 GiB against the D transport -- and in the Node.js case the connection is left open afterwards, so the frame can simply be sent again. This issue affects Apache Thrift before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | ||||
| CVE-2026-82459 | 2 Apache, Redhat | 2 Thrift, Hummingbird | 2026-10-02 | 7.5 High |
| Integer underflow (wrap or wraparound), Out-of-bounds write vulnerability in Apache Thrift C++ 32 bit THeaderTransport. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | ||||
| CVE-2026-82458 | 1 Redhat | 1 Hummingbird | 2026-10-02 | 7.5 High |
| Memory allocation with excessive size value, Allocation of resources without limits or throttling vulnerability in Apache Thrift Go, netstd, OCaml, Erlang, JavaME, Rust, C++, Java, Kotlin and D language bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | ||||
| CVE-2026-80298 | 1 Havelsan Inc. | 1 Sef - Ai Chatbot Platform | 2026-10-02 | 8.8 High |
| Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in HAVELSAN Inc. Sef - AI Chatbot Platform allows SQL Injection. This issue affects Sef - AI Chatbot Platform: before 2.1. NOTE: The vendor was contacted and it was learned that the product is not supported. | ||||
| CVE-2026-63568 | 2026-10-02 | N/A | ||
| 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-63566 | 2026-10-02 | N/A | ||
| Memory allocation with excessive size value in the DTLS handshake reassembly (DtlsReliableHandshake, DtlsReassembler) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated DTLS peer to cause a denial of service through memory exhaustion via crafted handshake message fragments, because the reassembly buffer for each incoming handshake message was allocated at the 24-bit length declared in the fragment header, without the check against the peer's maximum handshake message size that TLS already applied. A fragment carrying no payload can force an allocation of almost 16 MB, for each of up to 16 pending messages per handshake, before the handshake is authenticated. DTLS servers and DTLS clients are both affected; TLS is not. | ||||
| CVE-2026-59669 | 1 Repasat | 1 Repasat Application | 2026-10-02 | N/A |
| Cross-Site Scripting vulnerability in the Repasat application. Successful exploitation of this vulnerability could allow an attacker to trick a user into executing arbitrary code in the victim’s browser. The “name” parameter is affected – endpoint “/es/attachmenttypes/update/203336” | ||||
| CVE-2026-59664 | 1 Repasat | 1 Repasat Application | 2026-10-02 | N/A |
| Cross-Site Scripting vulnerability in the Repasat application. Successful exploitation of this vulnerability could allow an attacker to trick a user into executing arbitrary code in the victim’s browser. The “nomServicioPrestado” parameter is affected – endpoint “/es/providedservices/store”. | ||||
| CVE-2026-59663 | 1 Repasat | 1 Repasat Application | 2026-10-02 | N/A |
| Cross-Site Scripting vulnerability in the Repasat application. Successful exploitation of this vulnerability could allow an attacker to trick a user into executing arbitrary code in the victim’s browser. The “nomDelegacion” parameter is affected – endpoint “/es/delegations/store”. | ||||
| CVE-2026-59662 | 1 Repasat | 1 Repasat Application | 2026-10-02 | N/A |
| Cross-Site Scripting vulnerability in the Repasat application. Successful exploitation of this vulnerability could allow an attacker to trick a user into executing arbitrary code in the victim’s browser. The “nomCompetidor” parameter is affected – endpoint “/es/competitors/store”. | ||||
| CVE-2026-18036 | 1 Legion Of The Bouncy Castle Inc. | 1 Bc-java | 2026-10-02 | N/A |
| In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation's division-free fold and select; the results are unchanged. | ||||
| CVE-2026-17508 | 2026-10-02 | N/A | ||
| 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-17507 | 1 Legion Of The Bouncy Castle Inc. | 1 Bc-java | 2026-10-02 | N/A |
| In Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420's uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree's leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected. | ||||
| CVE-2026-16001 | 1 Legion Of The Bouncy Castle Inc. | 1 Bc-csharp | 2026-10-02 | N/A |
| Exposure of the message authentication key through the encryption keystream in the stream mode of IesEngine (an IesEngine constructed without a block cipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker who has observed one encrypted message with known plaintext to forge shorter messages of their choosing that the recipient accepts as authentic, via a crafted ciphertext and MAC tag, because the MAC key was taken from the key derivation output directly after a keystream as long as the message, while the derivation input depends only on the static key pair and fixed parameters. The keystream revealed by that one message therefore contains the MAC key for every sufficiently shorter message. | ||||
| CVE-2026-15999 | 1 Legion Of The Bouncy Castle Inc. | 1 Bc-csharp | 2026-10-02 | N/A |
| Improper validation of integrity check value in the AES-CCM implementation (CcmParameters and CcmBlockCipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an on-path attacker to modify CCM-encrypted content without detection via an AlgorithmIdentifier whose CCMParameters declare an authentication tag (aes-ICVlen) of zero or another length outside the RFC 5084 set, because CcmParameters accepted any value and CcmBlockCipher validated the tag length only when encrypting, so decryption compared a zero-length or very short tag. Affected paths include ParameterUtilities.GetCipherParameters, used by CmsEnvelopedData and CmsEnvelopedDataParser for EnvelopedData encrypted with AES-CCM, and any caller passing an unchecked tag length to CcmBlockCipher for decryption. | ||||