Search vulnerabilities

Use the Query Builder to create your own search query, or check out the documentation to learn the search syntax.

Results 1,874

Export CSV
CVE-2026-100118

CAI Content Credentials | Improper Certificate Validation (CWE-295)

CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Adobe
Products
C2pa C2pa-web C2patool and 2 more
CVE-2026-100121

CAI Content Credentials | Improper Certificate Validation (CWE-295)

CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Adobe
Products
C2pa C2pa-web C2patool and 2 more
CVE-2026-100122

CAI Content Credentials | Improper Certificate Validation (CWE-295)

CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Adobe
Products
C2pa C2pa-web C2patool and 2 more
CVE-2026-100123

CAI Content Credentials | Improper Certificate Validation (CWE-295)

CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Adobe
Products
C2pa C2pa-web C2patool and 2 more
CVE-2026-100116

CAI Content Credentials | Improper Certificate Validation (CWE-295)

CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue does not require user interaction.

CVSS 3.1 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Adobe
Products
C2pa C2pa-web C2patool and 2 more
CVE-2026-122098

CAI Content Credentials | Improper Certificate Validation (CWE-295)

CAI Content Credentials is affected by an Improper Certificate Validation vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue does not require user interaction.

CVSS 3.1 · 5.1 Medium EPSS < 1% KEV · Not listed
Vendors
Adobe
Products
C2patool Content Credentials Rust Sdk
CVE-2026-123867

Node.js is vulnerable to a per-host mTLS authorization bypass via a CA-only SNI context failing open to the default CA

A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different client-certificate CA with `server.addContext(host, { ca: protectedCA })` but no server certificate in that SNI context, the per-host client CA is never installed and the handshake falls back to the default client CA. In `src/crypto/crypto_tls.cc`, `CertCbDone` installs the SNI context's CA only when `setSniContext` succeeds, but `setSniContext` returns `false` for a context with no server certificate, so a CA-only SNI context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not the protected CA, can therefore complete mTLS to the protected hostname and read its response even with `requestCert` and `rejectUnauthorized` enabled, while a client certified by the protected CA is rejected. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

CVSS 3.1 · 4.2 Medium EPSS < 1% KEV · Not listed
Vendors
Nodejs
Products
Nodejs
CVE-2026-123877

Node.js is vulnerable to a certificate validation bypass in https.Agent via cross-policy TLS session reuse

A certificate validation bypass in Node.js https.Agent lets a cached TLS session authenticated under one CA policy be reused by a later request with a stricter policy. https.Agent.prototype.getName() assigns the same Agent and session-cache key to a request that omits ca and one that explicitly supplies ca: [], because an omitted value appends nothing to the key while an empty array stringifies to an empty string. The two policies differ: omitting ca uses the default trust store, while supplying ca replaces it. Since they share a key, a TLS session authenticated under the broader default policy is handed to a new connection made under the later ca: [] policy, and TLS 1.3 session resumption carries the earlier authentication forward, so the second request reports authorized === true and transmits confidential data to a server its own CA policy would reject on a fresh connection. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

CVSS 3.1 · 6.8 Medium EPSS < 1% KEV · Not listed
Vendors
Nodejs
Products
Nodejs
CVE-2026-123872

Node.js is vulnerable to a client certificate authentication bypass via TLS 1.2 renegotiation servername change

A client certificate authentication bypass in Node.js TLS lets a client change the servername during TLS 1.2 renegotiation to reach endpoints it was not authorized for. On a server that applies different client-certificate policies per hostname, for example stricter admin-only client-cert auth on one host and ordinary client-cert auth on another, a client that authenticates for a permitted host can renegotiate the TLS 1.2 connection under a different servername and carry its existing authentication to the protected host, bypassing the stricter policy. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

CVSS 3.1 · 8.1 High EPSS < 1% KEV · Not listed
Vendors
Nodejs
Products
Nodejs
CVE-2026-19552

ssl.get_server_certificate(addr, ca_certs=...) verifies the chain but never the identity

When ca_certs parameter was supplied to ssl.get_server_certificate() function, the identity of the certificate is not checked.

CVSS 4.0 · 0 Low EPSS < 1% KEV · Not listed
Vendors
Python Python Software Foundation
Products
Cpython Cpython
CVE-2026-121688

CVE-2026-121688

FrodoBots EarthRover Mini+ firmware (version 6.2.4_6.2.5_0.614.0) contains an insecure STM32 firmware update mechanism. The STM32 motor‑controller firmware is fetched over unencrypted HTTP. Integrity is validated only via MD5, with the hash provided in the same unprotected response. No code‑signing mechanism is implemented, allowing firmware to be replaced with potentially malicious code.

CVSS 3.1 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
Frodobots
Products
Frodobots Earthrover Mini+ Firmware
CVE-2026-120808

Certificate Validation Bypass via IPv6 trust-result skip in macOS TLS client

An issue exists in MongoDB's macOS TLS client implementation where certificate chain-of-trust validation is bypassed for outbound connections to IPv6-addressed peers. When a MongoDB process using the Apple SecureTransport TLS backend connects to an IPv6 target, the trust evaluation result from SecTrustEvaluate is silently discarded, regardless of whether the peer's certificate is trusted. An on-path party could exploit this by presenting a self-signed certificate containing the target's IPv6 address in the Subject Alternative Name to intercept and modify encrypted inter-node or external service traffic. This issue only affects MongoDB processes running on macOS with the Apple SecureTransport TLS provider.

CVSS 4.0 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
Mongodb
Products
Mongodb Server
CVE-2026-15554

