GHSA-pgqf-926r-548m
LOWGHSA-pgqf-926r-548m is a low-severity (CVSS 2.7) CWE-203 vulnerability in code.gitea.io/gitea. O3 Security confirms whether GHSA-pgqf-926r-548m is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gitea: Cross-repository label-ID enumeration oracle via unscoped DeleteIssueLabel API
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-pgqf-926r-548m plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 0 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
code.gitea.io/giteaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
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 repoalice/secret) creates a label → internal id 1.- Attacker
bob(separate user; public repobob/pubwith issue #1; no access toalice/secret) holds a token withwrite:issueon 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:
- Create two users
alice,bob. Asalice, create a private repo and a label on it (note the labelidfrom the API response). - As
bob, create any repo with an issue, and a token withwrite:issue. curl -u bob:$T -X DELETE https://<gitea>/api/v1/repos/bob/pub/issues/1/labels/<alice_label_id>→ 204.curl -u bob:$T -X DELETE https://<gitea>/api/v1/repos/bob/pub/issues/1/labels/99999999→ 422.- The differing status across an ID
bobcannot 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.)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | code.gitea.io/gitea | all versions | 1.27.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update code.gitea.io/gitea to 1.27.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pgqf-926r-548m is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-pgqf-926r-548m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-pgqf-926r-548m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-pgqf-926r-548m in your dependencies?
O3 detects GHSA-pgqf-926r-548m across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.