CVE-2026-26196: 
Gogs vulnerability analysis and mitigation

CVE-2026-26196 is a credential exposure vulnerability in Gogs, an open-source self-hosted Git service, where the API accepts authentication tokens via URL query parameters (token and access_token), causing them to leak through server logs, browser history, and HTTP referrer headers. All Gogs versions prior to 0.14.2 are affected. The vulnerability was reported by researcher rezmoss, disclosed and patched on March 5, 2026. It carries a CVSS v3.1 score of 5.3 (Medium) and a CVSS v4.0 score of 6.9 (Medium) (GitHub Advisory).

The root cause is classified as CWE-598 (Use of GET Request Method With Sensitive Query Strings). In internal/context/auth.go, the Gogs API authentication logic first reads c.Query("token"), then falls back to c.Query("access_token"), and only checks the Authorization header if both query parameters are absent — meaning URL-based token authentication was a fully supported code path. Any API request made with tokens embedded in the URL (e.g., /api/v1/user?token=...) would expose those credentials in web server access logs, proxy logs, browser history, shell history, and Referer headers sent to third-party sites. The fix, implemented in PR #8177, removes the URL query parameter token lookup entirely, requiring tokens to be passed exclusively via the Authorization: token <value> header (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker who gains access to server logs, proxy logs, browser history, or referrer data to harvest valid API authentication tokens without requiring any privileges or user interaction. These harvested tokens can be reused until explicitly revoked to perform any API operation permitted to the token holder, including unauthorized repository access, data exfiltration, code modification, or other actions impersonating the affected user. There is no integrity or availability impact directly from the vulnerability itself, but the secondary misuse of stolen tokens could have significant consequences depending on the permissions associated with the compromised token (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The vulnerability requires no authentication, no user interaction, and is exploitable over the network, making it straightforward to abuse if an attacker has access to logs or referrer data. The EPSS score is approximately 0.045% (14th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Qualys has added detection for this CVE (GitHub Advisory).

1. Identify target: Locate a Gogs instance running a version prior to 0.14.2 that is accessible over the network.
2. Access log or referrer sources: Gain access to server access logs, reverse proxy logs (e.g., nginx, Apache), browser history on a shared or compromised machine, or monitor HTTP referrer headers if the Gogs instance links to external resources.
3. Extract token from URL: Search logs or history for API requests containing ?token= or ?access_token= query parameters, e.g., GET /api/v1/user?token=abc123def456.
4. Authenticate with harvested token: Use the extracted token to make authenticated API requests via the Authorization header or directly in the URL: curl -H "Authorization: token abc123def456" https://gogs.example.com/api/v1/user/repos.
5. Perform unauthorized actions: With the valid token, access repositories, exfiltrate code or secrets, modify content, or perform any action permitted by the token's scope until the token is revoked (GitHub Advisory, Patch Commit).

• Logs: Web server or proxy access logs containing Gogs API requests with ?token= or ?access_token= query parameters (e.g., GET /api/v1/user?token=<value> or GET /api/v1/repos?access_token=<value>).
• Logs: Unusual API activity from unexpected IP addresses using a valid token, particularly after the token appeared in a URL-based request.
• Network: Outbound HTTP requests from Gogs clients to third-party domains with Referer headers containing API URLs that include token query parameters.
• File System / History: Shell history files (.bash_history, .zsh_history) on systems where curl or similar tools were used with ?token= in Gogs API URLs.
• Application Behavior: API calls authenticated via token that originate from unfamiliar user agents or geographic locations, suggesting token reuse by an unauthorized party (GitHub Advisory).

Upgrade Gogs to version 0.14.2 or later, which removes support for URL query parameter token authentication entirely and requires tokens to be passed via the Authorization: token <value> header (Gogs Release). Note that a further patch release 0.14.3 is available and is recommended as the upgrade target. For installations that cannot patch immediately: configure reverse proxies or WAFs to strip or reject API requests containing token or access_token query parameters; scrub query strings from access logs; set a strict Referrer-Policy header; and revoke any tokens that may have been exposed in logs or history. All existing API tokens should be considered potentially compromised and rotated if URL-based authentication was in use (GitHub Advisory).