Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
6.9
Gogs API: Access Tokens Can Be Exposed in URLs
CVE-2026-26196
GHSA-x9p5-w45c-7ffc
Summary
The Gogs API still allows access tokens to be passed in URLs, which can be seen in logs, browser history, and referrer headers. This can lead to unauthorized access if someone discovers or intercepts the token. To fix this, use authentication headers instead of URLs to pass tokens, and consider blocking URL parameters at your proxy or web application firewall.
What to do
No fix is available yet. Check with your software vendor for updates.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| gogs.io | gogs | <= 0.13.3 | – |
| gogs | gogs | <= 0.14.2 | – |
Original title
Gogs: Access tokens get exposed through URL params in API requests
Original description
### 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 `Authorization` header 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.
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 `Authorization` header 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.
nvd CVSS3.1
5.3
nvd CVSS4.0
6.9
Vulnerability type
CWE-598
- https://github.com/gogs/gogs/commit/295bfba72993c372e7b338438947d8e1a6bed8fd Patch
- https://github.com/gogs/gogs/pull/8177 Issue Tracking
- https://github.com/gogs/gogs/releases/tag/v0.14.2 Release Notes
- https://github.com/gogs/gogs/security/advisories/GHSA-x9p5-w45c-7ffc Vendor Advisory Mitigation
- https://nvd.nist.gov/vuln/detail/CVE-2026-26196
- https://github.com/advisories/GHSA-x9p5-w45c-7ffc
Published: 5 Mar 2026 · Updated: 11 Mar 2026 · First seen: 6 Mar 2026