Total
1566 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-54481 | 2026-08-26 | N/A | 7.5 HIGH | ||
| Internal API HTTP client hardcodes InsecureSkipVerify:true with no config override (CWE-295) | |||||
| CVE-2026-79785 | 2026-08-25 | N/A | 5.9 MEDIUM | ||
| X-AnyLabeling's model downloader disabled TLS certificate verification. download_with_retry in anylabeling/services/auto_labeling/model.py built a context with ssl._create_unverified_context() and passed it to urllib.request.urlopen, so neither the certificate chain nor the hostname was checked on any model download, and models are fetched over HTTPS from the project's release host. Any party positioned to intercept that connection could therefore answer it with content of their own choosing. The response is written to a .part file and moved into place with os.replace, and the only post-download check, safe_check_model, validates the file's format rather than its provenance: no hash or signature is compared against an expected value. For an ONNX target the substituted file passes onnx.checker.check_model and is then used for inference, so the attacker chooses the model that produces the application's annotations. For a .pth or .pt target, which the shipped SAM2 video, YOLOE, UPN and open_vision configurations use, the check worker calls torch.load without weights_only, so a substituted file is unpickled and executes code of the attacker's choosing on PyTorch releases predating the weights_only default. | |||||
| CVE-2026-16835 | 1 Ibm | 18 Power System E1080 \(9080-hex\), Power System E1080 \(9080-hex\) Firmware, Power System E1180 \(9080-heu\) and 15 more | 2026-08-25 | N/A | 9.6 CRITICAL |
| IBM Power Systems Firmware FW1120.00, FW1110.00 through FW1110.30, FW1060.00 through FW1060.80, and FW950.00 through FW950.H2 is affected by a vulnerability in the FSP management network protocol. An unauthenticated attacker on the management network can bypass authentication and perform any administrative operation on the managed system, including control of partition power state, configuration, and console access across all hosted partitions, resulting in a confidentiality, integrity, and availability impact to the managed system. | |||||
| CVE-2026-17024 | 1 Ibm | 2 Aix, Vios | 2026-08-25 | N/A | 7.7 HIGH |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to improper certificate validation. | |||||
| CVE-2026-50149 | 2026-08-25 | N/A | 6.5 MEDIUM | ||
| Contour is a Kubernetes ingress controller using Envoy proxy. In versions 1.23.0 through 1.33.4, when an `HTTPProxy` is configured with incompatible combination of both `.spec.virtualhost.tls.enableFallbackCertificate: true` and `.spec.virtualhost.jwtProviders`, Contour does not reject the configuration. Consequently, requests from clients that do not send TLS SNI or send an unrecognized SNI (one that does not match any `HTTPProxy` FQDN) bypass configured JWT verification and are proxied to upstream services without a valid token. This issue is fixed in Contour v1.33.5. Contour now rejects and marks invalid any `HTTPProxy` resources that combine `.spec.virtualhost.tls.enableFallbackCertificate: true` with `.spec.virtualhost.jwtProviders`. Affected resources will receive a status condition with the error reason `TLSIncompatibleFeatures`. As a workaround, do not enable `.spec.virtualhost.tls.enableFallbackCertificate` on `HTTPProxy` resources that also define `.spec.virtualhost.jwtProviders`. Remove one of the two settings to avoid the invalid configuration. | |||||
| CVE-2026-76403 | 1 Splunk | 1 Connect For Kafka | 2026-08-24 | N/A | 7.4 HIGH |
| In Splunk Connect for Kafka versions below 2.2.7, an unauthenticated user positioned in the network path could read or alter all relevant data sent from the connector when Kerberos authentication is used with Hypertext Transfer Protocol (HTTP) Event Collector in Splunk Enterprise. The vulnerability is possible because the Kerberos authentication path does not apply the configured certificate validation options when it builds the HTTP client. For more information see Install Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/install/install-splunk-connect-for-kafka), Security configurations for Splunk Connect for Kafka (https://help.splunk.com/en/splunk-enterprise/get-data-in/splunk-connect-for-kafka/2.2/configure/security-configurations-for-splunk-connect-for-kafka), and Set up and use HTTP Event Collector with configuration files (https://help.splunk.com/en/splunk-enterprise/get-data-in/get-started-with-getting-data-in/9.4/get-data-with-http-event-collector/set-up-and-use-http-event-collector-with-configuration-files) in the Splunk documentation. | |||||
| CVE-2026-16792 | 2026-08-24 | N/A | 6.1 MEDIUM | ||
| An improper certificate validation vulnerability was reported in multiple Lenovo XClarity Orchestrator (LXCO) 2.2.0 microservices that could allow an adjacent network attacker to intercept sensitive communications by performing a machine-in-the-middle attack against HTTPS connections during TLS certificate validation under certain circumstances. | |||||
| CVE-2026-16822 | 1 Ibm | 2 Aix, Vios | 2026-08-24 | N/A | 9.3 CRITICAL |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to impersonate the TNC policy server and modify traffic due to improper certificate validation. | |||||
| CVE-2026-15554 | 2026-08-24 | N/A | 7.4 HIGH | ||
| 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. | |||||
| CVE-2026-8497 | 3 Apple, Devolutions, Google | 4 Iphone Os, Macos, Password Manager and 1 more | 2026-08-21 | N/A | 7.4 HIGH |
| Improper certificate validation in the Devolutions Server connection handling in Devolutions Password Manager 2026.2.1.0 and earlier on Android, iOS, and macOS allows an adjacent-network attacker to intercept and modify sensitive information via a forged TLS certificate. | |||||
| CVE-2026-76362 | 1 Splunk | 1 Soar | 2026-08-21 | N/A | 7.4 HIGH |
| In Splunk SOAR versions below 8.6.0, an unauthenticated user who can observe or alter network traffic between Splunk SOAR and a configured CyberArk Representational State Transfer (REST) server could access or modify all relevant data exchanged through that credential manager. The vulnerability is possible because the CyberArk REST client does not verify server certificates by default. The attack requires the attacker to have network-path interception capability between Splunk SOAR and the configured CyberArk REST server. For more information see Manage your organization's credentials with a password vault (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/configure-administration-settings-in-splunk-soar-cloud/manage-your-organizations-credentials-with-a-password-vault) in the Splunk documentation. | |||||
| CVE-2026-15078 | 1 Ibm | 2 Aix, Vios | 2026-08-20 | N/A | 8.1 HIGH |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 NIM could allow a remote attacker to gain unauthorized access to AIX systems due to improper validation of TLS certificates. | |||||
| CVE-2026-49283 | 2026-08-19 | N/A | 8.7 HIGH | ||
| The SimpleSAMLphp SAML2 library is a PHP library for SAML2 related functionality. Prior to versions 4.19.3, 4.20.2, 5.0.6, and 6.2.1, the HTTPArtifact::receive() flow can treat an unsigned embedded SAML Response as cryptographically valid for the wrong identity provider. SOAPClient::addSSLValidator() attaches a TLS-based validator to the outer SOAP ArtifactResponse, while the embedded Response receives a validator that delegates to the outer message and is later checked against metadata selected from the embedded response issuer rather than necessarily the artifact issuer. SOAPClient::validateSSL() returns normally when the TLS public key does not match the key being validated, and SAML2\Message::validate() treats a validator call that does not throw as successful. In a multi-IdP federation, a malicious or lower-trust IdP can therefore provide an ArtifactResponse containing an unsigned Response that claims a higher-trust victim IdP as issuer and authenticate as arbitrary users with attacker-chosen assertion attributes, NameID, and session data. This issue is fixed in versions 4.19.3, 4.20.2, 5.0.6, and 6.2.1. | |||||
| CVE-2026-2368 | 1 Lenovo | 1 Filez | 2026-08-19 | N/A | 7.1 HIGH |
| An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to execute arbitrary code. | |||||
| CVE-2026-1068 | 1 Lenovo | 1 Filez | 2026-08-19 | N/A | 5.3 MEDIUM |
| An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to obtain sensitive user data from the application. | |||||
| CVE-2020-1113 | 1 Microsoft | 8 Windows 10, Windows 7, Windows 8.1 and 5 more | 2026-08-19 | 9.3 HIGH | 5.3 MEDIUM |
| A security feature bypass vulnerability exists in Microsoft Windows when the Task Scheduler service fails to properly verify client connections over RPC. An attacker who successfully exploited this vulnerability could run arbitrary code as an administrator. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. To exploit this vulnerability, a man-in-the-middle attacker would need to send a specially crafted request to a vulnerable system. The security update addresses the vulnerability by correcting how the Task Scheduler service validates connections. | |||||
| CVE-2026-8367 | 1 Aria2 Project | 1 Aria2 | 2026-08-19 | N/A | 4.8 MEDIUM |
| aria2c accepts a server certificate with incorrect Extended Key Usage (EKU). If the attackers compromise a certificate (with the associated private key) issued for a different purpose, they may be able to reuse it for TLS server authentication. | |||||
| CVE-2026-47632 | 1 Microsoft | 1 Azure Connected Machine Agent | 2026-08-18 | N/A | 8.8 HIGH |
| Improper certificate validation in Azure Connected Machine Agent allows an unauthorized attacker to elevate privileges over an adjacent network. | |||||
| CVE-2026-71290 | 1 Apache | 1 Httpclient | 2026-08-17 | N/A | 9.1 CRITICAL |
| Improper TLS hostname verification vulnerability in Apache HttpComponents Client 5.4 or newer. HostnameVerificationPolicy#BUILTIN setting has no effect when used with the async version of HttpClient. An attacker that can intercept and modify traffic between the client and the server can impersonate the server by presenting a valid certificate for a different domain. Please note the classic version of HttpClient is not affected by this vulnerability. Affected users are recommended to upgrade to at least version 5.6.4, which fixes the issue. | |||||
| CVE-2026-49457 | 2026-08-14 | N/A | 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. | |||||