Skip to content

Repo-side team-link endpoint still bypasses RepoAdminChangeTeamAccess

High
bircni published GHSA-g5jj-gp8w-73h7 Aug 29, 2026

Package

gomod code.gitea.io/gitea (Go)

Affected versions

<= 1.27.2

Patched versions

1.27.3

Description

Summary

PUT /api/v1/repos/{owner}/{repo}/teams/{team} allows a non-owner repository admin to attach organization teams to a repository even when the organization has disabled that behaviour with RepoAdminChangeTeamAccess=false. An earlier advisory fixed the corresponding team-side endpoint; the repository-side endpoint retained the weaker check.

Details

The repository-side handler's exception relies on a repository permission check (IsOwner()), which for an organization repository is satisfied by a user promoted to owner-level access through an attached admin team. The fixed team-side endpoint instead checks actual organization ownership when RepoAdminChangeTeamAccess is disabled. The matching web collaboration-settings handler had the same weak check.

Impact

A user with delegated admin rights on one organization repository can grant other organization teams read or write access to that repository without approval from an actual organization owner, exposing private source and history and, for a write-capable team, granting push access.

Affected versions

Gitea <= 1.27.2.

Patches

Fixed in Gitea 1.27.3 (#39046, #39058).

Workarounds

None. Upgrade to 1.27.3.

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

CVE ID

CVE-2026-60010

Weaknesses

Incorrect Privilege Assignment

A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor. Learn more on MITRE.

Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Learn more on MITRE.

Credits