CVE-2023-6787 is a medium severity (CVSS 6.5) flaw in Keycloak's re-authentication flow. Triggering a new login with prompt=login and then choosing Restart login can leave a new session sharing the earlier session's SID, which may allow account takeover. Apply the Red Hat or upstream Keycloak update.
What's affected
The record lists Red Hat build of Keycloak and Red Hat Keycloak products, and points to Red Hat errata RHSA-2024:1867 and RHSA-2024:1868. Those errata pages did not load for automated reading, so exact fixed versions are not restated here. Use the errata and the Red Hat CVE page to match your product stream.
If you run community Keycloak rather than the Red Hat build, check the upstream release notes and security advisories for the fixed release in your branch.
How to check if you're exposed
Find the version of each Keycloak server you run.
/opt/keycloak/bin/kc.sh --version
On containers, read the image tag or run the same command in the container. Compare the version against the errata listed on the Red Hat CVE page. Include development and staging instances that share a realm with production users.
What to do now
- Apply the vendor update for your Keycloak stream, using RHSA-2024:1867 or RHSA-2024:1868 where they match your product.
- Restart the service and confirm the new version.
- After patching, consider ending active sessions for high-value accounts.
- Watch authentication logs for sessions where a subject changes under a session id you expected to stay stable.
Why it matters
The description says the error sits in the re-authentication mechanism in org.keycloak.authentication. When a new authentication is forced and the user cancels it, the new session, which has a different subject, ends up with the same session id as the previous one. In plain terms, one person's session identifier is tied to another person's identity.
The record tags CWE-287, improper authentication. Session identifiers are the thread that holds an identity together. Any flow that restarts, reuses or cancels authentication has to be tested for what happens to that identifier, including the unhappy paths.
Base libraries reach your estate by many routes: operating system packages, container base images and statically linked builds. Update the source of each route, not only the host you checked first. Rebuild images, restart long-running processes, and verify afterward with a fresh scan.
Weakness class in the record: CWE-287 (Improper Authentication).
Quick check
Why is this medium if it can lead to account takeover?
The score reflects the conditions needed. The description requires a specific re-authentication sequence. Rating and impact are both worth reading together, and a central identity provider deserves a fast patch regardless.
How do I know all my images and hosts are covered?
Scan every image and host for the affected package and version. Images built before the fix keep the old library until they are rebuilt, and running processes keep it until they restart.
Sources
Last reviewed: 19 October 2026.