GHSA-X9P5-W45C-7FFC
Vulnerability from github – Published: 2026-03-05 19:50 – Updated: 2026-03-06 00:58
VLAI?
Summary
Gogs: Access tokens get exposed through URL params in API requests
Details
Summary
The Gogs API still accepts tokens in URL parameters such as token and access_token, which can leak through logs, browser history, and referrers.
Details
A static review shows that the API still checks tokens in the URL query before looking at headers:
- internal/context/auth.go reads
c.Query("token") - internal/context/auth.go falls back to
c.Query("access_token") - internal/context/auth.go only checks the
Authorizationheader when the query token is empty - internal/context/auth.go authenticates using that token and marks the request as token-authenticated
Token-authenticated requests are accepted by API routes through c.IsTokenAuth checks:
- internal/route/api/v1/api.go
Impact
If tokens are sent in URLs such as /api/v1/user?token=..., they can leak in logs, browser or shell history, and referrer headers, and can be reused until revoked.
Recommended Fix
- Authentication headers should be used exclusively for token transmission.
- Token parameters should be blocked at the proxy or WAF level.
- Query strings should be scrubbed from logs.
- A strict referrer policy should be set.
Remediation
A fix is available at https://github.com/gogs/gogs/releases/tag/v0.14.2.
Severity ?
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "gogs.io/gogs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.13.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-26196"
],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T19:50:35Z",
"nvd_published_at": "2026-03-05T19:16:04Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe Gogs API still accepts tokens in URL parameters such as `token` and `access_token`, which can leak through logs, browser history, and referrers.\n\n### Details\n\nA static review shows that the API still checks tokens in the URL query before looking at headers:\n\n - internal/context/auth.go reads `c.Query(\"token\")`\n - internal/context/auth.go falls back to `c.Query(\"access_token\")`\n - internal/context/auth.go only checks the `Authorization` header when the query token is empty\n - internal/context/auth.go authenticates using that token and marks the request as token-authenticated\n\nToken-authenticated requests are accepted by API routes through `c.IsTokenAuth` checks:\n - internal/route/api/v1/api.go\n\n### Impact\n\nIf tokens are sent in URLs such as `/api/v1/user?token=...`, they can leak in logs, browser or shell history, and referrer headers, and can be reused until revoked.\n\n### Recommended Fix\n\n- Authentication headers should be used exclusively for token transmission.\n- Token parameters should be blocked at the proxy or WAF level.\n- Query strings should be scrubbed from logs.\n- A strict referrer policy should be set.\n\n### Remediation\n\nA fix is available at https://github.com/gogs/gogs/releases/tag/v0.14.2.",
"id": "GHSA-x9p5-w45c-7ffc",
"modified": "2026-03-06T00:58:07Z",
"published": "2026-03-05T19:50:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/security/advisories/GHSA-x9p5-w45c-7ffc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26196"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/pull/8177"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/commit/295bfba72993c372e7b338438947d8e1a6bed8fd"
},
{
"type": "PACKAGE",
"url": "https://github.com/gogs/gogs"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/releases/tag/v0.14.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Gogs: Access tokens get exposed through URL params in API requests"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
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.
Loading…
Loading…