CVE-2025-24802
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:NSummary
CVE-2025-24802 is a high-severity Use of a Cryptographic Primitive with a Risky Implementation (CWE-1240) vulnerability. Its CVSS base score is 8.6 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Weaken Encryption (T1600); ranked at the 24th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-24802 is a vulnerability in Plonky2, a SNARK implementation based on PLONK and FRI techniques. The issue affects lookup tables whose length is not divisible by 26 (floor(num_routed_wires / 3)), as they always include an extraneous 0 -> 0 input-output pair due to zero-padding of LookupTableGates. This allows incorrect proofs for lookup table functions f where a malicious prover can demonstrate f(0) = 0, unless the table length is already divisible by 26. The vulnerability, classified under CWE-1240 with a CVSS score of 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N), impacts Plonky2 versions prior to 1.0.1.
A remote attacker with no privileges can exploit this as a malicious prover in a Plonky2 verification scenario. By generating crafted proofs for affected lookup tables, the attacker achieves high-integrity impact, enabling the verification of false statements such as f(0) = 0 for arbitrary functions f. This undermines the soundness of zero-knowledge proofs, potentially allowing invalid computations to pass verification in applications relying on Plonky2 for succinct proofs.
Mitigation is available via a user-side workaround: extend lookup tables by repeating entries to make their length divisible by 26. The vulnerability was fixed in Plonky2 version 1.0.1, as detailed in the project's GitHub security advisory (GHSA-hj49-h7fq-px5h), the fixing commit (091047f7f10cae082716f3738ad59a583835f7b6), and related code in prover.rs. Security practitioners using Plonky2 should upgrade immediately and audit lookup table configurations.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-0168
Vulnerability Data
Plonky2 is a SNARK implementation based on techniques from PLONK and FRI. Lookup tables, whose length is not divisible by 26 = floor(num_routed_wires / 3) always include the 0 -> 0 input-output pair. Thus a malicious prover can always prove…
more
that f(0) = 0 for any lookup table f (unless its length happens to be divisible by 26). The cause of problem is that the LookupTableGate-s are padded with zeros. A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26. This vulnerability is fixed in 1.0.1.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 12 hardening rules · 3 OS baselines
—
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Requires specific, validated cryptographic primitives, reducing use of risky or improperly implemented primitives.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require use of approved, proven cryptographic implementations and forbid risky custom ones.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Mandates approved cryptographic controls, directly preventing use of risky or non-compliant implementations.
Security testing can detect use of weak or non-compliant cryptographic primitives before deployment.
Secure SDLC requires vetted crypto libraries and standards, reducing risky custom implementations.
Application security requirements can specify approved cryptographic standards and disallow risky primitives.
Secure architecture principles include selection of proven cryptographic components and avoidance of custom risky implementations.
Secure coding standards prohibit non-standard or disallowed cryptographic algorithms.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (2 rules)
- V-248524 OL 8 must implement NIST FIPS-validated cryptography for the following: To provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-1240
- V-248534 OL 8 must employ FIPS 140-2 approved cryptographic hashing algorithms for all stored passwords. prevents CWE-1240
Oracle Linux 9 (1 rule)
- V-271628 OL 9 must employ FIPS 140-3 approved cryptographic hashing algorithms for all stored passwords. prevents CWE-1240
RHEL 8 (2 rules)
- V-230223 RHEL 8 must implement NIST FIPS-validated cryptography for the following: To provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-1240
- V-230224 All RHEL 8 local disk partitions must implement cryptographic mechanisms to prevent unauthorized disclosure or modification of all information that requires at rest protection. prevents CWE-1240