CVE-2025-69277
Elliptic Curve Validation Flaw in libsodium Risks Cryptographic Integrity
Publication date: 2025-12-31
Last updated on: 2025-12-31
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| libsodium | libsodium | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-184 | The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-69277 is a vulnerability in the libsodium cryptographic library's low-level function `crypto_core_ed25519_is_valid_point()`, which is supposed to validate whether an elliptic curve point lies in the main subgroup of the Edwards25519 curve. The flaw is that the function only checked if the X coordinate was zero after multiplying the point by the subgroup order but failed to verify that the Y and Z coordinates were equal. This omission allowed certain invalid points, specifically those in mixed-order subgroups where X=0 but Y≠Z, to be incorrectly accepted as valid. This can undermine cryptographic protocols relying on this validation. The issue was fixed by adding the missing check to ensure both conditions (X=0 and Y=Z) are met, preventing invalid points from passing validation. [1, 3, 4]
How can this vulnerability impact me? :
This vulnerability can impact you if you use libsodium's low-level function `crypto_core_ed25519_is_valid_point()` in custom cryptographic protocols or atypical use cases that rely on strict validation of elliptic curve points. Accepting invalid points outside the main subgroup can lead to security weaknesses, such as undermining the correctness and security assumptions of cryptographic operations. However, standard high-level libsodium APIs like `crypto_sign_*` and scalar multiplication functions are not affected, as they do not use this flawed validation. The risk mainly arises when low-level primitives are used beyond their intended scope without proper subgroup checks. [1, 3]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking if the function `crypto_core_ed25519_is_valid_point()` in libsodium improperly validates elliptic curve points, specifically by accepting points where X=0 but Y!=Z after multiplication by the subgroup order L. To detect misuse or exploitation, you can audit your cryptographic code to see if it uses this low-level function directly, especially in custom cryptographic protocols. There is an application-level workaround function `is_on_main_subgroup()` that performs a safe subgroup membership check and can be used to verify points. While no specific network commands are provided, you can implement or use this function to test points for validity. Additionally, monitoring for usage of vulnerable libsodium versions (up to 1.0.20 and before December 30, 2025) can help detect exposure. Since this is a cryptographic validation issue, detection involves code inspection and testing rather than network scanning commands. [1, 4]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include: 1) Upgrade libsodium to a version released after December 30, 2025, which includes the fix adding the missing Y=Z check in `crypto_core_ed25519_is_valid_point()`. 2) If upgrading is not possible, use the application-level workaround function `is_on_main_subgroup()` to safely validate points before use. 3) Prefer using the Ristretto255 group support introduced in libsodium in 2019, which avoids cofactor-related issues and does not require additional subgroup validation. 4) Avoid using low-level primitives like `crypto_core_ed25519_is_valid_point()` directly in custom cryptographic protocols; instead, rely on high-level libsodium APIs which are not affected by this vulnerability. These steps will prevent acceptance of invalid points and maintain cryptographic security. [1, 4, 3]