The tough library (Rust/crates.io) prior to version 0.7.1 does not properly verify the threshold of cryptographic signatures. It allows an attacker to duplicate a valid signature in order to circumvent TUF requiring a minimum threshold of unique signatures before the metadata is considered valid. A fix is available in version 0.7.1. CVE-2020-6174 is assigned to the same vulnerability in the TUF reference implementation.

In OASIS Digital Signature Services (DSS) 1.0, an attacker can control the validation outcome (i.e., trigger either a valid or invalid outcome for a valid or invalid signature) via a crafted XML signature, when the InlineXML option is used. This defeats the expectation of non-repudiation.

An issue was discovered in Aviatrix Controller through 5.1. An attacker with any signed SAML assertion from the Identity Provider can establish a connection (even if that SAML assertion has expired or is from a user who is not authorized to access Aviatrix), aka XML Signature Wrapping.

Sylabs Singularity 3.0 through 3.5 has Improper Validation of an Integrity Check Value. Image integrity is not validated when an ECL policy is enforced. The fingerprint required by the ECL is compared against the signature object descriptor(s) in the SIF file, rather than to a cryptographically validated signature.

A vulnerability was found in Samba's SMB2 packet signing mechanism. The SMB2 packet signing is not enforced if an admin configured "server signing = required" or for SMB2 connections to Domain Controllers where SMB2 packet signing is mandatory. This flaw allows an attacker to perform attacks, such as a man-in-the-middle attack, by intercepting the network traffic and modifying the SMB2 messages between client and server, affecting the integrity of the data.

Hyperledger Indy Node is the server portion of a distributed ledger purpose-built for decentralized identity. In Hyperledger Indy before version 1.12.4, there is lack of signature verification on a specific transaction which enables an attacker to make certain unauthorized alterations to the ledger. Updating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender. A malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because 1) Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions), 2) Any DID can change any other DID's alias, 3) The update transaction modifies the ledger metadata associated with a DID.

A flaw was found in Keycloak. When a JSON Web Encryption (JWE) encrypted request object is submitted, Keycloak may incorrectly process unsigned claims if the decrypted content is raw JSON, bypassing the configured signature policy. This allows a remote attacker to submit unauthorized claims, leading to a compromise of data integrity within the OpenID Connect (OIDC) authorization flow. While a redirect URI allowlist acts as a compensating control, this vulnerability violates OIDC Core and Financial-grade API (FAPI) signing requirements.

DELL ECS prior to 3.8.0.2 contains an improper verification of cryptographic signature vulnerability. A network attacker with an ability to intercept the request could potentially exploit this vulnerability to modify the body data of the request.

samlify is a Node.js library for SAML single sign-on. A Signature Wrapping attack has been found in samlify prior to version 2.10.0, allowing an attacker to forge a SAML Response to authenticate as any user. An attacker would need a signed XML document by the identity provider. Version 2.10.0 fixes the issue.

libgit2 is a cross-platform, linkable library implementation of Git. When using an SSH remote with the optional libssh2 backend, libgit2 does not perform certificate checking by default. Prior versions of libgit2 require the caller to set the `certificate_check` field of libgit2's `git_remote_callbacks` structure - if a certificate check callback is not set, libgit2 does not perform any certificate checking. This means that by default - without configuring a certificate check callback, clients will not perform validation on the server SSH keys and may be subject to a man-in-the-middle attack. Users are encouraged to upgrade to v1.4.5 or v1.5.1. Users unable to upgrade should ensure that all relevant certificates are manually checked.

The "Apache NetBeans" autoupdate system does not fully validate code signatures. An attacker could modify the downloaded nbm and include additional code. "Apache NetBeans" versions up to and including 11.2 are affected by this vulnerability.

PKCS7_verify signer confusion allows forged signatures, where the signer associated with a signature is not correctly bound, permitting a forged signature to be accepted.

HMAC zero-length tag forgery in EVP_DigestVerifyFinal, where a zero-length tag could be accepted as valid during HMAC verification. In the OpenSSL-compatibility HMAC verify path the supplied signature length was only checked as not exceeding the MAC length, so a zero-length or otherwise truncated tag could pass verification. The fix requires the supplied tag length to exactly equal the MAC length and rejects a zero-length MAC, so a forged short or empty tag is no longer accepted.

