CVE-2026-107623: Keycloak-services: keycloak-services: oidc dcr read-modify-write silently disables offline token revocation
A flaw was found in the keycloak-services component. A copy-paste error in the OIDC Dynamic Client Registration response serialization prevents the backchannellogoutrevokeofflinetokens setting from being included in GET responses. When an authorized user or client performs a standard read-modify-write update (GET followed by PUT), the missing field is interpreted as false, silently disabling the revocation of offline tokens. An attacker with manage-clients or registration access can exploit this to ensure offline tokens survive backchannel logout events, maintaining unauthorized access after a session should have been terminated. Additionally, this bug causes the backchannellogoutsessionrequired status to be incorrectly overwritten.
Other sources
A flaw was found in the OIDC Dynamic Client Registration (DCR) component of Keycloak. A bug in the response serialization causes the backchannel logout offline token revocation setting to be omitted from responses. When a client performs a standard update, this missing information causes the setting to be silently disabled. As a result, offline tokens may remain valid even after a user session is terminated via backchannel logout.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Who can trigger the unsafe configuration change?
An attacker needs manage-clients or Dynamic Client Registration access and can trigger it through a standard read-modify-write operation: retrieve the client configuration with GET and submit an update with PUT.
What is the security impact if the setting is disabled?
Offline tokens can remain valid after a backchannel logout event terminates the associated user session. This can allow continued unauthorized access using those offline tokens.
Are ordinary client updates a concern?
Yes. The affected GET response omits the offline-token revocation setting, so a normal GET-followed-by-PUT update can interpret the absent field as false and silently disable revocation.
What related configuration behavior should be checked?
The flaw also causes the backchannel_logout_session_required status to be incorrectly overwritten during the affected update flow.