Total
1716 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-41872 | 2026-10-26 | N/A | 7.4 HIGH | ||
| "Kura Sushi Official App" provided by EPG, Inc. is vulnerable to improper certificate validation. A man-in-the-middle attack may allow eavesdropping on, or altering, the communication on push notifications between the affected application and the relevant server. | |||||
| CVE-2026-42213 | 2026-10-26 | N/A | 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-8367 | 1 Aria2 Project | 1 Aria2 | 2026-10-26 | 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-115693 | 2026-10-26 | N/A | N/A | ||
| Improper Certificate Validation vulnerability in hackney_ssl in benoitc hackney allows an on-path attacker to impersonate a server pinned to a private certificate authority via a certificate chain that ends in a publicly trusted root. hackney adds {partial_chain, fun hackney_ssl:partial_chain/1} to every verify_peer configuration. The callback returns any certificate in the peer chain whose public key matches a root in the bundled certifi store as the trust anchor, and OTP honours that callback over the configured cacerts. hackney_ssl:merge_ssl_opts/3 kept the callback when the caller replaced the trust store with cacerts or cacertfile in ssl_options, so a connection pinned to a private CA still accepted any chain that carried a publicly trusted root. The hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname. This issue affects hackney: from 1.24.0 before 4.9.0. | |||||
| CVE-2026-115929 | 2026-10-26 | N/A | 6.8 MEDIUM | ||
| MongoDB Compass relies on Electron, a third-party runtime that carries its own TLS root certificate store. This root certificate store has the recoverable eMudhra intermediate CA certificates. Issue is resolved by updating to Compass 1.53.1, which includes Electron 44.9.1. | |||||
| CVE-2026-115930 | 2026-10-26 | N/A | 6.8 MEDIUM | ||
| The MongoDB Shell (mongosh) relies on Node.js as a third-party runtime that carries its own TLS root certificate store. This certificate store has the recoverable eMudhra intermediate CA certificates. This issue impacts MongoDB Shell (mongosh) versions prior to 2.14.0 and can be resolved by updating to mongosh 2.14.0 which bundles Node.js 24.22.1 or later. If mongosh is installed through npm, it uses the Node.js runtime installed on the host; update that runtime separately. | |||||
| CVE-2026-44309 | 2026-10-26 | N/A | 5.3 MEDIUM | ||
| Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. Prior to 0.16.0, gitsign verify and gitsign verify-tag re-encode commit/tag objects through go-git's EncodeWithoutSignature before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate tree headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes gitsign verify while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content. This vulnerability is fixed in 0.16.0. | |||||
| CVE-2026-0249 | 1 Paloaltonetworks | 1 Globalprotect | 2026-10-26 | N/A | 6.5 MEDIUM |
| Multiple improper certificate validation vulnerabilities in the Palo Alto Networks GlobalProtect™ app enables an attacker to intercept encrypted communications and potentially compromise the endpoint. This can enable a local non-administrative operating system user or an attacker on the same subnet to redirect traffic to an unauthorized server and facilitate the installation of malicious software. The GlobalProtect app on Linux, Windows, iOS and GlobalProtect UWP app are not affected. | |||||
| CVE-2026-44700 | 2026-10-26 | N/A | N/A | ||
| Elixir WebRTC is an Elixir implementation of the W3C WebRTC API. Prior to 0.15.1 and 0.16.1, missing DTLS peer certificate fingerprint validation in the DTLS client (active) role removes one side of WebRTC's mutual authentication. The bug is not independently exploitable for media interception in standard deployments, but enables a full man-in-the-middle attack when chained with insecure signalling or a peer with similar validation gaps. This vulnerability is fixed in 0.15.1 and 0.16.1. | |||||
| CVE-2026-44363 | 2026-10-26 | N/A | N/A | ||
| MISP modules are autonomous modules that can be used to extend MISP for new services. Prior to 3.0.7, an unsafe remote resource fetching vulnerability existed in MISP Modules expansion modules. The html_to_markdown module accepted arbitrary HTTP(S) URLs without sufficient validation, which could allow Server-Side Request Forgery against loopback, private, or link-local network resources. Additionally, the qrcode module disabled TLS certificate verification when retrieving remote images, exposing requests to potential man-in-the-middle interception or response tampering. The issue was fixed by validating URL schemes, blocking local and private address ranges, resolving hostnames before fetching, enforcing request timeouts, and re-enabling TLS certificate verification. This vulnerability is fixed in 3.0.7. | |||||
| CVE-2026-32992 | 1 Cpanel | 3 Cpanel, Whm, Wp Squared | 2026-10-26 | N/A | 8.2 HIGH |
| SSL verification is disabled in the DNS Cluster system. This could allow for a malicious server to man-in-the-middle the request and capture credentials. | |||||
| CVE-2026-0244 | 1 Paloaltonetworks | 20 Ion 1200, Ion 1200-c-na, Ion 1200-c-row and 17 more | 2026-10-26 | N/A | 8.1 HIGH |
| An improper certificate validation vulnerability in the Palo Alto Networks Prisma SD-WAN ION enables man-in-the-middle (MitM) attacker to impersonate the controller. | |||||
| CVE-2026-0248 | 2 Google, Paloaltonetworks | 3 Android, Chrome Os, Prisma Access Agent | 2026-10-26 | N/A | 5.9 MEDIUM |
| An improper certificate validation vulnerability in the Prisma Access Agent® for Android and Chrome OS enables an attacker to perform a man-in-the-middle (MitM) attack to intercept VPN traffic. By presenting a certificate for any domain issued by a trusted Certificate Authority, the attacker can capture sensitive device information. The Prisma Access Agent on macOS, Windows, Linux and iOS are not affected. | |||||
| CVE-2026-44312 | 2026-10-26 | N/A | 5.8 MEDIUM | ||
| css_parser is a Ruby CSS parser. Prior to 2.1.0 and 1.22.0, the CSS Parser gem does not validate HTTPS connections, allowing a Man-in-the-Middle (MITM) attacker to inject or modify CSS content when stylesheets are loaded via HTTPS. The connection is established with OpenSSL::SSL::VERIFY_NONE, meaning any HTTPS certificate—even entirely untrusted—will be accepted without validation. This vulnerability is fixed in 2.1.0 and 1.22.0. | |||||
| CVE-2026-23998 | 1 Fleetdm | 1 Fleet | 2026-10-26 | N/A | 7.5 HIGH |
| Fleet is open source device management software. Prior to version 4.81.0, a vulnerability in Fleet’s Windows MDM management endpoint could allow requests to be processed without proper client certificate validation. In certain circumstances, this could allow an attacker to impersonate an enrolled Windows device and retrieve sensitive configuration data. Fleet’s Windows MDM management endpoint relies on mutual TLS (mTLS) client certificates to authenticate enrolled devices. In affected versions, requests that did not present a client certificate could be incorrectly treated as trusted. As a result, an attacker with prior knowledge of a valid enrolled device identifier could potentially impersonate that device and receive configuration payloads intended for it. These payloads may contain sensitive information such as Wi-Fi or VPN configuration data, certificates, or other secrets delivered through MDM profiles. This issue does not allow enrollment of new devices, administrative access to Fleet, or compromise of the Fleet control plane. Impact is limited to the targeted Windows device. Version 4.81.0 contains a patch. If an immediate upgrade is not possible, affected Fleet users should temporarily disable Windows MDM. | |||||
| CVE-2026-83926 | 1 Microsoft | 11 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 8 more | 2026-10-26 | N/A | 4.4 MEDIUM |
| Improper certificate validation in Windows Hello allows an authorized attacker to bypass a security feature locally. | |||||
| CVE-2026-41119 | 2026-10-26 | N/A | 6.8 MEDIUM | ||
| Dell Live Optics Windows and Personal Edition collectors contain an improper certificate validation vulnerability. A remote unauthenticated attacker could potentially exploit this vulnerability leading to loss of confidentiality and integrity. | |||||
| CVE-2026-42791 | 1 Erlang | 1 Erlang\/otp | 2026-10-26 | N/A | 3.7 LOW |
| Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_ocsp module) allows forged OCSP responses signed with an expired responder certificate to be accepted as valid. OCSP response verification in pubkey_ocsp:verify_response/5 and pubkey_ocsp:is_authorized_responder/3 in lib/public_key/src/pubkey_ocsp.erl does not check the validity period (notBefore/notAfter) of the OCSP responder certificate. An attacker who has obtained the private key of an expired CA-designated OCSP responder certificate can forge OCSP responses that Erlang/OTP accepts as valid. This affects TLS clients using OCSP stapling via the ssl application: a malicious or compromised server can present a revoked TLS certificate together with a forged OCSP response signed by an expired responder key, and the client will accept the revoked certificate as valid. It also affects applications calling public_key:pkix_ocsp_validate/5 directly, where the impact depends on the use case — server-side client certificate validation using this API may allow authentication bypass with a revoked client certificate. This issue affects OTP from OTP 27.0 before OTP 29.0.1, OTP 28.5.0.1 and OTP 27.3.4.12, corresponding to public_key from 1.16 before 1.21.1, 1.20.3.1 and 1.17.1.3. | |||||
| CVE-2026-42790 | 1 Erlang | 1 Erlang\/otp | 2026-10-26 | N/A | 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-47074 | 2026-10-26 | N/A | N/A | ||
| Improper Certificate Validation vulnerability in ex-aws ex_aws_sns (ExAws.SNS, ExAws.SNS.PublicKeyCache modules) allows Signature Spoofing by Improper Validation. This vulnerability is associated with program files lib/ex_aws/sns.ex, lib/ex_aws/sns/public_key_cache.ex and program routines 'Elixir.ExAws.SNS':verify_message/1, 'Elixir.ExAws.SNS.PublicKeyCache':get/1. 'Elixir.ExAws.SNS':verify_message/1 fetches the signing certificate from the SigningCertURL field of the incoming SNS message without validating that the URL uses HTTPS or that the host matches an AWS-owned SNS certificate domain. An unauthenticated attacker who can POST to an endpoint that calls verify_message/1 can supply an attacker-controlled SigningCertURL, sign a forged SNS message with their own key, and cause the function to return :ok, completely bypassing SNS signature verification. This issue affects ex_aws_sns: from 2.0.1 before 2.3.5. | |||||