Skip to content

GHSA-pwx3-qcgw-vh7h CVE-2026-52800 GO-2026-5556

Gogs Vulnerable to CSRF Leading to Organization Owner Takeover

High Go
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

  1. Prepare a target user account to be added (e.g., attacker).

  2. Confirm that the victim user is an owner of the target organization (e.g., org3) and is logged in.

  3. 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" />

  1. After the request completes, verify that the attacker user can access:

    http://localhost:10880/org/org3/settings
    

    confirming 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

PackageVulnerableFixed 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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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
Is this in your code?

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