Keycloak 26.8.1 changes how the SAML single logout (SLO) endpoint treats a LogoutRequest whose SessionIndex belongs to a different client than the one sending the request: before the change, Keycloak ended the whole user session anyway, and from 26.8.1 it rejects the request as a bad request and records the reason session_index_not_owned_by_issuer on a failed event. Single logout normally lets a client end a session it took part in. The gap was that a client could also end the single sign-on session of a user who had never signed in to that client, provided it knew the user session ID and the ID of a client in that session. If you run SAML clients on 26.8.0, upgrade, make sure your SAML clients require signed requests, and test logout for each client afterwards.
This post describes what the Keycloak source shows between the 26.8.0 and 26.8.1 tags. We read the code and did not rely on a summary of it, and we make no claim about a CVE identifier or severity rating, because we have not seen the Keycloak project assign either. We checked 26.8.0 and 26.8.1 only, so we cannot say how far back the behavior goes, and the code path is old enough that earlier releases are plausibly affected.
What is SAML single logout, and why does a SessionIndex matter?
SAML single logout is the part of the SAML 2.0 standard (the OASIS SAML 2.0 Profiles document defines the Single Logout Profile) that lets a user sign out once and be signed out everywhere they used that identity provider. A service provider (the application) sends the identity provider a LogoutRequest message, and the identity provider ends the user’s session and, ideally, tells the other applications in that session to do the same.
A LogoutRequest can carry one or more SessionIndex values, which identify the specific session the application wants to end. Keycloak builds the value it hands to each application at login from two identifiers joined by ::: the user session ID and the internal ID of the client (see SamlSessionUtils in the Keycloak source). When a request arrives, Keycloak splits the value, finds the matching client session and ends it.
What did Keycloak do before 26.8.1?
When a LogoutRequest arrives at the realm’s SAML endpoint, Keycloak identifies the client from the request and, if that client is configured to require signed requests, verifies the signature. It then looks for the user’s identity cookie. If there is none, as is normal when an application sends the request directly to Keycloak, Keycloak falls back to the SessionIndex values in the message.
In 26.8.0 that fallback looked up the client session from each SessionIndex and compared its client with the client that sent the request. The comparison only decided whether to mark the sender’s own session as logged out. Whether it matched or not, the code went on to call a back-channel logout for the whole user session, so the comparison existed but blocked nothing.
The change in 26.8.1, visible in the SamlService.java diff between the two tags, turns the comparison into a rejection. If the session in the SessionIndex belongs to a different client, Keycloak logs a warning, sets the event reason to session_index_not_owned_by_issuer, and returns a bad request response without ending anything.
How serious is it, and what does an attacker need?
It is a real authorization gap with preconditions that limit who can use it, and we would rather list them than guess at a severity:
- A request has to be accepted as coming from a known client. The message names a client by its issuer. SAML clients created through the admin console or import require signed requests by default (the setting is “Client signature required”), and Keycloak checks the signature first when it is on. The easy case therefore needs a client where someone has turned the requirement off, and for such a client anyone who knows its client ID can send a request in its name.
- The sender needs a valid SessionIndex. It contains a user session ID and a client ID. The user session ID is not a closely guarded secret: Keycloak also uses it as the
sidclaim in tokens, and a SAML client learns it for every user who signs in to that client. The attacker also needs the ID of a client that is part of the target session, which is an identifier and not a secret but is not something an outsider reads from a public page. - The outcome is an availability one. A user is signed out of their single sign-on session. Nobody gains access to an account from this bug.
That makes it most relevant to realms where many SAML clients, sometimes run by different teams or customers, share one identity provider, and where at least one client does not require signed requests.
How does it differ from other SAML fixes?
It is a different class of problem from the signature and assertion bugs in our overview of Keycloak SAML exploits and mitigations, which concern forged login assertions and XML signature handling. Here a session is ended; nobody gains access.
What should you do?
- Upgrade to 26.8.1 or later, then test logout for each SAML client. After the change, a LogoutRequest is refused with a bad request if any SessionIndex in it belongs to another client. An application that was sending a SessionIndex it did not receive from its own login would have relied on the old behavior, so run a logout from every integration and confirm it still works. Keycloak also ships point releases on older lines (for example 26.4.15 and 26.6.6 on 11 August 2026), so check the release notes for your line instead of assuming either way.
- Audit “Client signature required”. Open each SAML client and confirm it is on unless the application truly cannot sign. Look especially at clients created long ago or by script.
- Keep and watch error events. Event saving is off by default in a new realm, so turn it on first. After the upgrade, search for the error
invalid_logout_requestwith the reasonsession_index_not_owned_by_issuer. A burst of them means some client is sending SessionIndex values that are not its own, which is occasionally a misconfigured application and sometimes someone probing. - Before the upgrade, look for unexplained logouts. If users report being signed out of one application when they used another, compare the timing against back-channel logout events. Our guide to Keycloak event logging and auditing lists the events to query.
Frequently asked questions
What is a SAML SessionIndex?
It is an identifier an identity provider puts in the login assertion so that a later LogoutRequest can say which session it means. Keycloak composes it from the user session ID and the internal client ID, separated by ::.
Can anyone on the internet end any user’s session through this?
Not based on the code we read. The request has to be accepted as coming from a known client, which includes a signature check if that client requires one, and it has to carry a user session ID and a client ID from the target session.
Does this let someone log in as another user?
No. The change concerns ending sessions only.
Is there a CVE for this?
We have not seen one assigned and do not want to guess.
Is single logout reliable enough to depend on?
Single logout is known to be fragile across vendors, because every application has to receive and honor the request. Treat it as a convenience and keep session lifetimes short enough that a missed logout does not leave a session open for long.