CVE-2026-25229: 
Gogs vulnerability analysis and mitigation

CVE-2026-25229 is an authorization bypass vulnerability in Gogs (a self-hosted Git service) that allows authenticated users with write access to any repository to modify issue labels belonging to other repositories — a cross-repository label tampering attack. It affects Gogs versions up to and including 0.13.4, with the fix introduced in version 0.14.0. The vulnerability was published on February 14, 2026, and added to the GitHub Advisory Database on February 17, 2026. It carries a CVSS v3.1 score of 6.5 (Medium) and a CVSS v4.0 score of 5.3 (Medium) (GitHub Advisory, Gogs Security Advisory).

The root cause is improper access control (CWE-284) in the UpdateLabel function within internal/route/repo/issue.go. The handler calls database.GetLabelByID(f.ID) — which internally passes repoID=0 to the ORM layer, causing repository ownership restrictions to be ignored — rather than the correct database.GetLabelOfRepoByID(c.Repo.Repository.ID, f.ID). No subsequent check validates that the retrieved label's RepoID matches the repository in the URL path. The middleware reqRepoWriter() only confirms write access to the attacker's own repository, not the label's actual owning repository. Notably, other functions (NewLabel, DeleteLabel, and the API's EditLabel) correctly enforce repository scoping, making UpdateLabel in the Web UI the sole vulnerable code path (GitHub Advisory, Gogs Security Advisory).

Successful exploitation allows an authenticated low-privileged attacker to arbitrarily rename or recolor issue labels in any repository on the Gogs instance, without requiring access to those repositories. Concrete consequences include: deprioritizing critical issues by downgrading labels (e.g., "P0-Critical" → "P3-Low"), concealing security vulnerability reports by relabeling them as "documentation," sabotaging CI/CD pipelines that rely on label-based automation, and performing mass disruption across multiple repositories via sequential label ID enumeration. There is no confidentiality or availability impact, but the integrity impact is rated High under CVSS v3.1 (GitHub Advisory).

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, demonstrating the attack via a simple curl command requiring only a valid session cookie and write access to any repository on the instance. The EPSS score is approximately 0.044% (14th percentile), indicating low current exploitation probability. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (GitHub Advisory, Gogs Security Advisory).

1. Reconnaissance: Identify a target Gogs instance running version ≤ 0.13.4. Obtain or create an account with write access to at least one repository ("repo-a").
2. Identify target label IDs: Log in as a victim user (or observe as an attacker with access to the target repository's label page). Navigate to the target repository's labels page (e.g., bob/repo-b/labels), open browser DevTools (F12) → Network tab, click "Edit" on any label, and note the id field value in the form submission (e.g., id=1).
3. Obtain attacker session cookie: Log in as the attacker ("alice"), open DevTools → Application → Cookies, and copy the i_like_gogs session cookie value.
4. Send malicious POST request: Using curl or a similar tool, POST to the attacker's own repository label edit endpoint with the victim's label ID:

curl -X POST "http://<gogs-host>/alice/repo-a/labels/edit" \
  -H "Cookie: i_like_gogs=<session_cookie>" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "id=1&title=HACKED-BY-ALICE&color=%23000000"

5. Verify impact: Log in as the victim and navigate to bob/repo-b/labels — the target label will now reflect the attacker-supplied name and color.
6. Mass disruption (optional): Enumerate sequential label IDs (e.g., id=1, id=2, ...) to batch-modify labels across multiple repositories on the instance (Gogs Security Advisory).

• Network: Unexpected HTTP POST requests to /<username>/<reponame>/labels/edit where the id parameter references a label ID not belonging to <reponame>; requests originating from users who do not own the targeted repository.
• Logs: Gogs access logs showing POST requests to /labels/edit endpoints with label IDs that do not correspond to the repository in the URL path; 302 redirect responses following such requests indicating successful processing.
• Application Behavior: Unexpected label name or color changes in repositories, particularly renaming of security-related or priority labels (e.g., "P0-Critical", "security") to unrelated values; CI/CD pipeline failures coinciding with label modifications.

Upgrade Gogs to version 0.14.0 or later, which resolves the vulnerability by replacing database.GetLabelByID(f.ID) with database.GetLabelOfRepoByID(c.Repo.Repository.ID, f.ID) in the UpdateLabel handler, enforcing repository ownership validation at the database layer. The fix is available in commit 643a6d6. No configuration-based workaround is available; upgrading is the only remediation. Administrators should also audit recent label modifications across all repositories to identify any unauthorized changes made prior to patching (GitHub Advisory, Gogs Commit).

The vulnerability was reported by security researcher spingARbor and published by the Gogs maintainer (unknwon) on February 14, 2026. No significant broader media coverage or notable community commentary beyond the official advisory has been identified at this time (Gogs Security Advisory).