GHSA-3RW9-WMC8-8948
Vulnerability from github – Published: 2025-08-28 19:36 – Updated: 2025-08-28 19:36Summary
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": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-324"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-28T19:36:04Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\nIf 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.\n\n### Details\nWhen 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\u0027s 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.\n\nHowever, 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.\n\nCoder 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). \n\n### Impact\nThis 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.",
"id": "GHSA-3rw9-wmc8-8948",
"modified": "2025-08-28T19:36:05Z",
"published": "2025-08-28T19:36:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/coder/coder/security/advisories/GHSA-3rw9-wmc8-8948"
},
{
"type": "WEB",
"url": "https://github.com/coder/coder/commit/1a4160803589034ce1518e24a78f232c8d08f996"
},
{
"type": "PACKAGE",
"url": "https://github.com/coder/coder"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Coder accepts an APIKey beyond the linked OIDC expiry if there is no refresh token"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.