Total
1568 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-56231 | 1 Tonec | 1 Internet Download Manager | 2026-07-05 | N/A | 9.1 CRITICAL |
| Tonec Internet Download Manager 6.42.41.1 and earlier suffers from Missing SSL Certificate Validation, which allows attackers to bypass update protections. | |||||
| CVE-2025-44964 | 1 Bluestacks | 1 Bluestacks | 2026-07-05 | N/A | 3.9 LOW |
| A lack of SSL certificate validation in BlueStacks v5.20 allows attackers to execute a man-it-the-middle attack and obtain sensitive information. | |||||
| CVE-2024-41334 | 1 Draytek | 40 Vigor165, Vigor165 Firmware, Vigor166 and 37 more | 2026-07-05 | N/A | 8.8 HIGH |
| Draytek devices Vigor 165/166 prior to v4.2.6 , Vigor 2620/LTE200 prior to v3.9.8.8, Vigor 2860/2925 prior to v3.9.7, Vigor 2862/2926 prior to v3.9.9.4, Vigor 2133/2762/2832 prior to v3.9.8, Vigor 2135/2765/2766 prior to v4.4.5.1, Vigor 2865/2866/2927 prior to v4.4.5.3, Vigor 2962/3910 prior to v4.3.2.7, Vigor 3912 prior to v4.3.5.2, and Vigor 2925 up to v3.9.6 were discovered to not utilize certificate verification, allowing attackers to upload crafted APPE modules from non-official servers, leading to arbitrary code execution. | |||||
| CVE-2026-12374 | 2026-07-02 | N/A | N/A | ||
| Improper certificate validation and a time-of-check time-of-use (TOCTOU) race condition in the PrivilegedHelperTool XPC service in Cato Client before v.5.13.1 on macOS allows a local authenticated attacker to escalate privileges to root via a self-signed certificate that bypasses the XPC caller verification and a symlink swap during package installation. | |||||
| CVE-2026-5263 | 1 Wolfssl | 1 Wolfssl | 2026-07-02 | N/A | 6.5 MEDIUM |
| URI nameConstraints from constrained intermediate CAs are parsed but not enforced during certificate chain verification in wolfcrypt/src/asn.c. A compromised or malicious sub-CA could issue leaf certificates with URI SAN entries that violate the nameConstraints of the issuing CA, and wolfSSL would accept them as valid. | |||||
| CVE-2026-8480 | 2026-07-01 | N/A | 4.3 MEDIUM | ||
| A vulnerability was discovered on Stormshield Network Security 4.3.0 to 4.3.41 (included), 4.4.0 to 4.8.15 (included) , 5.0.2 EA to 5.0.5 (included) A revoked client certificate can still be used to authenticate to the captive‑admin portal, allowing an attacker who possesses the revoked certificate to gain administrative access. | |||||
| CVE-2026-7532 | 1 Wolfssl | 1 Wolfssl | 2026-07-01 | N/A | 7.5 HIGH |
| iPAddress name constraints bypass when WOLFSSL_IP_ALT_NAME is not defined. IP address name constraints are not enforced in that configuration, allowing a certificate to bypass an issuing CA's IP address constraints. | |||||
| CVE-2025-2669 | 1 Ibm | 3 Cloud Pak For Data, Db2, Db2 Warehouse | 2026-06-30 | N/A | 6.0 MEDIUM |
| IBM Db2 on Cloud Pak for Data and Db2 Warehouse on Cloud Pak for Data versions 4.8, 5.0, 5.1, 5.2, 5.3 could allow a privileged user to perform operations and obtain sensitive information outside of their authority due to improper token validation. | |||||
| CVE-2026-48934 | 1 Nodejs | 1 Node.js | 2026-06-29 | N/A | 4.3 MEDIUM |
| A flaw in Node.js TLS host verification can cause an attacker to bypass certification validation. This vulnerability affects all supported release lines: **Node.js 22**, **Node.js 24**, and **Node.js 26**. | |||||
| CVE-2025-40745 | 1 Siemens | 7 Simcenter 3d, Simcenter Femap, Simcenter Star-ccm\+ Viewer and 4 more | 2026-06-29 | N/A | 3.7 LOW |
| A vulnerability has been identified in Siemens Software Center (All versions < V3.5.8.2), Simcenter 3D (All versions < V2506.6000), Simcenter Femap (All versions < V2506.0002), Simcenter STAR-CCM+ (All versions < V2602), Solid Edge SE2025 (All versions < V225.0 Update 13), Solid Edge SE2026 (All versions < V226.0 Update 04), Tecnomatix Plant Simulation (All versions < V2504.0008). Affected applications do not properly validate client certificates to connect to Analytics Service endpoint. This could allow an unauthenticated remote attacker to perform man in the middle attacks. | |||||
| CVE-2026-6731 | 1 Wolfssl | 1 Wolfssl | 2026-06-27 | N/A | 7.5 HIGH |
| X.509 name constraint bypass via the Subject Common Name when treated as a DNS-type name. A certificate whose Subject CN violates an issuing CA's DNS name constraints could be accepted. | |||||
| CVE-2026-10098 | 1 Wolfssl | 1 Wolfssl | 2026-06-27 | N/A | 5.3 MEDIUM |
| OCSP CertID serial-number length-confusion in wolfSSL_OCSP_resp_find_status allows a same-issuer SingleResponse whose serial is a prefix of the target serial to be reported as the revocation status of a different certificate. The lookup compared serial-number bytes without first requiring the two serial numbers to be of equal length, so a SingleResponse for one certificate (same issuer) whose serial is a prefix of the target's serial would match, returning the wrong certificate's status. The fix requires the serial lengths to be equal before comparing the serial bytes. | |||||
| CVE-2026-6450 | 1 Wolfssl | 1 Wolfssl | 2026-06-27 | N/A | 5.3 MEDIUM |
| A CRL critical extension bypass exists in ParseCRL_Extensions where critical extensions are not properly enforced, allowing a crafted CRL with an unhandled critical extension to be accepted. This only affects builds with CRL support enabled and where a crafted CRL had a trusted signature when parsed. | |||||
| CVE-2026-57289 | 1 Jenkins | 1 Bitbucket Push And Pull Request | 2026-06-26 | N/A | 4.8 MEDIUM |
| Jenkins Bitbucket Push and Pull Request Plugin 3.3.8 and earlier unconditionally disables SSL/TLS certificate and hostname validation for connections sending Bearer token authenticated requests to the configured Bitbucket Server endpoint, allowing attackers able to intercept network traffic to capture the token. | |||||
| CVE-2026-10592 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 5.3 MEDIUM |
| Certificates with wildcard DNS SANs (e.g. *.example.com) bypassed CA name-constraint checks. A certificate with a wildcard DNS SAN that should be rejected by the issuing CA's permitted/excluded DNS name constraints could be accepted. | |||||
| CVE-2026-11310 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 7.5 HIGH |
| X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts. | |||||
| CVE-2026-55960 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 7.5 HIGH |
| Un-negotiated Raw Public Key (RFC 7250) accepted in place of an X.509 certificate, bypassing chain validation. A raw public key has no chain, so ParseCertRelative() accepts it without performing any trust verification; it must therefore only be accepted when RPK was actually negotiated for that peer. The check now defaults the expected type to X.509 (per RFC 7250/8446) when no type was negotiated, comparing against the received server certificate type on the client and the selected client certificate type on the server, and rejects any mismatch, including an un-negotiated raw public key, with UNSUPPORTED_CERTIFICATE. Only affects builds with Raw Public Key support (HAVE_RPK) enabled - disabled by default in a standalone build, but included in --enable-all. | |||||
| CVE-2026-55964 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 5.3 MEDIUM |
| Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA. Intermediate CA certificates are required to have the keyCertSign key usage when a Key Usage extension is present, but chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building a certificate path were previously exempted from this check, so an intermediate asserting CA:TRUE but lacking keyCertSign was accepted as a signing CA. The check now applies to chain-supplied temporary CAs as well; only operator-loaded root certificates (WOLFSSL_USER_CA) and self-signed roots remain exempt. Per RFC 5280 an absent Key Usage extension implies all usages, so the requirement is enforced only when the extension is actually present (extKeyUsageSet). Affects the OpenSSL-compatibility certificate-path-building path (X509_verify_cert / X509_STORE, OPENSSL_EXTRA/OPENSSL_ALL), where untrusted chain intermediates are added as temporary CAs; native (non-OpenSSL-compat) certificate verification does not create temporary CAs and is unaffected. Within those builds, the check applies unless ALLOW_INVALID_CERTSIGN is defined. | |||||
| CVE-2026-6091 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 6.5 MEDIUM |
| Partial-chain certificate verification may accept chains that terminate at a peer-supplied, untrusted intermediate certificate rather than a trusted anchor. An attacker could present a chain that ends at an intermediate they control and have it accepted as valid. This affects the OpenSSL compatibility certificate-path-building path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the X509_V_FLAG_PARTIAL_CHAIN verify flag is enabled. | |||||
| CVE-2026-11999 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 7.5 HIGH |
| X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier's maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are. | |||||