CWE-325
Missing Cryptographic Step
BaseDraft
Description
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
Hierarchy (View 1000)
Related attack patterns (CAPEC)
CAPEC-68
CVEs mapped to this weakness (10)
| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-4601 | Hig | 0.50 | 8.7 | 0.00 | Mar 23, 2026 | Versions of the package jsrsasign before 11.1.1 are vulnerable to Missing Cryptographic Step via the KJUR.crypto.DSA.signWithMessageHash process in the DSA signing implementation. An attacker can recover the private key by forcing r or s to be zero, so the library emits an invalid signature without retrying, and then solves for x from the resulting signature. | |
| CVE-2025-30147 | Hig | 0.50 | — | 0.00 | May 7, 2025 | Besu Native contains scripts and tooling that is used to build and package the native libraries used by the Ethereum client Hyperledger Besu. Besu 24.7.1 through 25.2.2, corresponding to besu-native versions 0.9.0 through 1.2.1, have a potential consensus bug for the precompiles ALTBN128_ADD (0x06), ALTBN128_MUL (0x07), and ALTBN128_PAIRING (0x08). These precompiles were reimplemented in besu-native using gnark-crypto's bn254 implementation, as the former implementation used a library which was no longer maintained and not sufficiently performant. The new gnark implementation was initially added in version 0.9.0 of besu-native but was not utilized by Besu until version 0.9.2 in Besu 24.7.1. The issue is that there are EC points which may be crafted which are in the correct subgroup but are not on the curve and the besu-native gnark implementation was relying on subgroup checks to perform point-on-curve checks as well. The version of gnark-crypto used at the time did not do this check when performing subgroup checks. The result is that it was possible for Besu to give an incorrect result and fall out of consensus when executing one of these precompiles against a specially crafted input point. Additionally, homogenous Besu-only networks can potentially enshrine invalid state which would be incorrect and difficult to process with patched versions of besu which handle these calls correctly. The underlying defect has been patched in besu-native release 1.3.0. The fixed version of Besu is version 25.3.0. As a workaround for versions of Besu with the problem, the native precompile for altbn128 may be disabled in favor of the pure-java implementation. The pure java implementation is significantly slower, but does not have this consensus issue. | |
| CVE-2026-41395 | Hig | 0.42 | 7.5 | 0.00 | Apr 28, 2026 | OpenClaw before 2026.3.28 contains a webhook replay vulnerability in Plivo V3 signature verification that canonicalizes query ordering for signatures but hashes raw URLs for replay detection. Attackers can reorder query parameters to bypass replay cache detection and trigger duplicate voice-call processing with a captured valid signed webhook. | |
| CVE-2021-22946 | Hig | 0.42 | 7.5 | 0.00 | Sep 29, 2021 | A user can tell curl >= 7.20.0 and <= 7.78.0 to require a successful upgrade to TLS when speaking to an IMAP, POP3 or FTP server (`--ssl-reqd` on the command line or`CURLOPT_USE_SSL` set to `CURLUSESSL_CONTROL` or `CURLUSESSL_ALL` withlibcurl). This requirement could be bypassed if the server would return a properly crafted but perfectly legitimate response.This flaw would then make curl silently continue its operations **withoutTLS** contrary to the instructions and expectations, exposing possibly sensitive data in clear text over the network. | |
| CVE-2026-29142 | Med | 0.34 | 5.3 | 0.00 | Apr 2, 2026 | SEPPmail Secure Email Gateway before version 15.0.3 allows an attacker to forge a GINA-encrypted email. | |
| CVE-2025-58359 | Med | 0.32 | — | 0.00 | Sep 5, 2025 | ZF FROST is a Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures). In versions 2.0.0 through 2.1.0, refresh shares with smaller min_signers will reduce security of group. The inability to change min_signers (i.e. the threshold) with the refresh share functionality (frost_core::keys::refresh module) was not made clear to users. Using a smaller value would not decrease the threshold, and attempts to sign using a smaller threshold would fail. Additionally, after refreshing the shares with a smaller threshold, it would still be possible to sign with the original threshold, potentially causing a security loss to the participant's shares. This issue is fixed in version 2.2.0. | |
| CVE-2025-5323 | Low | 0.24 | 3.7 | 0.00 | May 29, 2025 | A vulnerability, which was classified as problematic, has been found in fossasia open-event-server 1.19.1. This issue affects the function send_email_change_user_email of the file /fossasia/open-event-server/blob/development/app/api/helpers/mail.py of the component Mail Verification Handler. The manipulation leads to reliance on obfuscation or encryption of security-relevant inputs without integrity checking. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |
| CVE-2025-59339 | Med | 0.22 | 4.4 | 0.00 | Sep 17, 2025 | The Bastion provides authentication, authorization, traceability and auditability for SSH accesses. Session-recording ttyrec files, may be handled by the provided osh-encrypt-rsync script that is a helper to rotate, encrypt, sign, copy, and optionally move them to a remote storage periodically, if configured to. When running, the script properly rotates and encrypts the files using the provided GPG key(s), but silently fails to sign them, even if asked to. | |
| CVE-2015-20112 | Low | 0.22 | 3.4 | 0.00 | Jun 29, 2025 | RLPx 5 has two CTR streams based on the same key, IV, and nonce. This can facilitate decryption on a private network. | |
| CVE-2024-55655 | Low | 0.11 | — | 0.00 | Dec 10, 2024 | sigstore-python is a Python tool for generating and verifying Sigstore signatures. Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the "integration time" present in "v2" and "v3" bundles during the verification flow: the "integration time" is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect "v1" bundles, as the "v1" bundle format always requires an inclusion promise. Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify). Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry's time. However, this would still be rejected at validation time, as the new entry's (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable. |