Bug 2555463 (CVE-2026-112201)

Summary: CVE-2026-112201 keycloak-services: keycloak-services: Login-failure upsert trusts MySQL/MariaDB affected-row count
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: aschwart, aszczucz, boliveir, drichtar, mposolda, pjindal, rmartinc, security-response-team, ssilvert, sthorger, vmuzikar
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the login-failure storage component of Keycloak, the identity and access management solution. This issue specifically affects deployments using MySQL or MariaDB databases in a multi-node configuration. When multiple failed login attempts occur simultaneously for the same account, a synchronization error can cause the system to enter a repetitive loop that locks the user's record in the database. This results in legitimate login attempts for that user being blocked and failing with an error. Furthermore, because some failures are not correctly recorded during this loop, the system's brute-force protection may not accurately count all failed attempts.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Deadline: 2027-01-17   

Description OSIDB Bzimport 2026-10-19 10:02:03 UTC 
A flaw was found in the org.keycloak.models.jpa package of Keycloak. The login-failure store contains a defect in its upsert logic that manifests when using MySQL or MariaDB. The issue occurs due to the way these databases report affected-row counts during concurrent transactions. In a multi-node deployment, if two unauthenticated users submit the first failed login attempt for the same account simultaneously, a race condition can trigger an infinite retry loop in one node. This loop persists until a transaction timeout occurs, during which time a database row lock is held.
Successful exploitation allows an unauthenticated remote attacker to:
Cause a temporary Denial of Service for specific user accounts by blocking all subsequent authentication requests until the database lock wait timeout expires.

Partially evade brute-force protection mechanisms, as failed attempts occurring during the race condition may not be recorded in the audit log.