Total
965 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-23680 | 1 Amazon | 1 Aws Encryption Sdk | 2026-07-14 | N/A | 5.3 MEDIUM |
| AWS Encryption SDK for Java versions 2.0.0 to 2.2.0 and less than 1.9.0 incorrectly validates some invalid ECDSA signatures. | |||||
| CVE-2026-54773 | 2026-07-10 | N/A | 5.9 MEDIUM | ||
| 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. | |||||
| CVE-2026-54783 | 2026-07-10 | N/A | 7.4 HIGH | ||
| 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 endorsing and supporting signature verification does not ensure the selected ds:Signature covers the expected Security header target, allowing an attacker with one captured signed SOAP envelope to replay arbitrary service operations as the victim principal. This issue is fixed in versions 1.8.1 and 1.9.1. | |||||
| CVE-2026-54782 | 2026-07-10 | N/A | 10.0 CRITICAL | ||
| 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 SAML 1.1 and SAML 2.0 token validation does not correctly resolve the issuer signing key or require signed tokens when IdentityConfiguration is used with federated bindings, allowing an unauthenticated remote attacker to impersonate any principal the trusted STS could issue. This issue is fixed in versions 1.8.1 and 1.9.1. | |||||
| CVE-2026-54774 | 2026-07-10 | N/A | 7.4 HIGH | ||
| 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, SamlSerializer skips final SignatureValue verification when a CoreWCF service validates SAML tokens using a non-X.509 signing token, allowing an attacker to reference a non-X.509 SecurityToken key identifier and bypass assertion signature verification. This issue is fixed in versions 1.8.1 and 1.9.1. | |||||
| CVE-2026-3564 | 2026-07-09 | N/A | 9.0 CRITICAL | ||
| A condition in the ScreenConnect server component may allow an actor with access to server-level cryptographic material used for authentication to obtain unauthorized access, including elevated privileges, in certain scenarios. ScreenConnect host and guest client agents are not independently affected by this CVE. | |||||
| CVE-2026-9027 | 2026-07-09 | N/A | 5.3 MEDIUM | ||
| The CorvusPay WooCommerce Payment Gateway plugin for WordPress is vulnerable to Payment Bypass via Improper Verification of Cryptographic Signature in all versions up to, and including, 2.7.4. The `corvuspay_success_handler` function registers the REST endpoint `POST /wp-json/corvuspay/success/` with `'permission_callback' => '__return_true'`, and while it calls `$this->client->validate->signature()` and stores the boolean result in `$res`, the result is never evaluated in a conditional — it is only written to the debug log — causing execution to unconditionally reach `$order->payment_complete()` regardless of whether the cryptographic signature is valid. This makes it possible for unauthenticated attackers to mark any pending WooCommerce order as fully paid by sending a POST request to the success endpoint containing an arbitrary or forged signature value, allowing them to obtain goods or services without payment. Because WooCommerce order IDs are sequential integers, target orders are trivially enumerable via the `order_number` POST parameter, requiring no prior knowledge of the victim order. | |||||
| CVE-2022-23334 | 1 Ip-label | 1 Newtest | 2026-07-09 | N/A | 9.8 CRITICAL |
| The Robot application in Ip-label Newtest before v8.5R0 was discovered to use weak signature checks on executed binaries, allowing attackers to have write access and escalate privileges via replacing NEWTESTREMOTEMANAGER.EXE. | |||||
| CVE-2026-46354 | 1 Coder | 1 Coder | 2026-07-08 | N/A | 9.1 CRITICAL |
| Coder allows organizations to provision remote development environments via Terraform. In versions prior tp 2.24.5, 2.29.13, 2.30.8, 2.31.12, 2.32.2, and 2.33.3, `azureidentity.Validate()` verifies that the PKCS#7 signer certificate chains to a trusted Azure CA but never verifies the PKCS#7 signature itself. An attacker can embed a legitimate Azure certificate alongside arbitrary content e.g. `{"vmId":"<target>"}` and the forged `vmId` will be accepted returning the victim workspace agent's session token. No authentication is required. The attacker only needs to know a target VM's `vmId` which is a `UUIDv4`. That's a practical limitation which would typically require prior access to be exploited. Versions 2.24.5, 2.29.13, 2.30.8, 2.31.12, 2.32.2, and 2.33.3 patch the issue. As a workaround, reconfigure any Azure templates to use token authentication rather than `azure-instance-identity`. | |||||
| CVE-2026-40941 | 1 Cacti | 1 Cacti | 2026-06-29 | N/A | 6.5 MEDIUM |
| Cacti is an open source performance and fault management framework. Versions 1.2.30 and prior have a package import signature validation bypass allows which allows self-signed packages. This issue has been fixed in version 1.2.31. | |||||
| CVE-2026-6329 | 1 Wolfssl | 1 Wolfssl | 2026-06-27 | N/A | 6.5 MEDIUM |
| PKCS#12 MAC verification uses an attacker-controlled comparison length, weakening the integrity check on the MAC and allowing a mismatched MAC to be accepted. The PKCS#12 verify path compared the locally computed HMAC against the MAC parsed from the PKCS#12 structure using a length taken directly from the attacker-supplied input, without first verifying that it equals the length of the digest actually produced by the configured algorithm. A truncated or zero-length stored MAC could therefore be accepted, defeating the integrity protection of the MAC. | |||||
| CVE-2026-6331 | 1 Wolfssl | 1 Wolfssl | 2026-06-27 | N/A | 7.5 HIGH |
| 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. | |||||
| CVE-2026-7511 | 1 Wolfssl | 1 Wolfssl | 2026-06-27 | N/A | 7.5 HIGH |
| 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. | |||||
| CVE-2026-55961 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 7.5 HIGH |
| 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. | |||||
| CVE-2024-49394 | 3 Mutt, Neomutt, Redhat | 3 Mutt, Neomutt, Enterprise Linux | 2026-06-26 | N/A | 5.3 MEDIUM |
| 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. | |||||
| CVE-2024-49393 | 3 Mutt, Neomutt, Redhat | 3 Mutt, Neomutt, Enterprise Linux | 2026-06-26 | N/A | 6.5 MEDIUM |
| In neomutt and mutt, the To and Cc email headers are not validated by cryptographic signing which allows an attacker that intercepts a message to change their value and include himself as a one of the recipients to compromise message confidentiality. | |||||
| CVE-2026-46349 | 2026-06-25 | N/A | 5.3 MEDIUM | ||
| Mastodon is a free, open-source social network server based on ActivityPub. Prior to 4.5.10, 4.4.17, and 4.3.23, Mastodon's normalization of incoming activities signed with Linked-Data Signatures does not sufficiently protect the activities from a certain class of spoofing, allowing attackers to re-arrange a valid signed JSON-LD activity from a third-party actor to have it processed differently. This vulnerability is fixed in 4.5.10, 4.4.17, and 4.3.23. | |||||
| CVE-2020-14966 | 2 Kjur, Netapp | 2 Jsrsasign, Max Data | 2026-06-22 | 5.0 MEDIUM | 7.5 HIGH |
| 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. | |||||
| CVE-2021-30246 | 1 Kjur | 1 Jsrsasign | 2026-06-22 | 6.4 MEDIUM | 9.1 CRITICAL |
| In the jsrsasign package through 10.1.13 for Node.js, some invalid RSA PKCS#1 v1.5 signatures are mistakenly recognized to be valid. NOTE: there is no known practical attack. | |||||
| CVE-2022-25898 | 1 Kjur | 1 Jsrsasign | 2026-06-22 | 7.5 HIGH | 7.7 HIGH |
| The package jsrsasign before 10.5.25 are vulnerable to Improper Verification of Cryptographic Signature when JWS or JWT signature with non Base64URL encoding special characters or number escaped characters may be validated as valid by mistake. Workaround: Validate JWS or JWT signature if it has Base64URL and dot safe string before executing JWS.verify() or JWS.verifyJWT() method. | |||||