KeycloakApplication · Redhat

CVE-2022-3916

MEDIUM · 6.8 CVSS v3.1 Published 2023-09-20
Fix available
A fix is available. Upgrade to 20.0.2 or later.
See remediation →
74/100
Remediation priority · Elevated
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
A flaw was found in the offline_access scope in Keycloak. This issue would affect users of shared computers more (especially if cookies are not cleared), due to a lack of root session validation, and the reuse of session ids across root and user authentication sessions. This enables an attacker to resolve a user session attached to a previously authenticated user; when utilizing the refresh token, they will be issued a token for the original user.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · moderate confidence

A flaw in Keycloak's offline_access scope allows session hijacking due to lack of root session validation and session ID reuse across root and user authentication sessions. An attacker on a shared computer can use a refresh token to obtain tokens for a previously authenticated user.

MitigationEnsure cookies and sessions are cleared after use on shared computers; implement proper root session validation in Keycloak authentication flows; ensure session IDs are not reused across root and user sessions.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
KeycloakApplication
Affected:< 20.0.2
Single Sign OnApplication
Affected:all versions= 7.6
Openshift Container PlatformApplication
Affected:= 4.9= 4.10
Openshift Container Platform For LinuxoneApplication
Affected:= 4.9= 4.10
Openshift Container Platform For PowerApplication
Affected:= 4.9= 4.10
Openshift Container Platform Ibm Z SystemsApplication
Affected:= 4.9= 4.10

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
High
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify the Keycloak version
    Retrieve the installed Keycloak version through the server administration interface or by querying the server's version endpoint
    Affected if The installed version is earlier than 20.0.2 for Red Hat Keycloak, or matches the affected OCP versions (4.9 or 4.10) when Keycloak is deployed on those platforms
  2. Confirm offline_access scope is enabled
    In the Keycloak admin console, navigate to the realm settings and inspect the client scopes or authentication flows to determine if the offline_access scope is configured and active
    Affected if The offline_access scope is enabled for any client or realm, allowing offline token issuance
  3. Verify refresh token usage
    Inspect token configuration in the realm settings to confirm that refresh tokens are being issued to clients
    Affected if Refresh tokens are being issued and can be used to obtain new access tokens after the original session has ended
  4. Check session configuration for root session validation
    Review the authentication flows and session settings in the realm to determine whether root session validation is implemented
    Affected if Root session validation is not explicitly configured or is absent from the authentication flows, allowing session ID reuse between root and user sessions
  5. Examine shared computer session handling
    Review the realm and client settings to determine if there are policies for clearing sessions or preventing token reuse across different user sessions on the same client
    Affected if There is no enforcement of session uniqueness or cookie/session clearing between users on shared clients

A user is affected if their Keycloak version is below 20.0.2, the offline_access scope is enabled, and the environment lacks proper root session validation to prevent session ID reuse across root and user authentication sessions.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 20.0.2 or later
Fixed in 20.0.2
Interim mitigation

Ensure cookies and sessions are cleared after use on shared computers; implement proper root session validation in Keycloak authentication flows; ensure session IDs are not reused across root and user sessions.

Recommended fix High confidence

Keycloak 20.0.2 or later; Red Hat Single Sign On 7.6.x with latest RHSA; OpenShift Container Platform 4.9.x and 4.10.x with latest errata

  1. 1. For Keycloak standalone installations: Upgrade Keycloak server to version 20.0.2 or later. This is the primary fix for the session fixation vulnerability in the offline_access scope.
  2. 2. For Red Hat Single Sign On 7.6: Apply the latest Red Hat Security Advisory (RHSA) for RH-SSO. Check access.redhat.com for the specific RHSA number and apply the update via 'yum update' or the Red Hat Satellite management console.
  3. 3. For OpenShift Container Platform 4.9 and 4.10: Apply the corresponding OpenShift errata updates. Check access.redhat.com for OCP security advisories (RHSA) specific to your OCP version and apply via 'oc adm upgrade' or the cluster management console.
  4. 4. After patching: Clear all existing sessions and tokens. Instruct users to re-authenticate to obtain new session identifiers.
  5. 5. Validate the fix: Verify that new offline tokens are generated with unique session IDs and that root session and user authentication sessions use separate identifiers.
Caveat Upgrading Keycloak may require checking compatibility of custom themes, providers, or integrations; OCP upgrades may require maintenance windows and should be tested in non-production first

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Keycloak Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing4.0 h
  • Review / QA2.0 h
15.0 hours of engineering $2,640
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,224.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2022-3916 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2022-3916 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data