If you're using Spring Security and rely on BCryptPasswordEncoder, you need to pay attention to CVE-2025-22228. This vulnerability makes it possible for attackers to bypass password checks if users choose passwords longer than 72 characters. Let's break down how this happens, how it affects your application, and what you can do about it.

What is CVE-2025-22228?

CVE-2025-22228 is a critical security flaw found in the matches method of BCryptPasswordEncoder. Specifically, when users enter passwords longer than 72 characters, the method can return true even if the characters after the 72nd position don't match. This bug happens because the underlying BCrypt algorithm only considers the first 72 bytes of a password, and extra characters are silently ignored. Attackers can exploit this to gain unauthorized access.

Why Is This a Problem?

BCrypt, the algorithm behind BCryptPasswordEncoder, is intentionally designed to only use the first 72 characters (bytes) of a password. Any characters beyond that are ignored during hashing and matching. The problem is, most users—and developers—expect passwords to be matched in full, no matter how long they are.

This means

- Users may think they have a very complex password, but only the first 72 characters are actually protected.

Let’s look at a small code example demonstrating this flaw

import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;

public class BcryptTest {
    public static void main(String[] args) {
        BCryptPasswordEncoder encoder = new BCryptPasswordEncoder();

        // Password that's more than 72 characters
        String originalPassword = "A".repeat(80); // 80 'A's

        // Password hash stored in your DB
        String hash = encoder.encode(originalPassword);

        // Attacker uses first 72 'A's, adds anything else
        String attackerPassword = "A".repeat(72) + "malicious-stuff";

        System.out.println("Match? " + encoder.matches(attackerPassword, hash));
        // Output: Match? true
    }
}

Constructs an Overlong Password:

The attacker crafts an overlong input where only the first 72 characters match the legitimate password. Everything afterwards can be garbage.

Bypasses Authentication:

The application authenticates the attacker—even though their full input doesn’t match the real password.

Obtains Unauthorized Access:

The attacker gains access to accounts, especially if users chose very long passwords for "extra security."

Authentication bypass: Attackers gain access to accounts without knowing the entire password.

- Credential confusion: Users may expect 80+ character passwords are more secure, when actually only the first 72 matter.
- Compliance issues: If your organization needs to meet security requirements about password handling, this flaw puts you out of compliance.

1. Limit Password Length

Enforce a maximum password length of 72 characters in your registration and login forms.

if (password.length() > 72) {
    throw new IllegalArgumentException("Password too long. Maximum is 72 characters.");
}

2. Validate Existing Passwords

If you already allowed longer passwords, notify users and recommend changing them.

3. Stay Updated

Check the status of this CVE in Spring Security’s repositories and mailing lists.

- Spring Security GitHub
- CVE Record for CVE-2025-22228 (availability may be delayed)

4. Consider Other Encoders

If you require longer passwords to be secure in full, consider using algorithms like PBKDF2 or Argon2id, which handle much longer passwords safely.

References

- Spring Security - PasswordEncoder documentation
- bcrypt password length limitation explained
- BCrypt Password Security (original paper)

In Summary

CVE-2025-22228 is a real threat for any Spring Security user relying on BCrypt for password encoding and not enforcing a strict password length. Make sure your application enforces a 72-character limit on passwords, informs users of this limit, and stays current on Spring Security updates. Failing to do so could allow attackers to shortcut your authentication logic—no matter how secure you think it is.

Stay vigilant, keep your dependencies updated, and know your tools' limits!

Timeline

Published on: 03/20/2025 06:15:23 UTC
Last modified on: 03/20/2025 18:15:18 UTC