An issue was discovered in the libp2p-core crate before 0.8.1 for Rust. Attackers can spoof ed25519 signatures.

uthenticode is a small cross-platform library for partially verifying Authenticode digital signatures. Versions of uthenticode prior to the 2.x series did not check Extended Key Usages in certificates, in violation of the Authenticode X.509 certificate profile. As a result, a malicious user could produce a "signed" PE file that uthenticode would verify and consider valid using an X.509 certificate that isn't entitled to produce code signatures (e.g., a SSL certificate). By design, uthenticode does not perform full-chain validation. However, the absence of EKU validation was an unintended oversight. The 2.0.0 release series includes EKU checks. There are no workarounds to this vulnerability.

Cargo is a Rust package manager. The Rust Security Response WG was notified that Cargo did not perform SSH host key verification when cloning indexes and dependencies via SSH. An attacker could exploit this to perform man-in-the-middle (MITM) attacks. This vulnerability has been assigned CVE-2022-46176. All Rust versions containing Cargo before 1.66.1 are vulnerable. Note that even if you don't explicitly use SSH for alternate registry indexes or crate dependencies, you might be affected by this vulnerability if you have configured git to replace HTTPS connections to GitHub with SSH (through git's [`url.<base>.insteadOf`][1] setting), as that'd cause you to clone the crates.io index through SSH. Rust 1.66.1 will ensure Cargo checks the SSH host key and abort the connection if the server's public key is not already trusted. We recommend everyone to upgrade as soon as possible.

SOGo 2.x before 2.4.1 and 3.x through 5.x before 5.1.1 does not validate the signatures of any SAML assertions it receives. Any actor with network access to the deployment could impersonate users when SAML is the authentication method. (Only versions after 2.0.5a are affected.)

Misskey is an open source, decentralized social media platform. Misskey's missing signature validation allows arbitrary users to impersonate any remote user. This issue has been patched in version 2023.11.1-beta.1.

A message-forgery issue was discovered in crypto/openpgp/clearsign/clearsign.go in supplementary Go cryptography libraries 2019-03-25. According to the OpenPGP Message Format specification in RFC 4880 chapter 7, a cleartext signed message can contain one or more optional "Hash" Armor Headers. The "Hash" Armor Header specifies the message digest algorithm(s) used for the signature. However, the Go clearsign package ignores the value of this header, which allows an attacker to spoof it. Consequently, an attacker can lead a victim to believe the signature was generated using a different message digest algorithm than what was actually used. Moreover, since the library skips Armor Header parsing in general, an attacker can not only embed arbitrary Armor Headers, but also prepend arbitrary text to cleartext messages without invalidating the signatures.

In the Bouncy Castle JCE Provider version 1.55 and earlier ECDSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of 'invisible' data into a signed structure.

Enigmail before 2.0.11 allows PGP signature spoofing: for an inline PGP message, an attacker can cause the product to display a "correctly signed" message indication, but display different unauthenticated text.

A crafted S/MIME message consisting of an inner encryption layer and an outer SignedData layer was shown as having a valid digital signature, although the signer might have had no access to the contents of the encrypted message, and might have stripped a different signature from the encrypted message. Previous versions had only suppressed showing a digital signature for messages with an outer multipart/signed layer. This vulnerability affects Thunderbird < 68.1.1.

Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. The AF_PACKET defrag option is enabled by default and allows AF_PACKET to re-assemble fragmented packets before reaching Suricata. However the default packet size in Suricata is based on the network interface MTU which leads to Suricata seeing truncated packets. Upgrade to Suricata 7.0.9, which uses better defaults and adds warnings for user configurations that may lead to issues.

Grassroot Platform is an application to make it faster, cheaper and easier to persistently organize and mobilize people in low-income communities. Grassroot Platform before master deployment as of 2021-04-16 did not properly verify the signature of JSON Web Tokens when refreshing an existing JWT. This allows to forge a valid JWT. The problem has been patched in version 1.3.1 by deprecating the JWT refresh function, which was an overdue deprecation regardless (the "refresh" flow is no longer used).

Lasso all versions prior to 2.7.0 has improper verification of a cryptographic signature.

