Search vulnerabilities

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

Results 127

Export CSV
CVE-2026-129117

C-Kermit 8.0.200 before 11.1.515 Missing Hostname Verification in AUTHENTICATION SSL

C-Kermit 8.0.200 before 11.1.515 contains an improper certificate validation vulnerability that allows machine-in-the-middle attackers to impersonate Telnet servers because ssl_reply() never calls ssl_check_server_name(). Attackers can refuse START-TLS, offer Telnet AUTHENTICATION SSL, and present any trusted CA certificate to capture user credentials and session data.

CVSS 4.0 · 7.6 High EPSS n/a KEV · Not listed
Vendors
—
Products
—
CVE-2026-129118

C-Kermit 8.0.200 before 11.1.515 Improper Certificate Hostname Matching via dNSName_cmp

C-Kermit 8.0.200 before 11.1.515 contains an improper certificate hostname validation vulnerability that allows attackers to impersonate hosts by abusing wildcard matching in dNSName_cmp() in ck_ssl.c. Attackers holding a trusted certificate with over-matching names containing asterisks, question marks, brackets, or empty labels can intercept credentials and data over Telnet, FTP, and HTTP TLS connections.

CVSS 4.0 · 7.6 High EPSS n/a KEV · Not listed
Vendors
—
Products
—
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-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-112339

Wazuh 3.9.0 before 4.14.9 Missing TLS Hostname Verification in fluent-forward Module

Wazuh from 3.9.0 before 4.14.9 contains a missing TLS hostname verification vulnerability in the fluent-forward module's wm_fluent_ssl_ctx() that allows network attackers to impersonate the Fluentd collector by presenting any certificate chaining to the configured ca_file. Attackers who redirect the connection via DNS, ARP, or on-path positions can receive forwarded security telemetry and the shared_key_hexdigest for offline cracking.

CVSS 4.0 · 8.2 High EPSS < 1% KEV · Not listed
Vendors
Wazuh
Products
Wazuh
CVE-2026-123848

Missing Host Name Verification in JetBrains IntelliJ IDEA TLS Connections

In JetBrains IntelliJ IDEA before 2026.3 host name verification was missing for server TLS certificates

CVSS 3.1 · 7.4 High EPSS < 1% KEV · Not listed
Vendors
Jetbrains
Products
Intellij Idea
CVE-2026-87758

Apache TomEE: Missing TLS hostname verification in ejbds client connections

The remote EJB client does not verify that the hostname of the server it connects to matches the server's TLS certificate. An attacker able to intercept network traffic between an EJB client and server can impersonate the server and read or modify the traffic, including credentials and invocation data. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.

CVSS n/a EPSS < 1% KEV · Not listed
Vendors
—
Products
—
CVE-2026-19553

SSLContext.wrap_bio() missing validation of server_hostname parameter

ssl.SSLContext.wrap_bio() didn't require the server_hostname argument to not be None if ssl.SSLContext.check_hostname was set. Due to a missing parameter check in SSLObject, if the server_hostname argument isn't supplied then hostname verification would be silently skipped. This defect could lead to programs where certificate hostname verification *appeared* to be succeeding with SSLContext.check_hostname = True and no ValueError being raised due to misconfiguration. If the program passes a server_hostname value that isn't an empty string or None to any of these APIs then certificate hostname verification proceeds as expected and the program is not affected by this vulnerability. Mitigating this vulnerability doesn't require updating Python or applying the patch. To mitigate, pass a valid non-None and non-empty server_hostname value to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls() and certificate hostname verification will proceed as expected. Upgrading to the latest version of Python or applying the patch only changes the behavior from silently skipping hostname verification to raising a ValueError, similar to SSLContext.wrap_socket(), when server_hostname isn't supplied.

CVSS 4.0 · 7.6 High EPSS < 1% KEV · Not listed
Vendors
Python
Products
Cpython
CVE-2026-115758

SumatraPDF: TLS hostname validation disabled in `HttpGet()`

