Total
576 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2020-1464 | 1 Microsoft | 18 Windows 10 1507, Windows 10 1607, Windows 10 1709 and 15 more | 2026-02-23 | 2.1 LOW | 7.8 HIGH |
| A spoofing vulnerability exists when Windows incorrectly validates file signatures. An attacker who successfully exploited this vulnerability could bypass security features and load improperly signed files. In an attack scenario, an attacker could bypass security features intended to prevent improperly signed files from being loaded. The update addresses the vulnerability by correcting how Windows validates file signatures. | |||||
| CVE-2026-2968 | 1 Cesanta | 1 Mongoose | 2026-02-23 | 2.6 LOW | 3.7 LOW |
| A vulnerability was detected in Cesanta Mongoose up to 7.20. This impacts the function mg_chacha20_poly1305_decrypt of the file /src/tls_chacha20.c of the component Poly1305 Authentication Tag Handler. The manipulation results in improper verification of cryptographic signature. The attack may be launched remotely. This attack is characterized by high complexity. The exploitability is said to be difficult. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2020-16922 | 1 Microsoft | 8 Windows 10, Windows 7, Windows 8.1 and 5 more | 2026-02-23 | 2.1 LOW | 5.3 MEDIUM |
| <p>A spoofing vulnerability exists when Windows incorrectly validates file signatures. An attacker who successfully exploited this vulnerability could bypass security features and load improperly signed files.</p> <p>In an attack scenario, an attacker could bypass security features intended to prevent improperly signed files from being loaded.</p> <p>The update addresses the vulnerability by correcting how Windows validates file signatures.</p> | |||||
| CVE-2026-25922 | 1 Goauthentik | 1 Authentik | 2026-02-18 | N/A | 8.8 HIGH |
| authentik is an open-source identity provider. Prior to 2025.8.6, 2025.10.4, and 2025.12.4, when using a SAML Source that has the option Verify Assertion Signature under Verification Certificate enabled and not Verify Response Signature, or does not have the Encryption Certificate setting under Advanced Protocol settings configured, it was possible for an attacker to inject a malicious assertion before the signed assertion that authentik would use instead. authentik 2025.8.6, 2025.10.4, and 2025.12.4 fix this issue. | |||||
| CVE-2025-32060 | 2026-02-18 | N/A | 6.7 MEDIUM | ||
| The system suffers from the absence of a kernel module signature verification. If an attacker can execute commands on behalf of root user (due to additional vulnerabilities), then he/she is also able to load custom kernel modules to the kernel space and execute code in the kernel context. Such a flaw can lead to taking control over the entire system. First identified on Nissan Leaf ZE1 manufactured in 2020. | |||||
| CVE-2026-25793 | 1 Slack | 1 Nebula | 2026-02-18 | N/A | 8.1 HIGH |
| Nebula is a scalable overlay networking tool. In versions from 1.7.0 to 1.10.2, when using P256 certificates (which is not the default configuration), it is possible to evade a blocklist entry created against the fingerprint of a certificate by using ECDSA Signature Malleability to use a copy of the certificate with a different fingerprint. This issue has been patched in version 1.10.3. | |||||
| CVE-2024-23480 | 1 Zscaler | 1 Client Connector | 2026-02-17 | N/A | 7.5 HIGH |
| A fallback mechanism in code sign checking on macOS may allow arbitrary code execution. This issue affects Zscaler Client Connector on MacOS prior to 4.2. | |||||
| CVE-2026-23687 | 1 Sap | 1 Sap Basis | 2026-02-17 | N/A | 8.8 HIGH |
| SAP NetWeaver Application Server ABAP and ABAP Platform allows an authenticated attacker with normal privileges to obtain a valid signed message and send modified signed XML documents to the verifier. This may result in acceptance of tampered identity information, unauthorized access to sensitive user data and potential disruption of normal system usage. | |||||
| CVE-2026-23992 | 1 Theupdateframework | 1 Go-tuf | 2026-02-17 | N/A | 5.9 MEDIUM |
| go-tuf is a Go implementation of The Update Framework (TUF). Starting in version 2.0.0 and prior to version 2.3.1, a compromised or misconfigured TUF repository can have the configured value of signature thresholds set to 0, which effectively disables signature verification. This can lead to unauthorized modification to TUF metadata files is possible at rest, or during transit as no integrity checks are made. Version 2.3.1 fixes the issue. As a workaround, always make sure that the TUF metadata roles are configured with a threshold of at least 1. | |||||
| CVE-2025-64186 | 1 Evervault | 1 Evervault | 2026-02-13 | N/A | 8.7 HIGH |
| Evervault is a payment security solution. A vulnerability was identified in the `evervault-go` SDK’s attestation verification logic in versions of `evervault-go` prior to 1.3.2 that may allow incomplete documents to pass validation. This may cause the client to trust an enclave operator that does not meet expected integrity guarantees. The exploitability of this issue is limited in Evervault-hosted environments as an attacker would require the pre-requisite ability to serve requests from specific evervault domain names, following from our ACME challenge based TLS certificate acquisition pipeline. The vulnerability primarily affects applications which only check PCR8. Though the efficacy is also reduced for applications that check all PCR values, the impact is largely remediated by checking PCR 0, 1 and 2. The identified issue has been addressed in version 1.3.2 by validating attestation documents before storing in the cache, and replacing the naive equality checks with a new SatisfiedBy check. Those who useevervault-go to attest Enclaves that are hosted outside of Evervault environments and cannot upgrade have two possible workarounds available. Modify the application logic to fail verification if PCR8 is not explicitly present and non-empty and/or add custom pre-validation to reject documents that omit any required PCRs. | |||||
| CVE-2026-1529 | 2026-02-10 | N/A | 8.1 HIGH | ||
| A flaw was found in Keycloak. An attacker can exploit this vulnerability by modifying the organization ID and target email within a legitimate invitation token's JSON Web Token (JWT) payload. This lack of cryptographic signature verification allows the attacker to successfully self-register into an unauthorized organization, leading to unauthorized access. | |||||
| CVE-2026-1568 | 2026-02-04 | N/A | 9.6 CRITICAL | ||
| Rapid7 InsightVM versions before 8.34.0 contain a signature verification issue on the Assertion Consumer Service (ACS) cloud endpoint that could allow an attacker to gain unauthorized access to InsightVM accounts setup via "Security Console" installations, resulting in full account takeover. The issue occurs due to the application processing these unsigned assertions and issuing session cookies that granted access to the targeted user accounts. This has been fixed in version 8.34.0 of InsightVM. | |||||
| CVE-2025-12007 | 2026-02-04 | N/A | N/A | ||
| There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X13SEM-F . An attacker can update the system firmware with a specially crafted image. | |||||
| CVE-2025-15469 | 1 Openssl | 1 Openssl | 2026-02-02 | N/A | 5.5 MEDIUM |
| Issue summary: The 'openssl dgst' command-line tool silently truncates input data to 16MB when using one-shot signing algorithms and reports success instead of an error. Impact summary: A user signing or verifying files larger than 16MB with one-shot algorithms (such as Ed25519, Ed448, or ML-DSA) may believe the entire file is authenticated while trailing data beyond 16MB remains unauthenticated. When the 'openssl dgst' command is used with algorithms that only support one-shot signing (Ed25519, Ed448, ML-DSA-44, ML-DSA-65, ML-DSA-87), the input is buffered with a 16MB limit. If the input exceeds this limit, the tool silently truncates to the first 16MB and continues without signaling an error, contrary to what the documentation states. This creates an integrity gap where trailing bytes can be modified without detection if both signing and verification are performed using the same affected codepath. The issue affects only the command-line tool behavior. Verifiers that process the full message using library APIs will reject the signature, so the risk primarily affects workflows that both sign and verify with the affected 'openssl dgst' command. Streaming digest algorithms for 'openssl dgst' and library users are unaffected. The FIPS modules in 3.5 and 3.6 are not affected by this issue, as the command-line tools are outside the OpenSSL FIPS module boundary. OpenSSL 3.5 and 3.6 are vulnerable to this issue. OpenSSL 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue. | |||||
| CVE-2026-24850 | 2026-01-29 | N/A | 5.3 MEDIUM | ||
| The ML-DSA crate is a Rust implementation of the Module-Lattice-Based Digital Signature Standard (ML-DSA). Starting in version 0.0.4 and prior to version 0.1.0-rc.4, the ML-DSA signature verification implementation in the RustCrypto `ml-dsa` crate incorrectly accepts signatures with repeated (duplicate) hint indices. According to the ML-DSA specification (FIPS 204 / RFC 9881), hint indices within each polynomial must be **strictly increasing**. The current implementation uses a non-strict monotonic check (`<=` instead of `<`), allowing duplicate indices. This is a regression bug. The original implementation was correct, but a commit in version 0.0.4 inadvertently changed the strict `<` comparison to `<=`, introducing the vulnerability. Version 0.1.0-rc.4 fixes the issue. | |||||
| CVE-2026-1237 | 2026-01-29 | N/A | N/A | ||
| Vulnerable cross-model authorization in juju. If a charm's cross-model permissions are revoked or expire, a malicious user who is able to update database records can mint an invalid macaroon that is incorrectly validated by the juju controller, enabling a charm to maintain otherwise revoked or expired permissions. This allows a charm to continue relating to another charm in a cross-model relation, and use their workload without their permission. No fix is available as of the time of writing. | |||||
| CVE-2026-0750 | 2026-01-29 | N/A | N/A | ||
| Improper Verification of Cryptographic Signature vulnerability in Drupal Drupal Commerce Paybox Commerce Paybox on Drupal 7.X allows Authentication Bypass.This issue affects Drupal Commerce Paybox: from 7-x-1.0 through 7.X-1.5. | |||||
| CVE-2023-23435 | 1 Honor | 1 Magicos | 2026-01-27 | N/A | 4.0 MEDIUM |
| Some Honor products are affected by signature management vulnerability, successful exploitation could cause the forged system file overwrite the correct system file | |||||
| CVE-2023-23436 | 1 Honor | 1 Magicos | 2026-01-27 | N/A | 7.3 HIGH |
| Some Honor products are affected by signature management vulnerability, successful exploitation could cause the forged system file overwrite the correct system file | |||||
| CVE-2026-22696 | 2026-01-27 | N/A | N/A | ||
| dcap-qvl implements the quote verification logic for DCAP (Data Center Attestation Primitives). A vulnerability present in versions prior to 0.3.9 involves a critical gap in the cryptographic verification process within the dcap-qvl. The library fetches QE Identity collateral (including qe_identity, qe_identity_signature, and qe_identity_issuer_chain) from the PCCS. However, it skips to verify the QE Identity signature against its certificate chain and does not enforce policy constraints on the QE Report. An attacker can forge the QE Identity data to whitelist a malicious or non-Intel Quoting Enclave. This allows the attacker to forge the QE and sign untrusted quotes that the verifier will accept as valid. Effectively, this bypasses the entire remote attestation security model, as the verifier can no longer trust the entity responsible for signing the quotes. All deployments utilizing the dcap-qvl library for SGX or TDX quote verification are affected. The vulnerability has been patched in dcap-qvl version 0.3.9. The fix implements the missing cryptographic verification for the QE Identity signature and enforces the required checks for MRSIGNER, ISVPRODID, and ISVSVN against the QE Report. Users of the `@phala/dcap-qvl-node` and `@phala/dcap-qvl-web` packages should switch to the pure JavaScript implementation, `@phala/dcap-qvl`. There are no known workarounds for this vulnerability. Users must upgrade to the patched version to ensure that QE Identity collateral is properly verified. | |||||