Listen to this Post
How CVE-2026-52804 Works
CVE-2026-52804 is an off-by-one vulnerability in Gogs that allows a repository admin collaborator to escalate their privileges to owner level.
The root cause lies in the `ChangeCollaborationAccessMode` function within `internal/database/repo_collaboration.go` at line 129. The function is responsible for updating a collaborator’s access mode on a repository. It performs input validation with the following check:
if mode <= AccessModeNone || mode > AccessModeOwner {
return nil
}
In Gogs, `AccessModeOwner` has a constant value of 4. The validation intends to reject any mode that is invalid or exceeds owner-level access. However, the condition `mode > AccessModeOwner` evaluates to 4 > 4, which is false. This means that when an attacker supplies `mode=4` (the value for AccessModeOwner), the check passes, and the function proceeds to update the collaboration record.
The web route responsible for handling this request is located in `internal/route/repo/setting.go` at lines 413–416. This endpoint takes the `mode` parameter directly from the query string as a raw integer and passes it to the vulnerable function without any additional validation:
func ChangeCollaborationAccessMode(c context.Context) {
if err := c.Repo.Repository.ChangeCollaborationAccessMode(
c.QueryInt64("uid"),
database.AccessMode(c.QueryInt("mode"))); err != nil {
An authenticated repository admin (who normally has AccessModeAdmin = 3) can send a POST request to the collaboration settings endpoint with mode=4. Because the input validation fails to reject this value, the function updates the database, setting the collaborator’s permission to owner level.
The impact is persistent: the `access` table is updated at line 181, meaning the escalated permissions survive across sessions. This is particularly dangerous because Gogs’ permission system uses `IsOwner()` defined as `AccessMode >= Owner` for many sensitive operations. The attacker gains the ability to delete the repository, transfer ownership, erase wiki data, and perform all other owner-only operations.
Notably, the API route at `internal/route/api/v1/repo_collaborators.go:46` uses ParseAccessMode(), which only returns Read, Write, or Admin—never Owner. The API endpoint is therefore not affected by this vulnerability.
The correct fix is to change the validation condition from `mode > AccessModeOwner` to mode >= AccessModeOwner, ensuring that owner-level access is properly rejected for collaborators.
DailyCVE Form:
Platform: ……. Gogs
Version: …….. prior to 0.14.3
Vulnerability :…… Off-by-one privilege escalation
Severity: ……. Low (CVSS v4.0: 4.0)
date: ………. June 19, 2026
Prediction: …… Patch released 2026-06-07
What Undercode Say:
Analytics of CVE-2026-52804
The vulnerability stems from a classic off-by-one error where the boundary check `mode > AccessModeOwner` fails to reject the exact value of AccessModeOwner. This pattern is a common source of security bugs in access control systems.
The vulnerable code path is exposed through the web UI only—the API route remains safe because it uses ParseAccessMode(), which explicitly never returns Owner. This discrepancy between web and API validation creates an inconsistent security posture.
The attack requires the attacker to already be a repository admin, which limits the initial access but makes the escalation highly impactful. The persistence of the escalation (database update) means that simply logging out and back in does not revoke the gained privileges.
A complete fix requires not only correcting the boundary check but also ensuring that all entry points to the collaboration access update functionality converge to the same validation logic. The patch was released in Gogs version 0.14.3 on June 7, 2026.
Exploit:
To reproduce the vulnerability, an attacker must first be added as a collaborator with Admin access (mode=3) to a private repository. The attacker then sends a POST request to the collaboration settings endpoint:
POST /{owner}/{repo}/settings/collaboration/access_mode?uid={B_uid}&mode=4
Example using `curl`:
curl -X POST "https://gogs.example.com/user/repo/settings/collaboration/access_mode?uid=123&mode=4" \ -H "Cookie: session=..." \ -H "X-Csrf-Token: ..."
After successful exploitation, the attacker’s dashboard will show the “Danger Zone” section with “Delete This Repository” and “Transfer Ownership” buttons. The `access` table in the database will reflect the owner-level permission.
Verification – The following Go code snippet demonstrates the vulnerability:
// Vulnerable validation in internal/database/repo_collaboration.go:129
if mode <= AccessModeNone || mode > AccessModeOwner { // 4 > 4 = false
return nil
}
// mode=4 passes through and grants owner access
The attacker can then perform owner-only operations such as:
Transfer repository ownership
POST /{owner}/{repo}/settings/transfer
Delete repository
POST /{owner}/{repo}/settings/delete
Erase wiki data
POST /{owner}/{repo}/wiki/erase
Protection:
Immediate Mitigation:
- Upgrade to Gogs version 0.14.3 or later, which contains the patch
- If immediate upgrade is not possible, manually apply the fix by changing line 129 in
internal/database/repo_collaboration.go:</li> <li>if mode <= AccessModeNone || mode > AccessModeOwner {</li> <li>if mode <= AccessModeNone || mode >= AccessModeOwner {
Long-term Recommendations:
- Enforce upper-bound constraints at the model or service layer to ensure `mode <= admin` for collaborator updates
- Ensure all entry points (web UI, API, internal services) converge to the same validation logic
- Do not rely on frontend constraints for security—always validate on the server side
- Avoid direct model-level writes without policy enforcement
- Consider using a centralized permission validation function that is called from all entry points
Impact:
Successful exploitation of CVE-2026-52804 allows a repository admin collaborator to escalate to owner-level access.
The attacker gains the ability to perform all owner-only operations:
– Delete the repository entirely
– Transfer repository ownership to another user
– Archive or unarchive the repository
– Delete wiki data
– Cancel repository transfers
– Modify repository settings that are restricted to owners
The escalated permissions persist across sessions because the `access` table is updated directly in the database.
This vulnerability effectively breaks the intended privilege boundary where collaborator permissions should not exceed admin level. The attack requires only that the attacker is already a repository admin, making it a serious risk for any Gogs instance where admin collaborators are trusted but not fully vetted.
The issue affects the web route for collaboration settings, while the API route that uses `ParseAccessMode()` is not affected. This inconsistent validation highlights the importance of using a unified authorization layer across all application entry points.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
