Total
1566 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-15937 | 2026-09-08 | N/A | N/A | ||
| Improper certificate validation in Checkmk <2.5.0p10 allows a relay and a push agent that share the same UUID to reuse each other's mTLS certificate to authenticate against agent receiver endpoints in either direction, because the endpoints do not verify that the certificate was issued by their own root certificate. | |||||
| CVE-2026-66795 | 2026-09-08 | N/A | 9.9 CRITICAL | ||
| A flaw was found in the managedcluster-import-controller. The Certificate Signing Request (CSR) auto-approval logic improperly validates incoming CSRs, specifically by not inspecting the signer name or decoding the PEM-encoded x509 CSR. This vulnerability allows a privileged service account on a spoke cluster to submit a malicious CSR. Successful exploitation can lead to privilege escalation, enabling the attacker to obtain administrative credentials on the hub cluster. | |||||
| CVE-2026-4740 | 1 Redhat | 1 Advanced Cluster Management For Kubernetes | 2026-09-08 | N/A | 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-40992 | 1 Vmware | 1 Spring Boot | 2026-09-04 | N/A | 5.0 MEDIUM |
| Spring Boot's Mail auto-configuration does not enable hostname verification. Applications that set the relevant JavaMail property, such as spring.mail.properties.mail.smtp.ssl.checkserveridentity=true, are not affected. Affected versions: Spring Boot 4.0.0 through 4.0.6; 3.5.0 through 3.5.14; 3.4.0 through 3.4.16. | |||||
| CVE-2026-33896 | 1 Digitalbazaar | 1 Forge | 2026-09-04 | N/A | 7.4 HIGH |
| Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, `pki.verifyCertificateChain()` does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the `basicConstraints` and `keyUsage` extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid. Version 1.4.0 patches the issue. | |||||
| CVE-2026-84736 | 2026-09-03 | N/A | N/A | ||
| In the current development version of Eclipse aeriOS, for which no official release has yet been published, the Federator component disables TLS certificate validation for outbound HTTPS connections by default. When the TLS_CERTIFICATE_VALIDATION environment variable is unset or set to false, the component configures its HTTP transport to skip TLS certificate verification. As a result, an attacker able to intercept network communications between the Federator and external services could impersonate those services and intercept sensitive information transmitted over HTTPS, including OAuth client credentials and bearer tokens. The issue has been addressed by enabling TLS certificate validation by default. The TLS_CERTIFICATE_VALIDATION environment variable is now set to true in the default configuration provided by the Helm chart and Docker Compose deployment. | |||||
| CVE-2026-41012 | 2026-09-03 | N/A | 7.7 HIGH | ||
| Traffic interception vulnerability in BOSH Director vCenter CPI allows attackers positioned between BOSH Director and vCenter to impersonate vCenter REST API and capture administrator credentials via HTTP Basic auth, leading to complete virtualization infrastructure takeover. An attacker who can intercept traffic between the BOSH Director and vCenter can establish a malicious server impersonating the vCenter REST API. When the BOSH Director makes CPI calls to perform routine cloud infrastructure operations, the attacker captures the vCenter administrator username and password transmitted via HTTP Basic authentication. The vulnerability stems from insufficient authentication security in the communication protocol between BOSH Director and vCenter. While HTTPS may be used, the lack of proper certificate validation and pinning allows attackers to successfully impersonate vCenter endpoints. Because vCenter credentials typically grant full administrative control over the entire virtualization estate, successful credential capture yields complete takeover of every VM, datastore, and network the CPI manages. This exposure exists on every CPI call (including routine deployment operations, not just when tags are configured) and cannot be mitigated by supplying a CA certificate alone. The attack impacts all infrastructure managed by the compromised vCenter instance, potentially affecting hundreds or thousands of VMs across multiple deployments and environments. | |||||
| CVE-2026-82955 | 2026-09-03 | N/A | N/A | ||
| In the current development version of Eclipse aeriOS, which has not yet had an official release, the KrakenD instance included in the API Gateway component had the disable_jwk_security parameter hard-coded to true, with no option to override it through the Helm chart configuration. This setting disables TLS certificate verification when KrakenD retrieves the JSON Web Key Set (JWKS) used to validate bearer tokens, potentially allowing an attacker with the ability to intercept this communication to provide a malicious JWKS and compromise token validation. The issue has been addressed by making the parameter configurable through the boolean Helm value krakend.config.disableJwkSecurity and setting its default value to false, ensuring that TLS certificate verification is enabled by default. | |||||
| CVE-2026-82180 | 2026-09-03 | N/A | N/A | ||
| In Eclipse Arrowhead versions from 5.0.0 to 5.2.1 when the MQTT API is enabled with the certificate authentication policy, CertificateMqttFilter parses an X.509 certificate that the client sends inside the MQTT message payload (the authentication field of MqttRequestTemplate) and treats its Subject DN as the authenticated identity. The certificate is decoded with CertificateFactory.generateCertificate() but its signature is never verified and its issuer chain is never validated against any trust store. Authorisation is reduced to two string comparisons on attacker-supplied data: the DN-qualifier must equal "sy" or "op", and the cloud-name part of the CN must match the server's. Both values are public (the cloud name is in the server's own TLS certificate). An attacker who can publish to the MQTT broker can therefore mint a self-signed certificate with CN=Sysop.<cloud>.<org>.arrowhead.eu, dnQualifier=op, send it as the authentication field, and be authenticated as the cloud's system operator with isSysOp == true. This passes the downstream ManagementServiceMqttFilter (request.isSysOp() → allowed) and gives full management access over MQTT. The HTTP CertificateFilter is not affected — it reads the certificate from jakarta.servlet.request.X509Certificate, which Tomcat populates only after a successful mTLS handshake against the configured trust store. | |||||
| CVE-2026-0872 | 2026-09-03 | N/A | N/A | ||
| Improper Certificate Validation vulnerability in Thales SafeNet Agent for Windows Logon on Windows allows Signature Spoofing by Improper Validation. This issue affects SafeNet Agent for Windows Logon: 4.0.0, 4.1.1, 4.1.2. | |||||
| CVE-2026-42013 | 2026-09-03 | N/A | 8.2 HIGH | ||
| 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. | |||||
| CVE-2026-42011 | 2026-09-03 | N/A | 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-58062 | 1 Bouncycastle | 3 Bc-java, Bouncy Castle For Java Lts, Fips Java Api | 2026-09-02 | N/A | 9.1 CRITICAL |
| In Bouncy Castle for Java before 1.85, Stapled OCSP response accepted without binding to the checked certificate. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series). | |||||
| CVE-2026-8763 | 1 Bouncycastle | 3 Bc-java, Bouncy Castle For Java Lts, Fips Java Api | 2026-09-02 | N/A | 9.1 CRITICAL |
| In Bouncy Castle for Java before 1.85, Name Constraints bypass via trailing dot in rfc822Name and URI. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series). | |||||
| CVE-2025-36290 | 1 Ibm | 1 Integrated Analytics System | 2026-09-02 | N/A | 5.9 MEDIUM |
| IBM Integrated Analytics System 1.0.0.0 through 1.0.31.0 does not validate or improperly validates TLS certificate validation, which could allow an attacker to obtain sensitive information using man in the middle techniques. | |||||
| CVE-2025-64649 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-09-02 | N/A | 5.9 MEDIUM |
| IBM Concert 1.0.0 through 2.3.1 could allow a remote attacker to perform unauthorized actions using man in the middle techniques due to improper certificate validation. | |||||
| CVE-2026-0392 | 2026-09-01 | N/A | N/A | ||
| eParakstītājs 3.0 for Windows before version 1.10.0 retrieves and executes its automatic updates over a channel that is not authenticated or integrity-protected. On each launch the application fetches an update descriptor (XML) over TLS but accepts any TLS certificate (a permissive TrustManager and a HostnameVerifier that always returns true), does not verify any digital signature on the update descriptor, and does not verify the Authenticode signature or a checksum of the downloaded installer before running it. A man-in-the-middle attacker able to redirect www.eparaksts.lv can serve a crafted update descriptor pointing to an attacker-controlled executable, which the client downloads and executes, resulting in arbitrary code execution on the victim host. | |||||
| CVE-2026-81518 | 2026-09-01 | N/A | 7.5 HIGH | ||
| When mongosqld is configured with a client certificate authority file, the listener requests a client certificate during the TLS handshake but does not require one, so a client that presents no certificate is still accepted. In deployments that rely on client certificates as the sole means of identifying users, a remote party with network access to the listener can therefore establish a session and read the MongoDB data exposed through the connector. | |||||
| CVE-2026-63650 | 2026-09-01 | N/A | N/A | ||
| OpenVPN 2.7_alpha1 through 2.7.5 using mbedTLS allows remote authenticated users to be misidentified by ignoring the configured X.509 username identity lookup field | |||||
| CVE-2026-65084 | 2 Linux, Nvidia | 2 Linux Kernel, Nemoclaw | 2026-09-01 | N/A | 8.1 HIGH |
| NVIDIA NemoClaw for Linux contains a vulnerability in its deployment process, where an attacker could cause improper certificate validation. A successful exploit of this vulnerability might lead to information disclosure, data tampering, code execution, and escalation of privileges. | |||||