Gogs has an Authorization Bypass Allows Cross-Repository Label Modification in Gogs

Summary

A broken access control vulnerability in Gogs allows authenticated users with write access to any repository to modify labels belonging to other repositories. The UpdateLabel function in the Web UI (internal/route/repo/issue.go) fails to verify that the label being modified belongs to the repository specified in the URL path, enabling cross-repository label tampering attacks.

Details

The vulnerability exists in the Web UI's label update endpoint POST /:username/:reponame/labels/edit. The handler function UpdateLabel uses an incorrect database query function that bypasses repository ownership validation:

Vulnerable Code (internal/route/repo/issue.go:1040-1054):

func UpdateLabel(c *context.Context, f form.CreateLabel) {
    l, err := database.GetLabelByID(f.ID)  // ❌ No repository validation
    if err != nil {
        c.NotFoundOrError(err, "get label by ID")
        return
    }

    // ❌ Missing validation: l.RepoID != c.Repo.Repository.ID
    l.Name = f.Title
    l.Color = f.Color
    if err := database.UpdateLabel(l); err != nil {
        c.Error(err, "update label")
        return
    }
    c.RawRedirect(c.Repo.MakeURL("labels"))
}

Root Cause:

1. The function calls database.GetLabelByID(f.ID) which internally passes repoID=0 to the ORM layer
2. According to code comments in internal/database/issue_label.go:147-166, passing repoID=0 causes the ORM to ignore repository restrictions
3. No validation checks whether l.RepoID == c.Repo.Repository.ID before updating
4. The middleware reqRepoWriter() only validates write access to the repository in the URL path, not the label's actual repository

Inconsistency with Other Functions:

• NewLabel: Correctly sets RepoID = c.Repo.Repository.ID
• DeleteLabel: Correctly uses database.DeleteLabel(c.Repo.Repository.ID, id)
• API EditLabel: Correctly uses database.GetLabelOfRepoByID(c.Repo.Repository.ID, id)

• Only UpdateLabel in Web UI uses the vulnerable pattern

PoC