Export limit exceeded: 26397 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (92 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-62243 | 1 Netty | 1 Netty | 2026-08-22 | 7.5 High |
| Netty (io.netty:netty-handler) versions from 4.2.0.Final through 4.2.16.Final and versions through 4.1.136.Final disable TLS hostname verification on the SslProvider.OPENSSL client path when a plain (non-extended) X509TrustManager is used and Unsafe-based trust-manager wrapping is unavailable (Java 25+). In this configuration the OpenSSL client does not perform hostname verification, allowing a man-in-the-middle attacker to present a certificate issued for a different hostname that is accepted without validation. Fixed in 4.2.17.Final and 4.1.137.Final. | ||||
| CVE-2026-53583 | 1 Libgit2 | 1 Libgit2 | 2026-08-20 | 6.5 Medium |
| libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Prior to 1.8.6 and 1.9.5, verify_server_cert in src/libgit2/streams/openssl.c uses an inverted !!memcmp result in the GEN_IPADD branch when comparing an IP-literal host with a certificate IP SubjectAltName. OpenSSL builds reject matching IP addresses and accept mismatched IP addresses, allowing a network attacker with a CA-trusted certificate containing any IP SubjectAltName to intercept libgit2 connections to IP-literal HTTPS URLs. DNS SubjectAltName validation and non-OpenSSL TLS backends are not affected. This issue is fixed in versions 1.8.6 and 1.9.5. | ||||
| CVE-2026-11751 | 1 Ly Corporation | 1 Armeria | 2026-08-20 | N/A |
| A vulnerability has been identified in armeria-xds versions prior to 1.41.0, where xDS upstream TLS peer verification may be silently disabled, allowing man-in-the-middle attacks against xDS-managed upstream connections. | ||||
| CVE-2026-65942 | 1 Apache | 1 Ranger | 2026-08-17 | 7.5 High |
| TLS hostname verification issue in Apache Ranger Client Code in versions <= 2.8.0. Users are recommended to upgrade to version 2.9.0, which fixes this issue. | ||||
| CVE-2026-49457 | 1 Benoitc | 1 Erlang Quic | 2026-08-17 | 9.1 Critical |
| erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify => false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify => true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents. | ||||
| CVE-2026-44393 | 1 Openstack | 1 Oslo.messaging | 2026-08-14 | 7.4 High |
| An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When ssl_ca_file is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected. | ||||
| CVE-2026-42790 | 1 Erlang | 3 Erlang/otp, Erlang\/otp, Otp | 2026-08-14 | 8.1 High |
| 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 29.0.1, OTP 28.5.0.1, OTP 27.3.4.12 and OTP 26.2.5.21, corresponding to public_key from 1.4 before 1.21.1, 1.20.3.1, 1.17.1.3 and 1.15.1.7. | ||||
| CVE-2026-12730 | 1 Ibm | 2 Business Automation Workflow, Business Automation Workflow Containers And Traditional | 2026-08-05 | 3.8 Low |
| IBM Business Automation Workflow containers and traditional 26.0.0, 25.0.0 through 25.0.0 Interim Fix 005, 24.0.1 through 24.0.1 Interim Fix 007, and 24.0.0 through 24.0.0 Interim Fix 009 IBM Business Automation Workflow fails to properly verify that the hostname matches the server certificate potentially allowing connections to an attacker-controlled server. | ||||
| CVE-2026-48145 | 1 Apache | 1 Thrift | 2026-08-03 | 7.5 High |
| Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift C++ bindings. This issue affects Apache Thrift: before 0.24.0. Users are recommended to upgrade to version 0.24.0, which fixes the issue. | ||||
| CVE-2026-59638 | 1 Legion Of The Bouncy Castle Inc. | 3 Bc-fja, Bc-java, Bc-lts-java | 2026-08-03 | N/A |
| In Bouncy Castle for Java before 1.85, JSSE hostname verifier CN-fallback enabled by default despite documented opt-in. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bctls-fips 1.0.24 (1.0.X series), 2.0.24 (2.0.X series) and 2.1.24 (2.1.X series). | ||||
| CVE-2026-58040 | 2 Nodejs, Redhat | 2 Nodejs, Hummingbird | 2026-08-03 | 6.3 Medium |
| An incomplete fix has been identified in Node.js: HTTPS Agent TLS session reuse skips hostname verification across identity policies (incomplete fix of CVE-2026-48934). This vulnerability affects Node.js **22.x**, **24.x**, and **26.x**. | ||||
| CVE-2026-47840 | 1 Cloudfoundry | 2 Cf-deployment, Uaa | 2026-08-03 | 7.5 High |
| A network attacker positioned between UAA and its LDAP directory can impersonate the directory using any certificate from any trusted CA, then harvest the LDAP bind password and every end-user password sent during simple-bind authentication, and return forged group memberships that grant themselves admin scopes. This affects every deployment that authenticates users against LDAP over StartTLS. Affected versions: UAA versions prior to v78.13.0; Cf-deployment versions prior to v56.2.0. | ||||
| CVE-2026-15925 | 1 Snowflake | 1 Snowflake-connector-python | 2026-08-02 | 7.4 High |
| Improper TLS hostname verification in Snowflake Connector for Python versions prior to 4.7.1 and 3.18.1 may have allowed a network-positioned attacker to bypass certificate hostname validation on HTTPS connections made by the connector. An attacker with on-path network access could exploit this by intercepting or redirecting network traffic and presenting a certificate signed by any trusted CA for any domain, causing the connector to accept connections without validating that the certificate matched the requested hostname. Successful exploitation requires an on-path traffic interception capability (e.g. ARP/DNS poisoning, rogue access point, BGP hijacking, or malicious proxy/exit node). This vulnerability may have exposed credentials, query data, and staged file contents to interception and tampering, and may have enabled the attacker to issue arbitrary SQL within the context of the victim's connector session. Impact is limited by the privileges of the affected Snowflake role. The fix is available in Snowflake Connector for Python versions 4.7.1 and 3.18.1. Users must manually upgrade. | ||||
| CVE-2026-15243 | 1 Apereo | 2 Jasig Cas Client, Java Cas Client | 2026-07-27 | N/A |
| Apereo CAS Client accepts any CA-trusted certificate for any hostname, provided the URL the client is calling matches the configured allowlist or regex. An attacker with a MITM position (DNS poisoning, rogue Wi-Fi, malicious proxy, etc.) can provide any CA-signed certificate for a hostname that matches the configured allowlist or regex. This can lead to intercepting the CAS exchange, capturing the Ticket-Granting Ticket (TGT), and subsequently obtaining Service Tickets on behalf of the victim. Because maintainers contact attempts were unsuccessful, vulnerabilities have only been confirmed in version 4.1.0 (Java Apereo CAS Client) and 3.6.4 (Jasig CAS Client) but may also affect other versions. | ||||
| CVE-2026-48144 | 1 Apache | 1 Thrift | 2026-07-27 | 9.1 Critical |
| Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift c_glib bindings. This issue affects Apache Thrift: before 0.24.0. Users are recommended to upgrade to version 0.24.0, which fixes the issue. | ||||
| CVE-2026-66053 | 1 Apache | 1 Thrift | 2026-07-27 | 5.9 Medium |
| Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift Python bindings. This issue affects Apache Thrift: before 0.24.0. Users are recommended to upgrade to version 0.24.0, which fixes the issue. This replaces CVE-2026-41603 | ||||
| CVE-2026-54275 | 2 Aio-libs, Aiohttp | 2 Aiohttp, Aiohttp | 2026-06-22 | 7.5 High |
| AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, the server_hostname TLS SNI check can be bypassed when an existing connection is reused. If an application makes multiple requests to the same domain, but with different per-request server_hostname parameters, then the later calls may succeed by reusing the existing connection when they should have been rejected due to the TLS SNI check. This vulnerability is fixed in 3.14.1. | ||||
| CVE-2026-12162 | 1 Devolutions | 1 Remote Desktop Manager | 2026-06-18 | 5.5 Medium |
| Improper host validation in the social login autofill feature in Devolutions Remote Desktop Manager 2026.2.8 allows an attacker to disclose stored social login credentials via a crafted web entry pointing to a provider lookalike domain. | ||||
| CVE-2025-25253 | 1 Fortinet | 3 Fortios, Fortipam, Fortiproxy | 2026-06-09 | 6.8 Medium |
| An Improper Validation of Certificate with Host Mismatch vulnerability [CWE-297] in FortiProxy version 7.6.1 and below, version 7.4.8 and below, 7.2 all versions, 7.0 all versions and FortiOS version 7.6.2 and below, version 7.4.8 and below, 7.2 all versions, 7.0 all versions ZTNA proxy may allow an unauthenticated attacker in a man-in-the middle position to intercept and tamper with connections to the ZTNA proxy | ||||
| CVE-2025-4295 | 2026-06-05 | 4.6 Medium | ||
| Improper Validation of Certificate with Host Mismatch vulnerability in HotelRunner B2B allows HTTP Response Splitting. This issue affects B2B: before 04.06.2025. | ||||