Total
655 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-8531 | 2026-04-15 | N/A | 7.2 HIGH | ||
| CWE-347: Improper Verification of Cryptographic Signature vulnerability exists that could compromise the Data Center Expert software when an upgrade bundle is manipulated to include arbitrary bash scripts that are executed as root. | |||||
| CVE-2024-1721 | 2026-04-15 | N/A | N/A | ||
| Improper Verification of Cryptographic Signature vulnerability in HYPR Passwordless on Windows allows Malicious Software Update.This issue affects HYPR Passwordless: before 9.1. | |||||
| CVE-2025-54369 | 2026-04-15 | N/A | N/A | ||
| Node-SAML is a SAML library not dependent on any frameworks that runs in Node. In versions 5.0.1 and below, Node-SAML loads the assertion from the (unsigned) original response document. This is different than the parts that are verified when checking signature. This allows an attacker to modify authentication details within a valid SAML assertion. For example, in one attack it is possible to remove any character from the SAML assertion username. This issue is fixed in version 5.1.0. | |||||
| CVE-2025-31335 | 2026-04-15 | N/A | 4.0 MEDIUM | ||
| The OpenSAML C++ library before 3.3.1 allows forging of signed SAML messages via parameter manipulation (when using SAML bindings that rely on non-XML signatures). | |||||
| CVE-2025-52556 | 2026-04-15 | N/A | N/A | ||
| rfc3161-client is a Python library implementing the Time-Stamp Protocol (TSP) described in RFC 3161. Prior to version 1.0.3, there is a flaw in the timestamp response signature verification logic. In particular, chain verification is performed against the TSR's embedded certificates up to the trusted root(s), but fails to verify the TSR's own signature against the timestamping leaf certificates. Consequently, vulnerable versions perform insufficient signature validation to properly consider a TSR verified, as the attacker can introduce any TSR signature so long as the embedded leaf chains up to some root TSA. This issue has been patched in version 1.0.3. There is no workaround for this issue. | |||||
| CVE-2025-20248 | 2026-04-15 | N/A | 6.0 MEDIUM | ||
| A vulnerability in the installation process of Cisco IOS XR Software could allow an authenticated, local attacker to bypass Cisco IOS XR Software image signature verification and load unsigned software on an affected device. To exploit this vulnerability, the attacker must have root-system privileges on the affected device. This vulnerability is due to incomplete validation of files during the installation of an .iso file. An attacker could exploit this vulnerability by modifying contents of the .iso image and then installing and activating it on the device. A successful exploit could allow the attacker to load an unsigned file as part of the image activation process. | |||||
| CVE-2020-36843 | 2026-04-15 | N/A | 4.3 MEDIUM | ||
| The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message. | |||||
| CVE-2025-59934 | 2026-04-15 | N/A | 9.4 CRITICAL | ||
| Formbricks is an open source qualtrics alternative. Prior to version 4.0.1, Formbricks is missing JWT signature verification. This vulnerability stems from a token validation routine that only decodes JWTs (jwt.decode) without verifying their signatures. Both the email verification token login path and the password reset server action use the same validator, which does not check the token’s signature, expiration, issuer, or audience. If an attacker learns the victim’s actual user.id, they can craft an arbitrary JWT with an alg: "none" header and use it to authenticate and reset the victim’s password. This issue has been patched in version 4.0.1. | |||||
| CVE-2024-8698 | 2026-04-15 | N/A | 7.7 HIGH | ||
| A flaw exists in the SAML signature validation method within the Keycloak XMLSignatureUtil class. The method incorrectly determines whether a SAML signature is for the full document or only for specific assertions based on the position of the signature in the XML document, rather than the Reference element used to specify the signed element. This flaw allows attackers to create crafted responses that can bypass the validation, potentially leading to privilege escalation or impersonation attacks. | |||||
| CVE-2025-27498 | 2026-04-15 | N/A | N/A | ||
| aes-gcm is a pure Rust implementation of the AES-GCM. In decrypt_in_place_detached, the decrypted ciphertext (which is the correct ciphertext) is exposed even if the tag is incorrect. This is because in decrypt_inplace in asconcore.rs, tag verification causes an error to be returned with the plaintext contents still in buffer. The vulnerability is fixed in 0.4.3. | |||||
| CVE-2025-34500 | 2026-04-15 | N/A | N/A | ||
| Deck Mate 2's firmware update mechanism accepts packages without cryptographic signature verification, encrypts them with a single hard-coded AES key shared across devices, and uses a truncated HMAC for integrity validation. Attackers with access to the update interface - typically via the unit's USB update port - can craft or modify firmware packages to execute arbitrary code as root, allowing persistent compromise of the device's integrity and deck randomization process. Physical or on-premises access remains the most likely attack path, though network-exposed or telemetry-enabled deployments could theoretically allow remote exploitation if misconfigured. The vendor confirmed that firmware updates have been issued to correct these update-chain weaknesses and that USB update access has been disabled on affected units. | |||||
| CVE-2024-10237 | 2026-04-15 | N/A | 7.2 HIGH | ||
| There is a vulnerability in the BMC firmware image authentication design at Supermicro MBD-X12DPG-OA6 . An attacker can modify the firmware to bypass BMC inspection and bypass the signature verification process | |||||
| CVE-2025-47934 | 2026-04-15 | N/A | N/A | ||
| OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. Startinf in version 5.0.1 and prior to versions 5.11.3 and 6.1.1, a maliciously modified message can be passed to either `openpgp.verify` or `openpgp.decrypt`, causing these functions to return a valid signature verification result while returning data that was not actually signed. This flaw allows signature verifications of inline (non-detached) signed messages (using `openpgp.verify`) and signed-and-encrypted messages (using `openpgp.decrypt` with `verificationKeys`) to be spoofed, since both functions return extracted data that may not match the data that was originally signed. Detached signature verifications are not affected, as no signed data is returned in that case. In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js. In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature. The issue has been patched in versions 5.11.3 and 6.1.1. Some workarounds are available. When verifying inline-signed messages, extract the message and signature(s) from the message returned by `openpgp.readMessage`, and verify the(/each) signature as a detached signature by passing the signature and a new message containing only the data (created using `openpgp.createMessage`) to `openpgp.verify`. When decrypting and verifying signed+encrypted messages, decrypt and verify the message in two steps, by first calling `openpgp.decrypt` without `verificationKeys`, and then passing the returned signature(s) and a new message containing the decrypted data (created using `openpgp.createMessage`) to `openpgp.verify`. | |||||
| CVE-2025-27773 | 2026-04-15 | N/A | 8.6 HIGH | ||
| The SimpleSAMLphp SAML2 library is a PHP library for SAML2 related functionality. Prior to versions 4.17.0 and 5.0.0-alpha.20, there is a signature confusion attack in the HTTPRedirect binding. An attacker with any signed SAMLResponse via the HTTP-Redirect binding can cause the application to accept an unsigned message. Versions 4.17.0 and 5.0.0-alpha.20 contain a fix for the issue. | |||||
| CVE-2025-9485 | 2026-04-15 | N/A | 9.8 CRITICAL | ||
| The OAuth Single Sign On – SSO (OAuth Client) plugin for WordPress is vulnerable to Improper Verification of Cryptographic Signature in versions up to, and including, 6.26.12. This is due to the plugin performing unsafe JWT token processing without verification or validation in the `get_resource_owner_from_id_token` function. This makes it possible for unauthenticated attackers to bypass authentication and gain access to any existing user account - including administrators in certain configurations - or to create arbitrary subscriber-level accounts. | |||||
| CVE-2025-54419 | 2026-04-15 | N/A | 10.0 CRITICAL | ||
| A SAML library not dependent on any frameworks that runs in Node. In version 5.0.1, Node-SAML loads the assertion from the (unsigned) original response document. This is different than the parts that are verified when checking signature. This allows an attacker to modify authentication details within a valid SAML assertion. For example, in one attack it is possible to remove any character from the SAML assertion username. To conduct the attack an attacker would need a validly signed document from the identity provider (IdP). This is fixed in version 5.1.0. | |||||
| CVE-2018-25099 | 2026-04-15 | N/A | 9.8 CRITICAL | ||
| In the CryptX module before 0.062 for Perl, gcm_decrypt_verify() and chacha20poly1305_decrypt_verify() do not verify the tag. | |||||
| CVE-2025-32977 | 2026-04-15 | N/A | 9.6 CRITICAL | ||
| Quest KACE Systems Management Appliance (SMA) 13.0.x before 13.0.385, 13.1.x before 13.1.81, 13.2.x before 13.2.183, 14.0.x before 14.0.341 (Patch 5), and 14.1.x before 14.1.101 (Patch 4) allows unauthenticated users to upload backup files to the system. While signature validation is implemented, weaknesses in the validation process can be exploited to upload malicious backup content that could compromise system integrity. | |||||
| CVE-2026-22696 | 2026-04-15 | 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. | |||||
| CVE-2025-54549 | 2026-04-15 | N/A | 5.9 MEDIUM | ||
| Cryptographic validation of upgrade images could be circumventing by dropping a specifically crafted file into the upgrade ISO | |||||