GHSA-pwx3-qcgw-vh7h CVE-2026-52800 GO-2026-5556
Gogs Vulnerable to CSRF Leading to Organization Owner Takeover
- Severity
- 8.8 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.25%
- Chance of exploitation in the next 30 days. Higher than 16.19% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-352 Cross-Site Request Forgery (CSRF)
- Fix
0.14.3- Upgrade gogs.io/gogs to this version or later
Description
Summary
In Gogs 0.14.1, organization team member management can be performed via GET requests without CSRF protection. If a victim who is an organization owner is logged in and is tricked into visiting a crafted link, an attacker-controlled user can be added to the Owners team. As a result, the attacker gains organization owner–equivalent privileges.
Description
When a victim is logged in as an organization owner, team member management endpoints are exposed via routes reachable by GET requests, allowing state-changing operations without a CSRF token.
Team action route allows GET
internal/cmd/web.go:390
m.Route("/teams/:team/action/:action", "GET,POST", org.TeamsAction)
CSRF validation is applied only to POST requests
Because the global CSRF check is limited to POST requests, state-changing operations reached via GET bypass CSRF protection entirely.
internal/context/auth.go:56-61
if !options.SignOutRequired && !options.DisableCSRF &&
c.Req.Method == "POST" && !isAPIPath(c.Req.URL.Path) {
csrf.Validate(c.Context, c.csrf)
if c.Written() {
return
}
}
TeamsAction performs state changes regardless of HTTP method
TeamsAction does not branch on the HTTP method. Instead, it performs state-changing operations (such as adding or removing members) based solely on query parameters (uid, uname) and the :action path parameter.
Since the route explicitly allows GET, the add action can be executed via GET.
internal/route/org/teams.go:38-83
func TeamsAction(c *context.Context) {
uid := com.StrTo(c.Query("uid")).MustInt64()
if uid == 0 {
c.Redirect(c.Org.OrgLink + "/teams")
return
}
page := c.Query("page")
var err error
switch c.Params(":action") {
case "add":
if !c.Org.IsOwner {
c.NotFound()
return
}
uname := c.Query("uname")
var u *database.User
u, err = database.Handle.Users().GetByUsername(c.Req.Context(), uname)
// ...
err = c.Org.Team.AddMember(u.ID)
page = "team"
}
}
Adding a user to the Owners team grants organization owner privileges
When a user joins the Owners team, OrgUser.IsOwner is set to true. Therefore, adding a user to the Owners team directly results in granting organization owner–equivalent privileges.
internal/database/org_team.go:566-576
ou := new(OrgUser)
if _, err = sess.Where("uid = ?", userID).
And("org_id = ?", orgID).Get(ou); err != nil {
return err
}
ou.NumTeams++
if t.IsOwnerTeam() {
ou.IsOwner = true
}
if _, err = sess.ID(ou.ID).AllCols().Update(ou); err != nil {
return err
}
Related issue: organization member actions are also state-changing via GET
For reference, organization member management endpoints are also exposed as GET routes that perform state changes without CSRF protection.
internal/cmd/web.go:382
m.Get("/members/action/:action", org.MembersAction)
MembersAction similarly does not branch on HTTP method and performs state-changing operations (public/private toggle, remove, leave) based on query parameters and the :action path parameter.
internal/route/org/members.go:31-71
func MembersAction(c *context.Context) {
uid := com.StrTo(c.Query("uid")).MustInt64()
if uid == 0 {
c.Redirect(c.Org.OrgLink + "/members")
return
}
org := c.Org.Organization
var err error
switch c.Params(":action") {
case "private":
err = database.ChangeOrgUserStatus(org.ID, uid, false)
case "public":
err = database.ChangeOrgUserStatus(org.ID, uid, true)
case "remove":
err = org.RemoveMember(uid)
case "leave":
err = org.RemoveMember(c.User.ID)
}
}
Steps to Reproduce
-
Prepare a target user account to be added (e.g.,
attacker). -
Confirm that the victim user is an owner of the target organization (e.g.,
org3) and is logged in. -
Cause the victim’s browser to perform a top-level navigation to the following URL:
http://localhost:10880/org/org3/teams/owners/action/add?uid=1&uname=attacker
<img width="2019" height="322" alt="image" src="https://github.com/user-attachments/assets/342a627a-04e8-47bd-818a-9c2b05a75446" />
-
After the request completes, verify that the
attackeruser can access:http://localhost:10880/org/org3/settingsconfirming that organization owner privileges have been obtained.
<img width="2010" height="285" alt="image" src="https://github.com/user-attachments/assets/03945bb1-e9c5-4e42-ad3a-9f6d63b7d86d" />
<img width="2016" height="893" alt="image" src="https://github.com/user-attachments/assets/55d7db13-52cf-471b-a6d3-aa4186c8b547" />
Impact
Successful exploitation allows an attacker to obtain organization owner privileges, resulting in:
- Full control over organization repositories, settings, and members
- Unauthorized access to private repositories (confidentiality impact)
- Modification or deletion of repositories and settings (integrity impact)
- Repository deletion or disruption leading to service unavailability (availability impact)
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| gogs.io/gogs | < 0.14.3 |
0.14.3 |
| gogs.io/gogs | all versions |
No fix yet |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
gogs.io/gogs Go → 0.14.3
- go
go get gogs.io/gogs@v0.14.3 && go mod tidy
Severity breakdown
CVSS 3.1 8.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-352: Cross-Site Request Forgery (CSRF)
The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.
How to prevent it
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330] Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
- Implementation: Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.
- Architecture and Design: Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]
- Architecture and Design: Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.
- Architecture and Design: Use the "double-submitted cookie" method as described by Felten and Zeller: When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult. This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]
- Architecture and Design: Do not use the GET method for any request that triggers a state change.
- Implementation: Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| CVE-2026-50128 Mastodon is a free, open-source social network server based on ActivityPub. | Medium | Linked by the source |
| GHSA-mq8m-42gh-wq7r Gogs vulnerable to a bypass of CVE-2024-55947 | High Known exploited | Also affects gogs.io/gogs |
| GHSA-3w28-36p9-w929 Gogs's Unauthenticated Jupyter Notebook (ipynb) Sanitizer allows arbitrary data: URIs leading to XSS | Medium | Also affects gogs.io/gogs |
| GHSA-744x-3838-5r56 Gogs Vulnerable to Unauthenticated Organization Teams Information Disclosure via API | Medium | Also affects gogs.io/gogs |
| GHSA-xp79-5mx3-jx52 Gogs has Unauthenticated Asymmetric Denial of Service (DoS) via SSH Handshake Stall (File Descriptor Exhaustion) | Medium | Also affects gogs.io/gogs |
| GHSA-c39w-43gm-34h5 Gogs has Path Traversal in organization name that results in RCE through Git hooks | Critical | Also affects gogs.io/gogs |
| GHSA-6p9m-q3jp-47h4 Gogs: LFS dedupe path leaks private repo content across tenants | High | Also affects gogs.io/gogs |
| GHSA-89mr-xqfv-758m Gogs: UploadRepoFiles writes outside repo working tree via committed parent sym | Critical | Also affects gogs.io/gogs |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor