CVE-2026-52804: Gogs Privilege Escalation Vulnerability

CVE-2026-52804 Overview

CVE-2026-52804 is a privilege escalation vulnerability in Gogs, an open source self-hosted Git service. The flaw exists in the ChangeCollaborationAccessMode function and stems from an off-by-one error [CWE-193] in the access mode boundary check. A repository admin collaborator can exploit this issue to elevate their access from admin to owner level on a repository they collaborate on. The vulnerability affects all Gogs versions prior to 0.14.3 and is fixed in release 0.14.3.

Critical Impact
An authenticated admin collaborator can escalate to repository owner privileges, gaining full control over repository configuration, collaborator management, and destructive actions including deletion.

Affected Products

Gogs versions prior to 0.14.3
Self-hosted Gogs Git service instances
Gogs repository collaboration API endpoints

Discovery Timeline

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

Technical Details for CVE-2026-52804

Vulnerability Analysis

The vulnerability resides in the ChangeCollaborationAccessMode function defined in internal/database/repo_collaboration.go. The function validates a requested access mode against the boundary mode > AccessModeOwner, which permits values up to and including AccessModeOwner. Collaborators should be capped at AccessModeAdmin, but the off-by-one comparison allows the AccessModeOwner value to pass validation. An authenticated admin collaborator can therefore submit an API request that assigns owner-level access to themselves or another collaborator.

Beyond the boundary error, the original implementation did not constrain the granting actor to a level at or below their own access. The patch introduces a second check ensuring mode > actorMode is rejected, so an actor can never assign privileges higher than they hold. The flaw is consistent with [CWE-193: Off-by-one Error].

Root Cause

The root cause is an incorrect upper-bound comparison in the access mode validation logic. The check mode > AccessModeOwner should have been mode > AccessModeAdmin for collaborators. Combined with the absence of an actor-bound check, the function trusted client-supplied permission values without enforcing the role hierarchy of the calling user.

Attack Vector

Exploitation requires authentication as an admin collaborator on a target repository. The attacker issues an API call to the repository collaborators endpoint with a permission value that maps to AccessModeOwner. Because the API handler in internal/route/api/v1/repo_collaborators.go previously passed the parsed access mode directly to ChangeCollaborationAccessMode without supplying the actor's mode, the elevated value is accepted and persisted.

// Security patch in internal/database/repo_collaboration.go
// ChangeCollaborationAccessMode sets new access mode for the collaboration.
-func (r *Repository) ChangeCollaborationAccessMode(userID int64, mode AccessMode) error {
-	// Discard invalid input
-	if mode <= AccessModeNone || mode > AccessModeOwner {
+// The actor's access mode bounds the new mode, so an actor can never grant a
+// level higher than their own.
+func (r *Repository) ChangeCollaborationAccessMode(actorMode AccessMode, userID int64, mode AccessMode) error {
+	// Collaborators can hold at most admin access.
+	if mode <= AccessModeNone || mode > AccessModeAdmin {
+		return nil
+	}
+
+	// Actors must not grant a level above their own.
+	if mode > actorMode {
 		return nil
 	}

Source: GitHub Commit 1fdc9cc

The corresponding handler change passes the caller's access mode into the function so the actor bound is enforced:

// Security patch in internal/route/api/v1/repo_collaborators.go
 	if form.Permission != nil {
-		if err := c.Repo.Repository.ChangeCollaborationAccessMode(collaborator.ID, database.ParseAccessMode(*form.Permission)); err != nil {
+		if err := c.Repo.Repository.ChangeCollaborationAccessMode(c.Repo.AccessMode, collaborator.ID, database.ParseAccessMode(*form.Permission)); err != nil {
 			c.Error(err, "change collaboration access mode")
 			return
 		}

Source: GitHub Commit 1fdc9cc

Detection Methods for CVE-2026-52804

Indicators of Compromise

API requests to /api/v1/repos/{owner}/{repo}/collaborators/{collaborator} containing a permission value that resolves to owner-level access from non-owner accounts.
Audit log entries showing collaborator access mode changes to owner performed by an admin collaborator rather than the repository owner.
Unexpected repository ownership transfers or collaborator role expansions not initiated through the web UI.

Detection Strategies

Review Gogs application logs and reverse proxy access logs for PATCH or PUT requests to the collaborators API endpoint with elevated permission payloads.
Compare current collaborator roles against an authoritative baseline to surface accounts holding owner privileges that were never explicitly granted by the original repository owner.
Inspect the collaboration database table for mode values inconsistent with prior assignments or that exceed the expected AccessModeAdmin value for non-owners.

Monitoring Recommendations

Forward Gogs HTTP and audit logs to a centralized logging platform and alert on collaborator permission changes.
Monitor Git server hosts for the installed Gogs binary version and flag deployments still running versions prior to 0.14.3.
Track outbound Git push events from accounts whose access mode recently changed, which can indicate post-escalation activity.

How to Mitigate CVE-2026-52804

Immediate Actions Required

Upgrade Gogs to version 0.14.3 or later, which contains the fix for the off-by-one error and adds the actor-bound check.
Audit all repositories for unexpected owner-level collaborators and revoke any unauthorized assignments.
Restrict admin collaborator assignments to trusted accounts until the upgrade is completed.

Patch Information

The fix is included in Gogs release 0.14.3. The patch bounds collaborator access at AccessModeAdmin and adds an actor-mode parameter so the API handler enforces that an actor cannot grant a level higher than their own. Review the GitHub Security Advisory GHSA-4565-r4x7-hg8j, the GitHub Pull Request #8227, and the Gogs v0.14.3 Release Notes for full details.

Workarounds

Limit the assignment of the admin collaborator role to a minimal set of trusted users until patching is complete.
Place the Gogs collaborators API endpoint behind a reverse proxy rule that rejects requests with permission values mapping to owner-level access.
Implement periodic reconciliation scripts that reset any non-owner accounts holding owner-level access in the collaboration table.

bash

# Configuration example: upgrade Gogs to the patched release
# Stop the running Gogs service
sudo systemctl stop gogs

# Back up the data directory and database before upgrading
sudo tar -czf /backup/gogs-pre-0.14.3.tar.gz /home/git/gogs

# Download and install Gogs 0.14.3
wget https://github.com/gogs/gogs/releases/download/v0.14.3/gogs_0.14.3_linux_amd64.tar.gz
tar -xzf gogs_0.14.3_linux_amd64.tar.gz
sudo cp gogs/gogs /usr/local/bin/gogs

# Restart and verify the running version
sudo systemctl start gogs
gogs --version