Export limit exceeded: 14496 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1397 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-42213 | 2026-05-08 | N/A | ||
| SolidCAM-GPPL-IDE is an unofficial, independently developed extension, Postprocessor IDE for SolidCAM. From version 1.0.0 to before version 1.0.2, the inc "filename" directive in GPPL postprocessor files is resolved by GpplDocumentLinkHandler into a clickable link (VS Code textDocument/documentLink). The handler accepted arbitrary paths — absolute, relative with parent-directory segments (..\..\..\), UNC (\\server\share\), and arbitrary subfolders — and called File.Exists on each to decide whether to render the link. Two distinct attack surfaces resulted: information disclosure via File.Exists probing and NTLM hash leak via UNC path probing. This issue has been patched in version 1.0.2. | ||||
| CVE-2026-40243 | 2 Linuxcontainers, Lxc | 2 Incus, Incus | 2026-05-08 | 4.8 Medium |
| Incus is a system container and virtual machine manager. In versions before 7.0.0, broken TLS validation logic in the OVN database connection logic can allow connections to an attacker's OVN database. The OVN client implementations disable Go standard TLS server verification and replace it with custom peer-certificate verification logic. That replacement verifier does not anchor trust in the configured CA certificate. Instead, it constructs the verification root set from certificates supplied by the peer during the handshake, so the configured CA is parsed but not used as the trust anchor for the final verification decision. In OVN-enabled deployments that use these SSL database connection paths, an attacker able to impersonate or intercept the OVN endpoint on the management network can present a rogue self-signed certificate chain, and Incus will accept this certificate as valid. This issue defeats the intended CA-based trust model for OVN database connections and permits endpoint impersonation by an active attacker in a suitable network position. This issue is fixed in version 7.0.0. | ||||
| CVE-2026-42225 | 1 Pjsip | 1 Pjproject | 2026-05-08 | N/A |
| PJSIP is a free and open source multimedia communication library written in C. Prior to version 2.17, on GnuTLS builds, the SIP TLS transport (sip_transport_tls) can accept connections with invalid or untrusted certificates even when the application explicitly enables certificate verification via verify_server = PJ_TRUE or verify_client = PJ_TRUE. This issue has been patched in version 2.17. | ||||
| CVE-2026-42011 | 1 Redhat | 5 Enterprise Linux, Hardened Images, Hummingbird and 2 more | 2026-05-07 | 7.4 High |
| A flaw was found in gnutls. This vulnerability occurs because permitted name constraints were incorrectly ignored when previous Certificate Authorities (CAs) only had excluded name constraints. A remote attacker could exploit this to bypass critical name constraint checks during certificate validation. This bypass could lead to the acceptance of invalid certificates, potentially enabling spoofing or man-in-the-middle attacks against affected systems. | ||||
| CVE-2026-5787 | 1 Ivanti | 1 Endpoint Manager Mobile | 2026-05-07 | 8.9 High |
| An Improper Certificate Validation in Ivanti EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1 allows a remote unauthenticated attacker to impersonate registered Sentry hosts and obtain valid CA-signed client certificates. | ||||
| CVE-2026-7821 | 1 Ivanti | 1 Endpoint Manager Mobile | 2026-05-07 | 7.4 High |
| Improper certificate validation in Ivanti EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1 allows a remote unauthenticated attacker to enroll a device belonging to a restricted set of unenrolled devices, leading to information disclosure about EPMM appliance and impacting on the integrity of the newly enrolled device identity. | ||||
| CVE-2026-34477 | 1 Apache | 1 Log4j | 2026-05-06 | 5.9 Medium |
| The fix for CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName attribute of the <Ssl> element. Although the verifyHostName configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value. A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met: * An SMTP, Socket, or Syslog appender is in use. * TLS is configured via a nested <Ssl> element. * The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured. This issue does not affect users of the HTTP appender, which uses a separate verifyHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName attribute that was not subject to this bug and verifies host names by default. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue. | ||||
| CVE-2026-6860 | 1 Eclipse | 1 Vert.x | 2026-05-06 | N/A |
| A TCP client can perform a TLS handshake and present the server name extension with a server name that is accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting *.example.com, any XYZ.example.com where xyz is a valid name can be used. | ||||
| CVE-2026-40557 | 1 Apache | 1 Storm Prometheus Reporter | 2026-05-05 | 4.8 Medium |
| Improper Certificate Validation via Global SSL Context Downgrade in Apache Storm Prometheus Reporter Versions Affected: from 2.6.3 to 2.8.6 Description: In production deployments where an administrator enables storm.daemon.metrics.reporter.plugin.prometheus.skip_tls_validation (by default it is disabled) intending to affect only the Prometheus reporter, the undocumented global side effect creates an attack surface across every TLS-protected communication channel in the Storm daemon. The PrometheusPreparableReporter class implements an INSECURE_TRUST_MANAGER that accepts all SSL certificates without validation, with empty checkClientTrusted and checkServerTrusted methods. Most critically, when the storm.daemon.metrics.reporter.plugin.prometheus.skip_tls_validation configuration option is enabled (default = disabled) for HTTPS Prometheus PushGateway connections, the INSECURE_CONNECTION_FACTORY calls SSLContext.setDefault(sslContext), which globally replaces the JVM's default SSL context rather than applying the insecure context only to the Prometheus connection. This payload flows through storm.yaml configuration → PrometheusPreparableReporter.prepare() → INSECURE_CONNECTION_FACTORY → SSLContext.setDefault(), resulting in a JVM-wide TLS security downgrade. All subsequent HTTPS connections in the process - including ZooKeeper, Thrift, Netty, and UI connections - silently trust all certificates, including self-signed, expired, and attacker-generated ones, enabling man-in-the-middle interception of cluster state, topology submissions, tuple data, and administrative credentials. Mitigation: 2.x users should upgrade to 2.8.7 if the Prometheus Metrics Reporter is used. Prometheus Metrics Reporter Users who cannot upgrade immediately should remove the storm.daemon.metrics.reporter.plugin.prometheus.skip_tls_validation: true setting from their storm.yaml configuration and instead configure a proper truststore containing the PushGateway's certificate. | ||||
| CVE-2025-42611 | 1 Mikrotik | 1 Routeros | 2026-05-05 | 6.5 Medium |
| RouterOS provides various services that rely on correct verification of client and server certificates to secure confidentiality and integrity of communications. This includes OpenVPN, CAPsMAN, Dot1x (802.1X), among others. The vulnerability lies in shared certificate validation logic which uses the system certificate store that is shared and equally trusted by all system services. This causes confusion of scope, allowing any certificate authority present in the system-wide trust store to be trusted in any context (with some exceptions), allowing partial or full authentication bypass in CAPsMAN, OpenVPN, Dot1X and potentially others. | ||||
| CVE-2026-41016 | 1 Apache | 2 Airflow, Airflow Providers Smtp | 2026-05-01 | 5.9 Medium |
| Apache Airflow's SMTP provider `SmtpHook` called Python's `smtplib.SMTP.starttls()` without an SSL context, so no certificate validation was performed on the TLS upgrade. A man-in-the-middle between the Airflow worker and the SMTP server could present a self-signed certificate, complete the STARTTLS upgrade, and capture the SMTP credentials sent during the subsequent `login()` call. Users are advised to upgrade to the `apache-airflow-providers-smtp` version that contains the fix. | ||||
| CVE-2025-10539 | 1 Desktime | 1 Desktime Time Tracking App | 2026-04-29 | 4.8 Medium |
| Due to improper TLS certificate validation in the DeskTime Time Tracking App before version 1.3.674, attackers who can position themselves in the network path between the client and the DeskTime update servers can return a malicious executable in response to an update request. This allows the attacker to achieve user-level remote code execution on the affected client. | ||||
| CVE-2026-5263 | 1 Wolfssl | 1 Wolfssl | 2026-04-29 | 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-2025-68121 | 2 Go Standard Library, Golang | 2 Crypto Tls, Go | 2026-04-29 | 9.1 Critical |
| During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. | ||||
| CVE-2026-41603 | 1 Apache | 1 Thrift | 2026-04-29 | 7.4 High |
| Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift. This issue affects Apache Thrift: before 0.23.0. Users are recommended to upgrade to version 0.23.0, which fixes the issue. | ||||
| CVE-2026-4740 | 1 Redhat | 2 Advanced Cluster Management For Kubernetes, Multicluster Engine | 2026-04-28 | 8.2 High |
| A flaw was found in Open Cluster Management (OCM), the technology underlying Red Hat Advanced Cluster Management (ACM). Improper validation of Kubernetes client certificate renewal allows a managed cluster administrator to forge a client certificate that can be approved by the OCM controller. This enables cross-cluster privilege escalation and may allow an attacker to gain control over other managed clusters, including the hub cluster. | ||||
| CVE-2026-40974 | 1 Spring | 1 Spring Boot | 2026-04-28 | 5 Medium |
| Spring Boot's Cassandra auto-configuration does not perform hostname verification when establishing an SSL connection to Cassandra. Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14), 3.4.0–3.4.15 (fix 3.4.16), 3.3.0–3.3.18 (fix 3.3.19), 2.7.0–2.7.32 (fix 2.7.33); Cassandra SSL auto-configuration. Versions that are no longer supported are also affected per vendor advisory. | ||||
| CVE-2026-40971 | 1 Spring | 1 Spring Boot | 2026-04-28 | 5 Medium |
| When configured to use an SSL bundle, Spring Boot's RabbitMQ auto-configuration does not perform hostname verification when connecting to the RabbitMQ broker. Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14) per vendor advisory. | ||||
| CVE-2026-40970 | 1 Spring | 1 Spring Boot | 2026-04-28 | 5 Medium |
| When configured to use an SSL bundle, Spring Boot's Elasticsearch auto-configuration does not perform hostname verification when connecting to the Elasticsearch server. Affected: Spring Boot 4.0.0–4.0.5; upgrade to 4.0.6 or later per vendor advisory. | ||||
| CVE-2026-22747 | 2 Spring, Vmware | 2 Spring Security, Spring Security | 2026-04-28 | 6.8 Medium |
| Vulnerability in Spring Spring Security. SubjectX500PrincipalExtractor does not correctly handle certain malformed X.509 certificate CN values, which can lead to reading the wrong value for the username. In a carefully crafted certificate, this can lead to an attacker impersonating another user. This issue affects Spring Security: from 7.0.0 through 7.0.4. | ||||