SumatraPDF is a multi-format reader for Windows. In version 3.6.1 and earlier, HttpGet() in src/base/Http_win.cpp unconditionally passes INTERNET_FLAG_IGNORE_CERT_CN_INVALID to WinINet, disabling hostname matching for HTTPS update metadata and crash-symbol requests while retaining certificate-chain validation. A network-positioned attacker with a Windows-trusted certificate for an attacker-controlled domain can impersonate the project's update host, inject promo text and a clickable URL before update metadata validation, and provide an attacker-controlled archive to ExtractSymbols(). Installer replacement is not directly possible because HttpGetToFile() validates TLS and MaybeStartUpdateDownload() restricts the download host. No fixed version is available as of this review.

CVSS 4.0 · 8.2 High EPSS < 1% KEV · Not listed
Vendors
Sumatrapdfreader
Products
Sumatrapdf
CVE-2026-109408

vault-java-driver: SslConfig silently disables requested TLS verification

vault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than "true", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0.

CVSS 3.1 · 7.4 High EPSS < 1% KEV · Not listed
Vendors
Jopenlibs
Products
Vault-java-driver
CVE-2026-117666

ssl_verify_fun: partial-label wildcard certificate matches hostnames across a label boundary

Improper Validation of Certificate with Host Mismatch vulnerability in deadtrickster ssl_verify_fun allows an adversary in the middle to impersonate a TLS peer via a certificate that carries a partial-label wildcard. try_match_wildcard/4 in src/ssl_verify_hostname.erl anchors only the text before and after the * of an identifier such as f*.example.net, so the wildcard also consumes dots and the certificate is accepted for f.evil.example.net. RFC 6125 confines a wildcard to the left-most label. The same matcher lets *.168.1.1 match the IP literal 192.168.1.1. Whole-label wildcards are matched correctly. Erlang/OTP 20.0 and later check the hostname in ssl before a user verify_fun sees valid_peer, so a client that keeps server_name_indication set rejects the mismatch regardless. Exposed are clients that disable SNI, servers that verify client certificate hostnames with this library, and direct callers of verify_cert_hostname/2. This issue affects ssl_verify_fun: from 1.0.1 before 1.1.8.

CVSS 4.0 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
Deadtrickster
Products
Ssl Verify Fun
CVE-2026-88647

gnutls: gnutls: Information disclosure via hostname verification bypass

GnuTLS v3.8.13 can perhaps unexpectedly trust a certificate on the basis of Common Name when Subject Alternative Name has an SRV otherName (1.3.6.1.5.5.7.8.7) whose value is an OCTET STRING. NOTE: the Supplier does not consider this an actionable security vulnerability because of its "threat model doesn't consider attacks only possible by modifying anything within the trust boundary (private keys, trusted certificate authorities and their issued certificates including intermediate CAs, etc.)" policy.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed
Vendors
Gnu
Products
Gnutls
CVE-2026-105483

nodejs: nodejs: TLS certificate hostname bypass via fullwidth-digit IP hostnames

A flaw in Node.js TLS hostname verification allows a certificate without a matching IP address SAN to authenticate a connection to an IPv4 address when the host is written with non-ASCII characters, such as fullwidth digits (`１２７.0.0.1`). `tls.checkServerIdentity()` did not recognize such hosts as IP addresses, even though they normalize and resolve to a regular IPv4 address, and matched them against the certificate DNS names and Common Name instead. A certificate containing `DNS:127.0.0.1` or `DNS:*.0.0.1` could therefore be accepted for an IP endpoint it was not issued for. This is a regression introduced after the fix for CVE-2026-48618. This vulnerability affects Node.js **26.x** and **24.x**.

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

nodejs: nodejs: TLS certificate hostname bypass via non-canonical IP hostnames

