CVE-2025-22228

What it actually does

The flaw is an authentication logic weakness in BCryptPasswordEncoder.matches(CharSequence, String): password candidates longer than 72 characters can be accepted when their first 72 characters match the stored bcrypt password input. Because bcrypt has a 72-byte effective input limit, the comparison can treat different long passwords as equivalent after that boundary. An attacker who knows, guesses, or can derive the first 72 characters of a valid user's password may authenticate with a different password by appending or changing characters beyond the bcrypt limit. The impact is unauthorized authentication, leading to compromise of confidentiality and integrity for accounts protected by the affected password-verification path; availability is not directly affected.

Why it matters to the business

Systems that rely on the affected password-verification behavior may accept an incorrect password for accounts using very long passwords, allowing unauthorized access if an attacker can learn or predict the password prefix. This can lead to account takeover, exposure of sensitive data, unauthorized transactions, or administrative changes, depending on the privileges of the compromised account. The CVSS score is high at 7.4, but exploitation complexity is high and EPSS is currently low, with no known CISA KEV listing or known ransomware use in the provided data. Because the issue has been public for 507 days, organizations should still treat unpatched internet-facing or high-value authentication systems as overdue for remediation.

How an attack unfolds

An attacker first identifies an application or service that uses the affected BCryptPasswordEncoder.matches behavior for login or API authentication. The attacker then targets an account whose password is longer than 72 characters, or an authentication workflow where long generated secrets, passphrases, or migrated credentials are accepted. To exploit the issue, the attacker must obtain or correctly guess the first 72 characters of the victim's password or secret. They then submit a password candidate that preserves those first 72 characters but changes or appends characters after the 72-character boundary. The vulnerable comparison may return success even though the full submitted password is not identical to the original password. If accepted, the attacker receives a normal authenticated session or token and can proceed with the permissions of the compromised account. There is no evidence in the provided data of public exploit maturity, KEV exploitation, ransomware use, or named threat actors, so detection should focus on anomalous long-password authentication behavior rather than known campaign artifacts.

How to fix it

Upgrade affected packages and application dependencies to fixed versions. For Debian 13, update the affected linux package stream to 6.12.5-1 or later as listed in the provided fixed-version data. For applications using BCryptPasswordEncoder, update the relevant security framework or library to a version that correctly handles passwords exceeding the bcrypt 72-character limit. After patching, rebuild and redeploy applications that bundle the vulnerable library rather than relying only on operating-system package updates. As a defense-in-depth control, enforce a safe maximum password length compatible with bcrypt semantics, or switch to a password-hashing configuration that explicitly pre-hashes long inputs using a well-reviewed vendor-supported approach. Avoid silently truncating passwords. Require password reset for users known to have passwords longer than 72 characters if the application previously allowed such passwords. Ensure authentication tests include passwords that differ only after the 72-character boundary.

How to confirm the fix worked

Confirm the deployed package or dependency version is at or above the fixed release, including Debian 13 package version 6.12.5-1 or later where applicable. For source-built or containerized applications, inspect dependency manifests, lock files, SBOMs, and runtime classpaths to ensure the vulnerable BCryptPasswordEncoder implementation is no longer present. Perform a functional authentication test in a non-production environment: create a test account with a password longer than 72 characters, then attempt login with a different password that shares only the first 72 characters. The fixed implementation should not authenticate the altered password. Review CI/CD and unit tests to ensure this boundary case is permanently covered. For deployed services, verify all application instances, containers, and background authentication components were restarted or redeployed after the update.

Typical attack path

1. Identify an application, API, or identity service using the affected bcrypt password-matching implementation.
2. Determine that the target accepts passwords or shared secrets longer than 72 characters.
3. Acquire, infer, or brute-force the first 72 characters of a valid user's password or long secret.
4. Submit a login attempt using the same first 72 characters with a different suffix beyond the bcrypt input boundary.
5. Receive a successful authentication result despite the full password being different.
6. Use the resulting session, token, or account access to read sensitive data, make unauthorized changes, or escalate privileges through normal application functionality.

How to detect it

There are no universal exploit artifacts because successful exploitation looks like a normal login and should not produce malware, files, processes, registry keys, or network signatures by itself. Review application authentication logs, identity-provider audit logs, web access logs, API gateway logs, WAF logs, and session-management logs for successful logins that are anomalous for the account, particularly where the application can safely record password length categories such as greater-than-72-character attempts without storing the password. Look for successful authentication followed by new device enrollment, MFA reset, email or password change, token creation, privilege changes, administrative actions, bulk data access, or unusual API activity. If historical telemetry includes password-length metadata, compare failed and successful login attempts where the submitted password length exceeded 72 characters. Correlate logins from unfamiliar IP addresses, ASNs, geographies, user agents, or impossible-travel patterns against accounts known or suspected to use very long passphrases or generated secrets. In forensic review, inspect deployed dependency versions and application build artifacts to determine whether the vulnerable code was present during suspicious authentication events. Because no named threat actors or campaigns are provided, detection should be behavior-based rather than IOC-based.

What your security team should do

• Prioritize patching authentication services, identity providers, administrative portals, internet-facing applications, and systems protecting regulated or sensitive data.
• Inventory applications that use BCryptPasswordEncoder or bcrypt-based password verification and identify whether they accept passwords or secrets longer than 72 characters.
• Upgrade Debian 13 affected packages to 6.12.5-1 or later where applicable, and update bundled application dependencies separately if they are not provided by the operating system.
• Add regression tests for passwords over 72 characters that differ only after the bcrypt boundary.
• Review authentication logs for unusual successful logins involving accounts known to use very long passwords, especially from new IP addresses, devices, geographies, or automation clients.
• Consider forced password resets for accounts with passwords longer than 72 characters if exposure cannot be ruled out.
• Do not log plaintext passwords to aid detection; instead, if needed, log only safe metadata such as password length category, authentication outcome, account identifier, source IP, and device/session fingerprint.
• Because the vulnerability is not listed in KEV and EPSS is low, handle as high-impact but not currently mass-exploited; prioritize based on authentication exposure and account privilege.