Skip to content

Gitea: Cross-repository label-ID enumeration oracle via unscoped DeleteIssueLabel API

Low severity GitHub Reviewed Published Jul 13, 2026 in go-gitea/gitea

Package

gomod code.gitea.io/gitea (Go)

Affected versions

< 1.27.0

Patched versions

1.27.0

Description

Summary

The API endpoint DELETE /repos/{owner}/{repo}/issues/{index}/labels/{id} loads the label by ID with a global,
unscoped
lookup and never verifies the label belongs to the URL's repository (or its owning organization). Because
the response status differs by whether the label ID exists anywhere on the instance (204) versus not (422), an
authenticated user can use the endpoint as a cross-repository label-ID existence / enumeration oracle, including
for labels in repositories and organizations they cannot access.

Severity

  • The leaked information is minimal (existence/count of label IDs instance-wide); no label name, color, or owning
    repository is disclosed, and no cross-repository write occurs.

Affected / patched versions

  • Affected: through 1.26.3 (latest at time of report).
  • Patched: none yet.

Details

DeleteIssueLabel resolves the label with a global loader and never checks its scope:

// routers/api/v1/repo/issue_label.go  (DeleteIssueLabel)
label, err := issues_model.GetLabelByID(ctx, ctx.PathParamInt64("id"))   // global, unscoped

GetLabelByID (models/issues/label.go) is e.ID(labelID).Get(l) with no repo_id / org_id filter. The
handler never verifies label.RepoID == ctx.Repo.Repository.ID (nor the org-label equivalent), and the downstream
issue_service.RemoveLabel (services/issue/label.go) only re-checks the doer's write permission on the issue's
own
repository — never that the label belongs to it.

Every sibling label handler is correctly scoped — GetLabel / EditLabel / DeleteLabel (repo and org) use
GetLabelInRepoByID / GetLabelInOrgByID and return 404 for a foreign ID. DeleteIssueLabel is the only outlier.

Why it is only an oracle: deleteIssueLabel (models/issues/issue_label.go) deletes the issue_label row keyed
by (issue.ID, label.ID). For a foreign label, no such row exists → the function returns early before any
mutation or comment creation. So there is no cross-repo write and no leak of the label's name. But the HTTP status
differs:

  • label ID exists anywhere on the instance (incl. private repos/orgs) → 204 No Content
  • label ID does not exist → 422 (ErrLabelNotExist)

Label IDs are sequential auto-increment, so this enumerates the instance-wide label population and probes existence
of specific IDs across tenant boundaries.

Proof of Concept

Verified end-to-end on a build of the v1.26.3 tag.

  • alice (private repo alice/secret) creates a label → internal id 1.
  • Attacker bob (separate user; public repo bob/pub with issue #1; no access to alice/secret) holds a token
    with write:issue on his own repo.
bob DELETE /api/v1/repos/bob/pub/issues/1/labels/1          -> HTTP 204   (alice's PRIVATE label id exists)
bob DELETE /api/v1/repos/bob/pub/issues/1/labels/99999999   -> HTTP 422   (no such label)

Differing only by the label ID: 204 vs 422 distinguishes "label ID exists" from "does not exist." bob has zero rights to alice/secret but can still learn label id 1 exists. (Alice's label is untouched — no write.)

Reproduction steps:

  1. Create two users alice, bob. As alice, create a private repo and a label on it (note the label id from
    the API response).
  2. As bob, create any repo with an issue, and a token with write:issue.
  3. curl -u bob:$T -X DELETE https://<gitea>/api/v1/repos/bob/pub/issues/1/labels/<alice_label_id>204.
  4. curl -u bob:$T -X DELETE https://<gitea>/api/v1/repos/bob/pub/issues/1/labels/99999999422.
  5. The differing status across an ID bob cannot otherwise see is the oracle.

Impact

Cross-tenant authorization-key bypass producing a label-ID existence/enumeration oracle: an authenticated user can
determine whether arbitrary label IDs (including in private repositories and organizations they cannot access) exist,
and enumerate the instance-wide label population.

Remediation

Scope the loader like every sibling handler, returning 404 for a label that is not in the URL repository (or its
owning organization), so the status no longer distinguishes existence:

// routers/api/v1/repo/issue_label.go — in DeleteIssueLabel, after loading the label
if label.RepoID != ctx.Repo.Repository.ID && label.OrgID != ctx.Repo.Repository.OwnerID {
    ctx.APIErrorNotFound()
    return
}

(Equivalently, resolve via GetLabelInRepoByID and, for org repositories, also accept the repo owner's org labels —
mirroring the scoping in GetLabel/EditLabel/DeleteLabel.)

References

@bircni bircni published to go-gitea/gitea Jul 13, 2026
Published to the GitHub Advisory Database Jul 21, 2026
Reviewed Jul 21, 2026

Severity

Low

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
High
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
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:H/UI:N/S:U/C:L/I:N/A:N

EPSS score

Weaknesses

Observable Discrepancy

The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not. Learn more on MITRE.

Authorization Bypass Through User-Controlled Key

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. Learn more on MITRE.

CVE ID

CVE-2026-58445

GHSA ID

GHSA-pgqf-926r-548m

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.