CVE-2026-2733 in Keycloak
Summary
by MITRE • 02/19/2026
A flaw was identified in the Docker v2 authentication endpoint of Keycloak, where tokens continue to be issued even after a Docker registry client has been administratively disabled. This means that turning the client “Enabled” setting to OFF does not fully prevent access. As a result, previously valid credentials can still be used to obtain authentication tokens. This weakens administrative controls and could allow unintended access to container registry resources.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/06/2026
The vulnerability described in CVE-2026-2733 represents a critical authorization flaw within Keycloak's Docker v2 authentication implementation that directly undermines administrative security controls. This issue affects the core authentication mechanism that governs access to Docker registries through Keycloak's identity management system, creating a persistent security gap where disabled clients can still obtain valid authentication tokens. The flaw manifests specifically within the Docker registry client configuration where the administrative toggle for enabling or disabling clients fails to properly invalidate existing authentication sessions. This represents a fundamental breakdown in the principle of least privilege and privilege management within the identity and access management system.
The technical implementation of this vulnerability stems from improper session management and token issuance logic within Keycloak's authentication flow for Docker v2 endpoints. When administrators disable a Docker registry client through the administrative interface, the system should immediately revoke all active sessions and prevent further token issuance for that client. However, the current implementation fails to properly synchronize the client status with the active authentication token lifecycle, allowing previously authenticated sessions to continue operating with valid credentials. This represents a classic case of inadequate state management and session invalidation, where the system does not properly enforce the administrative decision to disable a client across all active authentication contexts. The vulnerability specifically affects the token issuance process during Docker registry authentication requests, where the system fails to validate whether the client remains enabled before proceeding with token generation.
The operational impact of this vulnerability extends beyond simple unauthorized access to container registry resources, creating significant risks for organizations relying on Keycloak for Docker registry security. Attackers who gain access to valid Docker registry credentials can continue to obtain new authentication tokens even after the client has been administratively disabled, effectively bypassing the intended security controls. This undermines the entire administrative framework for managing registry access and creates a persistent backdoor for unauthorized users. The vulnerability particularly affects environments where strict access controls are required for container registry operations, such as in DevOps pipelines, CI/CD systems, and production container deployments. Organizations may experience unauthorized access to sensitive container images, potential data exfiltration, and compromised container security posture. The flaw also impacts audit and compliance requirements, as the system cannot properly enforce client disablement policies and maintain accurate access control records.
Mitigation strategies for CVE-2026-2733 should focus on immediate administrative actions and system hardening measures to prevent exploitation. Organizations should implement immediate monitoring of Docker registry client status changes and ensure that all disabled clients have their active sessions properly terminated. The recommended approach involves configuring additional access controls and implementing network-level restrictions to limit Docker registry access based on client status. System administrators should also consider implementing token revocation mechanisms that can be triggered manually when clients are disabled. Security teams should review and update their access control policies to account for this vulnerability, potentially implementing additional layers of authentication such as multi-factor authentication for critical registry operations. The fix should involve updating Keycloak to a version that properly enforces client status validation during token issuance, ensuring that all authentication requests are validated against the current client enablement status. This vulnerability aligns with CWE-668, which addresses "Exposure of Resource to Wrong Sphere," and may map to ATT&CK technique T1078.004 for valid accounts and T1566.002 for spearphishing via email, as unauthorized access can occur through compromised credentials. Organizations should also consider implementing automated workflows that automatically invalidate tokens when client status changes, providing a more robust security posture against this type of authorization bypass.