A flaw in Node.js TLS hostname verification can cause a server certificate to be validated against a different IP address than the one the client connected to, when the host is a non-canonical IPv4 literal with a leading zero, such as `0127.0.0.1`. `tls.checkServerIdentity()` normalizes the host following the WHATWG URL rules, which read a leading-zero octet as octal (`0127.0.0.1` becomes `87.0.0.1`), while the connection is made through the operating system resolver, which on some platforms such as macOS reads it as decimal (`127.0.0.1`). A server at the connected address can then be authenticated with a certificate issued for another IP address. This vulnerability affects Node.js **26.x**, **24.x**, and **22.x**.

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

Apache bRPC: TLS Client Accepts Certificates for Mismatched Peer Names

Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint. Affected Scenarios: Applications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint. How to Fix: Upgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from https://github.com/apache/brpc/pull/3408 . Note: The new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected.

CVSS 3.1 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Apache
Products
Brpc
CVE-2026-86410

redirect to SFTP or SCP bypasses host verification

A flaw in the curl command line tool's logic makes it only set SSH host verification options when interacting directly using SFTP or SCP, and not as a result of following a redirect.

CVSS 3.1 · 8.1 High EPSS < 1% KEV · Not listed
Vendors
Curl Redhat
Products
Curl Hummingbird
CVE-2026-91769

TLS Hostname Verification Falls Back to CN After SAN Mismatch

PHP's OpenSSL stream peer verification checks the certificate's subjectAltName entries first and, whenever no entry matches, falls back to the Common Name. RFC 6125 requires the CN to be ignored once the certificate presents any service identity, so a certificate carrying a non-matching DNS SAN was still accepted when its CN matched the requested peer_name. A certificate trusted by the client for one name can therefore be used to impersonate another.

CVSS 3.1 · 4.3 Medium EPSS < 1% KEV · Not listed
Vendors
Php Php Group Redhat
Products
Php Php Hummingbird
CVE-2026-84975

PJSIP: TLS server identity (hostname) verification bypass via embedded NUL in certificate SubjectAltName (OpenSSL and GnuTLS backends)

PJSIP is a free and open source multimedia communication library written in C. In 2.17 and earlier, the OpenSSL and GnuTLS backends in pjlib/src/pj/ssl_sock_ossl.c and pjlib/src/pj/ssl_sock_gtls.c copy DNS SubjectAltName values with string functions that recalculate their length and truncate an embedded NUL byte. With server verification enabled through --tls-verify-server for the PJSIP TLS/SIPS transport, a certificate containing a DNS SubjectAltName formed from the target hostname prefix followed by an embedded NUL and an attacker-controlled suffix can therefore be accepted for the prefix hostname. An attacker who possesses such a certificate from a trusted issuer and can intercept the connection can impersonate the target server, complete the SIP session, and receive REGISTER credentials. The mbedTLS backend is not affected because it preserves the explicit string length. No fixed version is available as of this review.

CVSS 3.1 · 7.4 High EPSS < 1% KEV · Not listed
Vendors
Pjsip Teluu
Products
Pjproject Pjsip
CVE-2026-107938

Apache CXF: The Netty HTTP client transport does not perform TLS hostname verification.

In Apache CXF, the Netty-based HTTP client transport (cxf-rt-transports-http-netty-client) did not verify that the hostname in the server’s TLS certificate matched the host being called. This applied over both HTTP/1.1 and HTTP/2, even when disableCNCheck was left at its default value of false. The certificate chain was validated against the configured trust store, but the endpoint’s identity was not. A network attacker able to intercept traffic could present any certificate trusted by the client, such as a publicly issued certificate for a domain they control, and impersonate the target service. They could then read or modify the exchanged messages, including credentials.  Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.

CVSS 3.1 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
Apache
Products
Cxf
CVE-2026-84393

Improper Certificate Host Validation Allows Information Disclosure

A improper validation of certificate with host mismatch vulnerability in Fortinet FortiOS 7.6.1 through 7.6.6, FortiProxy 7.6.2 through 7.6.6 may allow attacker to information disclosure via <insert attack vector here>

CVSS 3.1 · 7.3 High EPSS < 1% KEV · Not listed
Vendors
Fortinet
Products
Fortios Fortiproxy