wolfSSL_PKCS7_verify() returning success for a degenerate (certs-only) PKCS#7 object that contains no signer. Such an object has empty signerInfos, so the underlying signed-data verification succeeds without authenticating any content. The compatibility-layer verify path now rejects the object when no signer signature has actually been verified, so a PKCS#7 carrying no valid signature is no longer reported as verified. This is enforced regardless of the PKCS7_NOVERIFY flag, which only suppresses signer certificate chain validation and was never intended to waive the requirement that a signature exist. Only affects OpenSSL compatibility builds that call the PKCS7_verify() compatibility API on potentially degenerate PKCS#7 bundles.

CoreWCF is a port of the service side of Windows Communication Foundation (WCF) to .NET Core. Prior to 1.8.1 and 1.9.1, CoreWCF WS-Security signature verification performs a document-wide ds:Signature lookup, allowing an unauthenticated remote attacker to place a SOAP header before wsse:Security and cause WSSecurityOneDotZeroReceiveSecurityHeader to verify an attacker-supplied signature instead of the security header signature. This issue is fixed in versions 1.8.1 and 1.9.1.

The XmlSecLibs library as used in the saml2 library in SimpleSAMLphp before 1.15.3 incorrectly verifies signatures on SAML assertions, allowing a remote attacker to construct a crafted SAML assertion on behalf of an Identity Provider that would pass as cryptographically valid, thereby allowing them to impersonate a user from that Identity Provider, aka a key confusion issue.

Cisco 7940/7960 Voice over IP (VoIP) phones do not properly check the Call-ID, branch, and tag values in a NOTIFY message to verify a subscription, which allows remote attackers to spoof messages such as the "Messages waiting" message.

The Payment Gateway for Redsys & WooCommerce Lite plugin for WordPress is vulnerable to Improper Verification of Cryptographic Signature in versions up to, and including, 7.0.0 due to successful_request() handlers calculating a local signature but not validating Ds_Signature from the request before accepting payment status across the Redsys, Bizum, and Google Pay gateway flows. This makes it possible for unauthenticated attackers to forge payment callback data and mark pending orders as paid when they know a valid order key and order amount, potentially allowing checkout completion and product or service fulfillment without a successful payment.

sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 4.1.1, the documented certificateOIDs option in sigstore.verify() is accepted by the public API but discarded before verification, so required certificate extension OIDs are never checked and applications relying on certificateOIDs to restrict which certificates may sign artifacts can accept unauthorized certificates. This issue is fixed in version 4.1.1.

sigstore-go is a Go library for Sigstore signing and verification. Prior to 1.2.0, a verifier configured with WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1) counts verified witnesses per entry or per validation path rather than per log authority, allowing a single compromised transparency log or CT log to satisfy multi-log threshold requirements and defeat the multi-log policy. This issue is fixed in version 1.2.0.

LibreOffice supports digital signatures of ODF documents and macros within documents, presenting visual aids that no alteration of the document occurred since the last signing and that the signature is valid. An Improper Certificate Validation vulnerability in LibreOffice allowed an attacker to create a digitally signed ODF document, by manipulating the documentsignatures.xml or macrosignatures.xml stream within the document to contain both "X509Data" and "KeyValue" children of the "KeyInfo" tag, which when opened caused LibreOffice to verify using the "KeyValue" but to report verification with the unrelated "X509Data" value. This issue affects: The Document Foundation LibreOffice 7.2 versions prior to 7.2.5.

The bitcoinj library is a Java implementation of the Bitcoin protocol. Prior to 0.17.1, ScriptExecution.correctlySpends() contains two fast-path verification bugs for standard P2PKH and native P2WPKH spends in core/src/main/java/org/bitcoinj/script/ScriptExecution.java. In both branches, bitcoinj verifies an attacker-controlled signature/public-key pair but fails to verify that the public key is the one committed to by the output being spent. As a result, any attacker keypair can satisfy bitcoinj's local verification for arbitrary P2PKH and P2WPKH outputs. This vulnerability is fixed in 0.17.1.

A flaw during verification of certain S/MIME signatures causes emails to be shown in Thunderbird as having a valid digital signature, even if the shown message contents aren't covered by the signature. The flaw allows an attacker to reuse a valid S/MIME signature to craft an email message with arbitrary content. This vulnerability affects Thunderbird < 60.5.1.

