CVE-2026-25229
mediumpriority · track · 26EPSS 0.003 · 22 %ileDEEUUSEPSS · scored 2026-10-27
Gogs is an open source self-hosted Git service. Versions 0.13.4 and below have a broken access control vulnerability which 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. 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. This issue has been fixed in version 0.14.1.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · low–medium · 1.3–6.5
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (6)
Products and version ranges known to be affected.
advisories (3)
Vendor and ecosystem advisories describing this.
- WID-SEC-W-2026-0423Gogs: Mehrere SchwachstellenDeutsch2026-02-15csaf · cert_bundDE
Ein Angreifer kann mehrere Schwachstellen in Gogs ausnutzen, um Dateien zu manipulieren, Sicherheitsmaßnahmen zu umgehen oder Administratorrechte zu erlangen.
- GHSA-cv22-72px-f4ghGogs has an Authorization Bypass Allows Cross-Repository Label Modification in Gogs2026-02-17ghsa · osvUS
### **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`): ```plain 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** **Prerequisites**: + Two user accounts: Alice (attacker) and Bob (victim) + alice has written access to repo-a + Bob owns repo-b with labels **Step 1: Identify Target Label ID** 1. Login as bob, navigate to bob/repo-b/labels 2. Open browser DevTools (F12) → Network tab 3. Click edit on any label 4. Observe the form data: id=<LABEL_ID> 5. Example: id=1 **Step 2: Execute Attack** ```plain # Login as alice, get session cookie # Open DevTools → Application → Cookies → i_like_gogs # Copy the cookie value # Send malicious request curl -X POST "http://localhost:3000/alice/repo-a/labels/edit" \ -H "Cookie: i_like_gogs=<ALICE_SESSION_COOKIE>" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "id=1&title=HACKED-BY-ALICE&color=%23000000" # Expected response: 302 Found (redirect) ``` **Step 3: Verify Impact** 1. Login as bob 2. Navigate to bob/repo-b/labels 3. Observe: Label "P0-Critical" is now "HACKED-BY-ALICE" with black color ### **Impact** 1. **Issue Classification Disruption**: Modify critical labels (e.g., "P0-Critical" → "P3-Low") causing urgent issues to be deprioritized 2. **Security Issue Concealment**: Change "security" labels to "documentation" to hide vulnerability reports from security teams 3. **Workflow**** Sabotage**: Alter labels used in CI/CD automation, breaking deployment pipelines 4. **Mass Disruption**: Batch modifies all labels across multiple repositories using ID enumeration **Recommended Fix**: ```plain func UpdateLabel(c *context.Context, f form.CreateLabel) { l, err := database.GetLabelOfRepoByID(c.Repo.Repository.ID, f.ID) if err != nil { c.NotFoundOrError(err, "get label of repository by ID") return } // Now label ownership is validated at database layer 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")) } ```
- GO-2026-4499Gogs has an Authorization Bypass Allows Cross-Repository Label Modification in Gogs in gogs.io/gogs2026-02-23vendor · osvUS
Gogs has an Authorization Bypass Allows Cross-Repository Label Modification in Gogs in gogs.io/gogs. NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions. (If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.) The additional affected modules and versions are: gogs.io/gogs before v0.14.0.
also known as (5)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (7)
External citations — patches, advisories, analysis.
- https://github.com/gogs/gogs/commit/643a6d6353cb6a182a4e1f0720228727f30a3ad2cnnvd
- https://github.com/gogs/gogs/security/advisories/GHSA-cv22-72px-f4ghcnnvd
- https://gogs.io/getting-started/installationPatchcnnvd
- https://github.com/gogs/gogs/commit/643a6d6353cb6a182a4e1f0720228727f30a3ad2enisa_euvd
- https://github.com/gogs/gogs/security/advisories/GHSA-cv22-72px-f4ghenisa_euvd
- https://github.com/gogs/gogs/commit/643a6d6353cb6a182a4e1f0720228727f30a3ad2Patchnvd
- https://github.com/gogs/gogs/security/advisories/GHSA-cv22-72px-f4ghExploitMitigationVendor Advisorynvd
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan