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.
An issue was discovered in Foxit Reader and PhantomPDF before 9.5. It allows signature validation bypass via a modified file or a file with non-standard signatures.
wolfSSL before 4.3.0 mishandles calls to wc_SignatureGenerateHash, leading to fault injection in RSA cryptography.
An issue was discovered in Foxit PhantomPDF before 8.3.10. It allows signature validation bypass via a modified file or a file with non-standard signatures.
Deno is a JavaScript, TypeScript, and WebAssembly runtime. Versions 1.46.0 through 2.1.6 have an issue that affects AES-256-GCM and AES-128-GCM in Deno in which the authentication tag is not being validated. This means tampered ciphertexts or incorrect keys might not be detected, which breaks the guarantees expected from AES-GCM. Older versions of Deno correctly threw errors in such cases, as does Node.js. Without authentication tag verification, AES-GCM degrades to essentially CTR mode, removing integrity protection. Authenticated data set with set_aad is also affected, as it is incorporated into the GCM hash (ghash) but this too is not validated, rendering AAD checks ineffective. Version 2.1.7 includes a patch that addresses this issue.
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.
The Keybase app 2.13.2 for iOS provides potentially insufficient notice that it is employing a user's private key to sign a certain cryptocurrency attestation (that an address at keybase.io can be used for Stellar payments to the user), which might be incompatible with a user's personal position on the semantics of an attestation.
An issue was discovered in Decentralized Anonymous Payment System (DAPS) through 2019-08-26. The content to be signed is composed of a representation of strings, rather than being composed of their binary representations. This is a weak signature scheme design that would allow the reuse of signatures in some cases (or even the reuse of signatures, intended for one type of message, for another type). This also affects Private Instant Verified Transactions (PIVX) through 3.4.0.
An issue was discovered in the libp2p-core crate before 0.8.1 for Rust. Attackers can spoof ed25519 signatures.
In mutt and neomutt the In-Reply-To email header field is not protected by cryptographic signing which allows an attacker to reuse an unencrypted but signed email message to impersonate the original sender.
Duo Network Gateway 1.2.9 and earlier may incorrectly utilize the results of XML DOM traversal and canonicalization APIs in such a way that an attacker may be able to manipulate the SAML data without invalidating the cryptographic signature, allowing the attack to potentially bypass authentication to SAML service providers.
Wizkunde SAMLBase may incorrectly utilize the results of XML DOM traversal and canonicalization APIs in such a way that an attacker may be able to manipulate the SAML data without invalidating the cryptographic signature, allowing the attack to potentially bypass authentication to SAML service providers.
Hyperledger Iroha versions v1.0_beta and v1.0.0_beta-1 are vulnerable to transaction and block signature verification bypass in the transaction and block validator allowing a single node to sign a transaction and/or block multiple times, each with a random nonce, and have other validating nodes accept them as separate valid signatures.
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_signed_hash() in lib/liboswkeys/signatures.c in Openswan before 2.6.50.1, the RSA implementation does not verify the value of padding string during PKCS#1 v1.5 signature verification. Consequently, a remote attacker can forge signatures when small public exponents are being used. IKEv2 signature verification is affected when RAW RSA keys are used.
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.
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.
A vulnerability in the Cisco node-jose open source library before 0.11.0 could allow an unauthenticated, remote attacker to re-sign tokens using a key that is embedded within the token. The vulnerability is due to node-jose following the JSON Web Signature (JWS) standard for JSON Web Tokens (JWTs). This standard specifies that a JSON Web Key (JWK) representing a public key can be embedded within the header of a JWS. This public key is then trusted for verification. An attacker could exploit this by forging valid JWS objects by removing the original signature, adding a new public key to the header, and then signing the object using the (attacker-owned) private key associated with the public key embedded in that JWS header.
It is possible for an attacker to manipulate documents to appear to be signed by a trusted source. All versions of Apache OpenOffice up to 4.1.10 are affected. Users are advised to update to version 4.1.11. See CVE-2021-25635 for the LibreOffice advisory.
Huawei APP HiWallet earlier than 5.0.3.100 versions do not support signature verification for APK file. An attacker could exploit this vulnerability to hijack the APK and upload modified APK file. Successful exploit could lead to the APP is hijacking.
An issue was discovered in Enigmail before 1.9.9. In a variant of CVE-2017-17847, signature spoofing is possible for multipart/related messages because a signed message part can be referenced with a cid: URI but not actually displayed. In other words, the entire containing message appears to be signed, but the recipient does not see any of the signed text.
An issue was discovered in Enigmail before 1.9.9. Signature spoofing is possible because the UI does not properly distinguish between an attachment signature, and a signature that applies to the entire containing message, aka TBE-01-021. This is demonstrated by an e-mail message with an attachment that is a signed e-mail message in message/rfc822 format.
phpseclib before 2.0.31 and 3.x before 3.0.7 mishandles RSA PKCS#1 v1.5 signature verification.
Http-signature is a "Reference implementation of Joyent's HTTP Signature Scheme". In versions <=0.9.11, http-signature signs only the header values, but not the header names. This makes http-signature vulnerable to header forgery. Thus, if an attacker can intercept a request, he can swap header names and change the meaning of the request without changing the signature.
Lasso all versions prior to 2.7.0 has improper verification of a cryptographic signature.
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.
An issue was discovered in the jsrsasign package through 8.0.18 for Node.js. It allows a malleability in ECDSA signatures by not checking overflows in the length of a sequence and '0' characters appended or prepended to an integer. The modified signatures are verified as valid. This could have a security-relevant impact if an application relied on a single canonical signature.
A missing cryptographic step in the Identity-Based Encryption service of FortiMail before 7.0.0 may allow an unauthenticated attacker who intercepts the encrypted messages to manipulate them in such a way that makes the tampering and the recovery of the plaintexts 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.)
whatsapp-api-js is a TypeScript server agnostic Whatsapp's Official API framework. It's possible to check the payload validation using the WhatsAppAPI.verifyRequestSignature and expect false when the signature is valid. Incorrect Access Control, anyone using the post or verifyRequestSignature methods to handle messages is impacted. This vulnerability is fixed in 4.0.3.
An issue in code signature validation was addressed with improved checks. This issue is fixed in macOS Big Sur 11.3, iOS 14.5 and iPadOS 14.5, watchOS 7.4, tvOS 14.5. A malicious application may be able to bypass Privacy preferences.
In JetBrains Rider versions 2019.3 EAP2 through 2019.3 EAP7, there were unsigned binaries provided by the Windows installer. This issue was fixed in release version 2019.3.
Union Pay up to 3.3.12, for iOS mobile apps, contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability, allows attackers to shop for free in merchants' websites and mobile apps, via a crafted authentication code (MAC) which is generated based on a secret key which is NULL.