In verify_emsa_pkcs1_signature() in gmp_rsa_public_key.c in the gmp plugin in strongSwan 4.x and 5.x before 5.7.0, the RSA implementation based on GMP does not reject excess data in the digestAlgorithm.parameters field during PKCS#1 v1.5 signature verification. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation when only an RSA signature is used for IKEv2 authentication. This is a variant of CVE-2006-4790 and CVE-2014-1568.

JOSE is a Javascript Object Signing and Encryption (JOSE) library. Prior to version 0.3.5+1, a vulnerability in jose could allow an unauthenticated, remote attacker to forge valid JWS/JWT tokens by using a key embedded in the JOSE header (jwk). The vulnerability exists because key selection could treat header-provided jwk as a verification candidate even when that key was not present in the trusted key store. Since JOSE headers are untrusted input, an attacker could exploit this by creating a token payload, embedding an attacker-controlled public key in the header, and signing with the matching private key. Applications using affected versions for token verification are impacted. This issue has been patched in version 0.3.5+1. A workaround for this issue involves rejecting tokens where header jwk is present unless that jwk matches a key already present in the application's trusted key store.

A vulnerability was found in Dataease SQLBot up to 1.5.1. This impacts the function validateEmbedded of the file backend/apps/system/middleware/auth.py of the component JWT Token Handler. Performing a manipulation results in improper verification of cryptographic signature. The attack can be initiated remotely. The attack is considered to have high complexity. The exploitability is said to be difficult. The exploit has been made public and could be used. A comment in the source code warns users about using this feature. The vendor was contacted early about this disclosure.

The signature verification routine in Enigmail before 2.0.7 interprets user ids as status/control messages and does not correctly keep track of the status of multiple signatures, which allows remote attackers to spoof arbitrary email signatures via public keys containing crafted primary user ids.

Little Snitch versions 4.0 to 4.0.6 use the SecStaticCodeCheckValidityWithErrors() function without the kSecCSCheckAllArchitectures flag and therefore do not validate all architectures stored in a fat binary. An attacker can maliciously craft a fat binary containing multiple architectures that may cause a situation where Little Snitch treats the running process as having no code signature at all while erroneously indicating that the binary on disk does have a valid code signature. This could lead to users being confused about whether or not the code signature is valid.

Nov json-jwt version >= 0.5.0 && < 1.9.4 contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability in Decryption of AES-GCM encrypted JSON Web Tokens that can result in Attacker can forge a authentication tag. This attack appear to be exploitable via network connectivity. This vulnerability appears to have been fixed in 1.9.4 and later.

Improper Verification of a Cryptographic Signature in OpenPGP.js <=4.1.2 allows an attacker to forge signed messages by replacing its signatures with a "standalone" or "timestamp" signature.

Improper Verification of a Cryptographic Signature in OpenPGP.js <=4.1.2 allows an attacker to pass off unsigned data as signed.

The secp256k1-js package before 1.1.0 for Node.js implements ECDSA without required r and s validation, leading to signature forgery.

In Bouncy Castle JCE Provider version 1.55 and earlier the DSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of 'invisible' data into a signed structure.

Lock Warp switch is a feature of Zero Trust platform which, when enabled, prevents users of enrolled devices from disabling WARP client. Due to insufficient policy verification by WARP iOS client, this feature could be bypassed by using the "Disable WARP" quick action.

ServiceStack before 5.9.2 mishandles JWT signature verification unless an application has a custom ValidateToken function that establishes a valid minimum length for a signature.

MITRE is populating this ID because it was assigned prior to Lenovo becoming a CNA. A vulnerability was reported (fixed and publicly disclosed in 2015) in Lenovo System Update version 5.07.0008 and prior that could allow the signature check of an update to be bypassed.

Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.3.0, RSA PKCS#1 v1.5 signature verification code does not properly check `DigestInfo` for a proper ASN.1 structure. This can lead to successful verification with signatures that contain invalid structures but a valid digest. The issue has been addressed in `node-forge` version 1.3.0. There are currently no known workarounds.

Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.3.0, RSA PKCS#1 v1.5 signature verification code does not check for tailing garbage bytes after decoding a `DigestInfo` ASN.1 structure. This can allow padding bytes to be removed and garbage data added to forge a signature when a low public exponent is being used. The issue has been addressed in `node-forge` version 1.3.0. There are currently no known workarounds.