CVE-2026-52810: Gogs Git Service Auth Bypass Vulnerability

CVE-2026-52810 Overview

CVE-2026-52810 is a broken access control vulnerability [CWE-284] in Gogs, an open source self-hosted Git service. Versions prior to 0.14.3 evaluate Git Smart HTTP authorization based on the client-supplied service query string rather than the actual HTTP route being invoked. A POST request to …/git-receive-pack with ?service=git-upload-pack is authorized as a read operation, yet the server still executes git receive-pack. This authorization confusion allows an authenticated user with read-only permissions to push commits to repositories where only read access should be granted. The issue is fixed in Gogs 0.14.3.

Critical Impact
Authenticated users with read-only repository access can push arbitrary commits, tampering with source code integrity across affected Gogs instances.

Affected Products

Gogs versions prior to 0.14.3
Self-hosted Gogs Git service deployments
Repositories exposed via Git Smart HTTP protocol

Discovery Timeline

2026-06-24 - CVE-2026-52810 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-52810

Vulnerability Analysis

Gogs implements the Git Smart HTTP protocol, which uses two endpoints: git-upload-pack for fetch/clone (read) operations and git-receive-pack for push (write) operations. Authorization should be tied to the HTTP route and method that the server actually dispatches. In affected versions, the access check inspected the service query parameter supplied by the client to determine whether the request was a pull or a push. An attacker can issue POST /<owner>/<repo>.git/git-receive-pack?service=git-upload-pack to make Gogs evaluate the request as read-only, while the router still hands the request body to git receive-pack, which writes objects and updates refs.

Root Cause

The root cause is a mismatch between the trusted source used for authorization and the trusted source used for dispatch. The access control function relied on a client-controlled query string instead of the server-side action derived from the HTTP path. This is a classic broken access control flaw [CWE-284] where the authorization decision and the operation actually performed disagree.

Attack Vector

Exploitation requires network access to a Gogs HTTP endpoint and valid credentials with at least read permission on a target repository. The attacker crafts a POST to the git-receive-pack path while setting ?service=git-upload-pack, then streams a standard pack file with the desired ref updates. No user interaction is required.

// Patch from internal/route/repo/http.go
// Source: https://github.com/gogs/gogs/commit/7c9cf53aca957959bcd98b0cc987d9901b7cb184

func gitHTTPIsPull(c *macaron.Context, action string) bool {
    if action == "info/refs" {
        return c.Query("service") != "git-receive-pack"
    }
    return action != "git-receive-pack"
}

func HTTPContexter(store Store) macaron.Handler {
    return func(c *macaron.Context) {
        if len(conf.HTTP.AccessControlAllowOrigin) > 0 {
            // ...
        }
    }
}

The fix derives the pull/push decision from the server-side action value. The service query string is only consulted for the info/refs advertisement endpoint, where Git clients legitimately use it to negotiate the operation.

Detection Methods for CVE-2026-52810

Indicators of Compromise

HTTP POST requests to /<owner>/<repo>.git/git-receive-pack containing the query string ?service=git-upload-pack.
Unexpected ref updates or new commits in repositories from accounts that only hold read permissions.
Git server access logs showing git-receive-pack invocations from users not listed as writers in repository ACLs.

Detection Strategies

Parse Gogs HTTP access logs for any request whose path ends in git-receive-pack while the query string contains service=git-upload-pack.
Correlate repository write events (ref updates, new objects) with the authenticated user's permission level on that repository.
Audit the Git reflog and repository history for pushes that do not match the expected committer set.

Monitoring Recommendations

Forward Gogs reverse proxy and application logs to a centralized log platform and alert on the query/path mismatch pattern described above.
Enable webhook or audit-log shipping for push events and review pushes from accounts with read-only roles.
Track running Gogs versions across the fleet and alert on instances below 0.14.3.

How to Mitigate CVE-2026-52810

Immediate Actions Required

Upgrade all Gogs instances to version 0.14.3 or later, which contains the authorization fix referenced in GHSA-wmfg-5p4h-5fw3.
Review repository histories and reflogs for unauthorized pushes performed since the affected versions were deployed.
Rotate any secrets, signing keys, or build artifacts that may have been tampered with via unauthorized commits.

Patch Information

The vulnerability is fixed in Gogs 0.14.3. The patch introduces the gitHTTPIsPull helper that derives the read/write decision from the dispatched action rather than the client-supplied service parameter. See the GitHub commit, the pull request review for #8331, and the v0.14.3 release notes.

Workarounds

Place a reverse proxy in front of Gogs that rejects requests where the path ends in git-receive-pack but the service query parameter is git-upload-pack.
Restrict Git Smart HTTP access to trusted networks or VPN users until patching is complete.
Temporarily disable HTTP-based Git access and require SSH, which uses a separate code path for authorization.

bash

# Example NGINX rule to block the mismatched request pattern
location ~ "/git-receive-pack$" {
    if ($arg_service = "git-upload-pack") {
        return 403;
    }
    proxy_pass http://gogs_backend;
}