CVE-2026-26196: Sensitive API Token Exposure via URL Query Parameters in Gogs

Gogs is a widely deployed, self-hosted Git service written in Go. In versions prior to 0.14.2, the application's API authentication logic failed to adhere to secure transport standards for sensitive credentials. Specifically, the API accepted authentication tokens passed directly in the URL query string using parameters named token or access_token.

This implementation violates standard security practices defined in CWE-598 (Information Exposure Through Query Strings in GET Request). While convenient for quick scripting, passing secrets in the URL places them in components of the HTTP request that are not intended to be confidential. Unlike the HTTP Body or Headers, the Request Line (URI) is routinely logged in cleartext by web servers, proxies, and security appliances.

The vulnerability is classified as a passive information leak. It does not allow an attacker to break into the system directly via a crafted packet, but rather ensures that valid credentials are persistently recorded in locations accessible to a wider audience than intended, such as system administrators, log analysis tools, or attackers with local file inclusion (LFI) capabilities.

The root cause of this vulnerability lies in the authenticatedUserID function within internal/context/auth.go. This function is responsible for determining the identity of the user making an API request. The logic explicitly checked the URL query string for authentication material before checking standard HTTP headers.

The vulnerable code prioritized ease of use over security. When an API request was received, the application checked c.Query("token"). If that was empty, it checked c.Query("access_token"). Only if both were missing did the application proceed to inspect the Authorization header. This precedence encouraged users and client libraries to use the insecure query string method.

Because the token retrieval occurred early in the request lifecycle, the full URL—including the sensitive token—would be processed by the Go net/http stack and any reverse proxies (like Nginx or Apache) sitting in front of the Gogs instance. Standard logging configurations for these servers default to the Combined Log Format, which includes the requested resource path and query string.

The remediation for CVE-2026-26196 involved removing the logic that parsed tokens from the query string entirely. The patch enforces the use of the Authorization header, which is the standard mechanism for bearer token authentication and is rarely logged by default.

Below is the analysis of the changes in internal/context/auth.go from commit 295bfba72993c372e7b338438947d8e1a6bed8fd:

Vulnerable Implementation (Pre-0.14.2):

// internal/context/auth.go
 
func authenticatedUserID(store AuthStore, c *macaron.Context, sess session.Store) int64 {
    // ...
    if isAPIPath(c.Req.URL.Path) {
        // VULNERABILITY: Tokens extracted from URL query
        tokenSHA := c.Query("token")
        if len(tokenSHA) <= 0 {
            tokenSHA = c.Query("access_token")
        }
        if tokenSHA == "" {
            // Only checks header if query params are empty
            auHead := c.Req.Header.Get("Authorization")
            // ...
        }
    }
}

Patched Implementation (v0.14.2):

// internal/context/auth.go
 
func authenticatedUserID(store AuthStore, c *macaron.Context, sess session.Store) int64 {
    // ...
    if isAPIPath(c.Req.URL.Path) {
        var tokenSHA string
        // FIX: Query string checks removed entirely.
        // Authentication now strictly requires the Authorization header.
        auHead := c.Req.Header.Get("Authorization")
        if auHead != "" {
            auths := strings.Fields(auHead)
            if len(auths) == 2 && auths[0] == "token" {
                tokenSHA = auths[1]
            }
        }
        // ...
    }
}

By removing the calls to c.Query, the maintainers eliminated the attack surface. Any client attempting to use the old query parameter method will now receive a 401 Unauthorized response, forcing the adoption of the secure header method.

The exploitation of this vulnerability relies on an attacker gaining access to historical request data. Several vectors exist for this leakage:

1. Server Logs: Access logs (e.g., /var/log/nginx/access.log) retain the full request URI. An attacker who gains read access to these logs—perhaps via a separate Directory Traversal vulnerability or misconfigured permissions—can harvest valid tokens.
2. Proxy & SIEM Logs: In enterprise environments, traffic often passes through transparent proxies or is forwarded to SIEM solutions (Splunk, ELK). If these systems are not configured to redact sensitive query parameters, the tokens become indexed and searchable by security analysts or attackers who compromise the logging infrastructure.
3. Referer Headers: If a user visits a URL like https://gogs.local/api/v1/repos?token=XYZ and the API response contains a link to an external site, clicking that link may send the full URL (containing the token) in the Referer header to the external server.

Impact Assessment: The compromise of a Gogs API token is equivalent to compromising the user's password for API operations. Depending on the scope of the token and the user's privileges, an attacker could:

• Clone private repositories (Intellectual Property theft).
• Push malicious code to repositories (Supply Chain Attack).
• Modify issue trackers or wiki pages.
• If the user is an administrator, the attacker could potentially gain full control over the Gogs instance.

The primary remediation is to upgrade the Gogs instance to version 0.14.2 or later immediately. This version drops support for query-based authentication, neutralizing the vulnerability.

Critical Post-Upgrade Step: Token Rotation Upgrading the software stops future leaks, but it does not invalidate tokens that have already been logged. Security teams must assume that all tokens used prior to the upgrade are compromised. Users should be forced or instructed to revoke existing Personal Access Tokens and generate new ones.

Log Sanitization Administrators should scan existing web server and proxy logs for patterns matching token= or access_token=. These logs should be scrubbed or deleted to prevent historical data mining by attackers. Future logging configurations should be reviewed to ensure query strings are either excluded or sanitized of sensitive keys.