| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| @strapi/core | npm | < 5.10.3 | 5.10.3 |
The vulnerability, CVE-2025-25298, stems from the fact that the bcryptjs library used by Strapi for password hashing silently truncates any password longer than 72 bytes. This means that if a user sets a password of this_is_a_very_long_password_that_is_definitely_more_than_72_bytes_long, only the first 72 bytes are actually used to create the hash. An attacker could then log in by providing only those first 72 bytes, effectively bypassing the full password.
The root cause was a lack of server-side validation to enforce a maximum password length in bytes before the password was passed to bcryptjs. The provided patch addresses this by introducing a validation rule across the entire application wherever a password can be set or updated.
My analysis of the commit 41f8cdf116f7f464dae7d591e52d88f7bfa4b7cb identified all the key functions involved in password management that were missing this validation:
register): For both regular users via the users-permissions plugin and the initial admin user.resetPassword and changePassword for regular users, and the update function for users managed through the admin panel.create): For users created by an administrator in the admin panel.The patch consistently applies a .test('max-bytes', ...) check using yup validation schemas. This new test calculates the byte length of the password string and ensures it does not exceed 72. By identifying the schemas that were modified (createRegisterSchema, createResetPasswordSchema, createChangePasswordSchema, etc.) and the files they are in, I was able to pinpoint the corresponding controller functions that would be active at runtime during an exploitation attempt. These are the functions that process the user's password input and are therefore the primary indicators of this vulnerability being triggered.
A Semantic Attack on Google Gemini - Read the Latest Research