VYPR
Get started

CWE-347

Improper Verification of Cryptographic Signature

BaseDraft

Description

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

Hierarchy (View 1000)

Parents

Children

none

Related attack patterns (CAPEC)

CAPEC-463 · CAPEC-475

CVEs mapped to this weakness (119)

page 1 of 6
CVESevRiskCVSSEPSSKEVPublishedDescription
CVE-2026-6911Cri0.649.80.00Apr 24, 2026Missing JWT signature verification in AWS Ops Wheel allows unauthenticated attackers to forge JWT tokens and gain unintended administrative access to the application, including the ability to read, modify, and delete all application data across tenants and manage Cognito user accounts within the deployment's User Pool, via a crafted JWT sent to the API Gateway endpoint. To remediate this issue, users should redeploy from the updated repository and ensure any forked or derivative code is patched to incorporate the new fixes.
CVE-2026-33746Cri0.649.80.00Apr 2, 2026Convoy is a KVM server management panel for hosting businesses. From version 3.9.0-beta to before version 4.5.1, the JWTService::decode() method did not verify the cryptographic signature of JWT tokens. While the method configured a symmetric HMAC-SHA256 signer via lcobucci/jwt, it only validated time-based claims (exp, nbf, iat) using the StrictValidAt constraint. The SignedWith constraint was not included in the validation step. This means an attacker could forge or tamper with JWT token payloads — such as modifying the user_uuid claim — and the token would be accepted as valid, as long as the time-based claims were satisfied. This directly impacts the SSO authentication flow (LoginController::authorizeToken), allowing an attacker to authenticate as any user by crafting a token with an arbitrary user_uuid. This issue has been patched in version 4.5.1.
CVE-2026-31946Cri0.649.80.00Mar 30, 2026OpenOlat is an open source web-based e-learning platform for teaching, learning, assessment and communication. From version 10.5.4 to before version 20.2.5, OpenOLAT's OpenID Connect implicit flow implementation does not verify JWT signatures. The JSONWebToken.parse() method silently discards the signature segment of the compact JWT (header.payload.signature), and the getAccessToken() methods in both OpenIdConnectApi and OpenIdConnectFullConfigurableApi only validate claim-level fields (issuer, audience, state, nonce) without any cryptographic signature verification against the Identity Provider's JWKS endpoint. This issue has been patched in version 20.2.5.
CVE-2023-53951Cri0.649.80.00Dec 19, 2025Ever Gauzy v0.281.9 contains a JWT authentication vulnerability that allows attackers to exploit weak HMAC secret key implementation. Attackers can leverage the exposed JWT token to authenticate and gain unauthorized access with administrative permissions.
CVE-2025-9485Cri0.649.80.01Oct 4, 2025The 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-2024-47943Cri0.649.80.00Oct 15, 2024The firmware upgrade function in the admin web interface of the Rittal IoT Interface & CMC III Processing Unit devices checks if the patch files are signed before executing the containing run.sh script. The signing process is kind of an HMAC with a long string as key which is hard-coded in the firmware and is freely available for download. This allows crafting malicious "signed" .patch files in order to compromise the device and execute arbitrary code.
CVE-2026-1568Cri0.629.60.00Feb 3, 2026Rapid7 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-54982Cri0.629.60.00Aug 5, 2025An improper verification of cryptographic signature in Zscaler's SAML authentication mechanism on the server-side allowed an authentication abuse.
CVE-2025-32977Cri0.629.60.00Jun 24, 2025Quest 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-22696Cri0.60—0.00Jan 26, 2026dcap-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-2024-13990Cri0.60—0.00Sep 19, 2025MicroWorld eScan AV's update mechanism failed to ensure authenticity and integrity of updates: update packages were delivered and accepted without robust cryptographic verification. As a result, an on-path attacker could perform a man-in-the-middle (MitM) attack and substitute malicious update payloads for legitimate ones. The eScan AV client accepted these substituted packages and executed or loaded their components (including sideloaded DLLs and Java/installer payloads), enabling remote code execution on affected systems. MicroWorld eScan confirmed remediation of the update mechanism on 2023-07-31 but versioning details are unavailable. NOTE: MicroWorld eScan disputes the characterization in third-party reports, stating the issue relates to 2018–2019 and that controls were implemented then.
CVE-2024-11957Cri0.60—0.00Mar 4, 2025Improper verification of the digital signature in ksojscore.dll in Kingsoft WPS Office in versions equal or less than 12.1.0.18276 on Windows allows an attacker to load an arbitrary Windows library. The patch released in version 12.2.0.16909 to mitigate CVE-2024-7262 was not restrictive enough.
CVE-2026-40372Cri0.599.10.00Apr 21, 2026Improper verification of cryptographic signature in ASP.NET Core allows an unauthorized attacker to elevate privileges over a network.
CVE-2026-34872Cri0.599.10.00Apr 1, 2026An issue was discovered in Mbed TLS 3.5.x and 3.6.x through 3.6.5 and TF-PSA-Crypto 1.0. There is a lack of contributory behavior in FFDH due to improper input validation. Using finite-field Diffie-Hellman, the other party can force the shared secret into a small set of values (lack of contributory behavior). This is a problem for protocols that depend on contributory behavior (which is not the case for TLS). The attack can be carried by the peer, or depending on the protocol by an active network attacker (person in the middle).
CVE-2026-33026Cri0.599.10.00Mar 30, 2026Nginx UI is a web user interface for the Nginx web server. Prior to version 2.3.4, the nginx-ui backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration. This issue has been patched in version 2.3.4.
CVE-2026-29000Cri0.599.10.00Mar 4, 2026pac4j-jwt versions prior to 4.5.9, 5.7.9, and 6.3.3 contain an authentication bypass vulnerability in JwtAuthenticator when processing encrypted JWTs that allows remote attackers to forge authentication tokens. Attackers who possess the server's RSA public key can create a JWE-wrapped PlainJWT with arbitrary subject and role claims, bypassing signature verification to authenticate as any user including administrators.
CVE-2024-32962Cri0.5910.00.11May 2, 2024xml-crypto is an xml digital signature and encryption library for Node.js. In affected versions the default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of the w3 xmldsig-core-20080610 spec. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `<KeyInfo />` element, and pass `xml-crypto` default validation checks. As a result `xml-crypto` trusts by default any certificate provided via digitally signed XML document's `<KeyInfo />`. `xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes. An attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to `<KeyInfo />` element. This vulnerability is combination of changes introduced to `4.0.0` on pull request 301 / commit `c2b83f98` and has been addressed in version 6.0.0 with pull request 445 / commit `21201723d`. Users are advised to upgrade. Users unable to upgrade may either check the certificate extracted via `getCertFromKeyInfo` against trusted certificates before accepting the results of the validation or set `xml-crypto's getCertFromKeyInfo` to `() => undefined` forcing `xml-crypto` to use an explicitly configured `publicCert` or `privateKey` for signature verification.
CVE-2025-54419Cri0.5810.00.00Jul 28, 2025A 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-2024-7479Hig0.588.80.06Sep 25, 2024Improper verification of cryptographic signature during installation of a VPN driver via the TeamViewer_service.exe component of TeamViewer Remote Clients prior version 15.58.4 for Windows allows an attacker with local unprivileged access on a Windows system to elevate their privileges and install drivers.
CVE-2026-3562Hig0.578.80.00Mar 16, 2026Philips Hue Bridge hk_hap Ed25519 Signature Verification Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Philips Hue Bridge. Authentication is not required to exploit this vulnerability. The specific flaw exists within the ed25519_sign_open function. The issue results from improper verification of a cryptographic signature. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-28480.