CVE-2024-1722 is a low-severity (CVSS 3.7) CWE-645 vulnerability in org.keycloak:keycloak-services. A fix is available for org.keycloak:keycloak-services — see the affected versions and patch details below.
Keycloak-core: dos via account lockout
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2024-1722.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
org.keycloak:keycloak-servicesReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
In any realm set with "User (Self) registration" a user that is registered with a username in email format can be "locked out" (denied from logging in) using his username.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.keycloak:keycloak-services | all versions | 24.0.0org.keycloak:keycloak-services:24.0.0 |
Affected Products
keycloakredhatDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.keycloak:keycloak-services, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.keycloak:keycloak-services to 24.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-1722 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
While this attack enables locking out an individual from their account, the entire system will remain in operation. The follow conditions are required for successful exploitation: - The realm is configured to use "User (Self) registration" - The user registers with a username in email format - The attacker discovers a…
Red Hat Product Security is not aware of a way to completely mitigate this issue. However, the following techniques can be used to help prevent exploitation: - Put limits on frequency of account registration, restricting how often an attacker could utilize this attack - Restrict new account registration to not allow email addresses in the username field, for example, by not allowing the "@" symbol. Note: this cannot prevent attacks against existing users who have registered with an email address. If this vulnerability has been triggered, an administrator has two options to remedy it manually by modifying the second account (of the attacker): - Delete the account - Change the usernameSource: Red Hat security advisory for CVE-2024-1722 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2024-1722 in your dependencies?
Find it across Maven, including transitive dependencies.