Undertow-core: undertow: authentication bypass via ajp ssl_cert/is_ssl forgery

the Undertow AJP listener honours forged ssl_cert and is_ssl AJP attributes without requiring any shared-secret authentication. This enables an unauthenticated attacker with direct TCP access to port 8009 to bypass CLIENT-CERT authentication by injecting a forged X.509 certificate via the AJP protocol.

CVSS 3.1 · 7.4 High EPSS < 1% KEV · Not listed
Vendors
Redhat
Products
Jboss Enterprise Application Platform Jboss Enterprise Application Platform Els Jboss Enterprise Application Platform Expansion Pack and 1 more
CVE-2026-32144

OCSP designated-responder authorization bypass via missing signature verification

Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_ocsp module) allows OCSP designated-responder authorization bypass via missing signature verification. The OCSP response validation in public_key:pkix_ocsp_validate/5 does not verify that a CA-designated responder certificate was cryptographically signed by the issuing CA. Instead, it only checks that the responder certificate's issuer name matches the CA's subject name and that the certificate has the OCSPSigning extended key usage. An attacker who can intercept or control OCSP responses can create a self-signed certificate with a matching issuer name and the OCSPSigning EKU, and use it to forge OCSP responses that mark revoked certificates as valid. This affects SSL/TLS clients using OCSP stapling, which may accept connections to servers with revoked certificates, potentially transmitting sensitive data to compromised servers. Applications using the public_key:pkix_ocsp_validate/5 API directly are also affected, with impact depending on usage context. This vulnerability is associated with program files lib/public_key/src/pubkey_ocsp.erl and program routines pubkey_ocsp:is_authorized_responder/3. This issue affects OTP from OTP 27.0 before OTP 27.3.4.10 and OTP 28.4.2, corresponding to public_key from 1.16 before 1.17.1.2 and 1.20.3, and ssl from 11.2 before 11.2.12.7 and 11.5.4.

CVSS 4.0 · 7.6 High EPSS < 1% KEV · Not listed
Vendors
Erlang
Products
Erlang/otp Erlang\/otp Erlang\/public Key and 2 more
CVE-2026-42790

nameConstraints DNS bypass via subject CommonName fallback in public_key hostname verification

Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification. Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com): First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName. Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback. The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https hostname matcher. This issue affects OTP from OTP 19.3 before OTP 26.2.5.21, OTP 27.3.4.12, OTP 28.5.0.1, and OTP 29.0.1, corresponding to public_key from 1.4 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.

CVSS 4.0 · 7.6 High EPSS < 1% KEV · Not listed
Vendors
Erlang
Products
Erlang/otp Erlang\/otp Otp
CVE-2026-42791

OCSP responder certificate validity period not checked in public_key

Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_ocsp module) allows forged OCSP responses signed with an expired responder certificate to be accepted as valid. OCSP response verification in pubkey_ocsp:verify_response/5 and pubkey_ocsp:is_authorized_responder/3 in lib/public_key/src/pubkey_ocsp.erl does not check the validity period (notBefore/notAfter) of the OCSP responder certificate. An attacker who has obtained the private key of an expired CA-designated OCSP responder certificate can forge OCSP responses that Erlang/OTP accepts as valid. This affects TLS clients using OCSP stapling via the ssl application: a malicious or compromised server can present a revoked TLS certificate together with a forged OCSP response signed by an expired responder key, and the client will accept the revoked certificate as valid. It also affects applications calling public_key:pkix_ocsp_validate/5 directly, where the impact depends on the use case — server-side client certificate validation using this API may allow authentication bypass with a revoked client certificate. This issue affects OTP from OTP 27.0 before OTP 27.3.4.12, OTP 28.5.0.1, and OTP 29.0.1, corresponding to public_key from 1.16 before 1.17.1.3, 1.20.3.1, and 1.21.1.

CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Vendors
Erlang
Products
Erlang/otp Erlang\/otp Otp
CVE-2026-64855

soapbar: verify_envelope_bsp accepts an unauthenticated embedded certificate (signature forgery / authentication bypass)

soapbar is a SOAP library for Python — client, server, and WSDL handling. Prior to version 0.13.0, verify_envelope_bsp() derived its trust anchor from the message it was verifying. It read the X.509 certificate out of the caller-untrusted wsse:BinarySecurityToken, validated only that certificate's not-before / not-after dates, and then verified the signature against that same certificate. There was no CA-chain validation, no issuer/subject allowlist, and no pinning. A successful verify_envelope_bsp() therefore proved only that the envelope was signed by whoever supplied the embedded certificate — never that it was signed by a trusted party. An attacker who mints their own certificate, signs a forged envelope, and embeds that certificate in the token passes verification. Any consumer that treats a successful BSP verification as authentication can be impersonated (signature forgery / authentication bypass). verify_envelope() (which pins a caller-supplied x509_cert) was not affected — the flaw was specific to the BSP variant whose trust anchor came from the message. This issue has been patched in version 0.13.0.

CVSS 3.1 · 8.2 High EPSS < 1% KEV · Not listed
Vendors
—
Products
—
CVE-2026-42013

Gnutls: gnutls: certificate validation bypass due to oversized subject alternative name

A flaw was found in gnutls. When validating certificates, an oversized Subject Alternative Name (SAN) could cause the validation process to incorrectly fall back to checking the Common Name (CN) field. This could allow a remote attacker to bypass proper certificate validation, potentially leading to spoofing or man-in-the-middle attacks.

CVSS 3.1 · 8.2 High EPSS < 1% KEV · Not listed
Vendors
Gnu Redhat
Products
Gnutls Cert Manager Discovery and 14 more