Summary
Coder accepts an APIKey beyond the linked OIDC expiry if there is no refresh token
If users log in to Coder via OIDC, and the OpenID Identity Provider does not return a refresh token, then Coder may allow their web session to continue beyond the expiration of the token returned by the OpenID Identity Provider.
Details
When a user logs in via OIDC, Coder stores the OIDC token and refresh token (if any) in its datastore and sets an APIKey in the user's cookies. If there is a refresh token, then when the OIDC token is expired and a request is made with the APIKey, we attempt to refresh the OIDC token. If refresh fails, the Coder API request is also failed and the user needs to log in again.
However, if there is no refresh token provided, then affected versions of Coder fail to enforce the expiry of the OIDC token, and allow users to make API requests even if it is expired so long as their APIKey stored in cookies has not expired.
Coder APIKeys have an expiry and lifetime of 24 hours, but Coder is configured to extend the lifetime of the APIKey by up to 24 hours from the time it is used successfully. So, an APIKey that is used at least once every 24 hours will not expire. (This behavior can be disabled by configuration).
Impact
This could allow a user to access the Coder service beyond the lifetime of the token issued by the OpenID provider, potentially indefinitely, even if they are no loner authorized via OIDC.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-3RW9-WMC8-8948? GHSA-3RW9-WMC8-8948 is a low-severity security vulnerability in github.com/coder/coder/v2 (go), affecting versions < 2.23.0. It is fixed in 2.23.0.
- Which versions of github.com/coder/coder/v2 are affected by GHSA-3RW9-WMC8-8948? github.com/coder/coder/v2 (go) versions < 2.23.0 is affected.
- Is there a fix for GHSA-3RW9-WMC8-8948? Yes. GHSA-3RW9-WMC8-8948 is fixed in 2.23.0. Upgrade to this version or later.
- Is GHSA-3RW9-WMC8-8948 exploitable, and should I be worried? Whether GHSA-3RW9-WMC8-8948 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-3RW9-WMC8-8948 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-3RW9-WMC8-8948? Upgrade
github.com/coder/coder/v2to 2.23.0 or later.