CVE-2025-64719: Gogs Denial of Service via Unhandled Commit Errors

Technical summary

CVE-2025-64719 is an improper error handling vulnerability in Gogs's wiki and repository view routes. The affected code paths are internal/route/repo/wiki.go and internal/route/repo/view.go. When rendering file listings, these handlers call functions to recover commit metadata. If those functions return errors—which can be triggered by a user with repository push or wiki write permissions creating a specially crafted file—the error is not caught and handled gracefully. Instead, the page rendering halts and returns HTTP 500, effectively denying access to the affected repository or wiki view. The root cause is inadequate error boundary handling in the commit information retrieval phase.

Business impact

For organizations relying on Gogs for internal or external Git hosting, this vulnerability creates operational disruption. An authenticated user with file creation rights can render a repository or wiki temporarily inaccessible to the broader team. While the impact is localized to the affected repository's web interface (Git operations via command line remain functional), it damages team collaboration workflows and trust in self-hosted infrastructure. The low barrier to exploitation—requiring only standard user permissions—means the risk scales with team size and the number of users granted write access.

Affected systems

All Gogs versions prior to 0.14.3 are vulnerable. The vulnerability requires an authenticated user with rights to create files in a repository or wiki page. There are no vendor-supplied affected product listings in the advisory data, so verification against your Gogs deployment version is essential. Self-hosted instances are the primary concern; cloud-hosted Gogs services (if any) would depend on their patching cadence.

Exploitability

Exploitation is straightforward and requires low privilege: any user with push access to a repository or write access to a wiki can trigger the condition. No special tools, network position, or user interaction is needed beyond creating a file. The attack is reliably reproducible, though the specific file characteristics that trigger the underlying commit-retrieval error are not detailed in the advisory. The CVSS score of 4.9 reflects the availability impact and authentication requirement; the high attack complexity (AC:L) and network accessibility (AV:N) keep it in medium severity rather than high.

Remediation

Upgrade Gogs to version 0.14.3 or later. This release includes fixes to the error handling logic in wiki.go and view.go that prevent unhandled exceptions during commit information recovery. Organizations should verify compatibility with their deployment environment before upgrading, particularly those running older Go versions or with custom patches. No workarounds short of access controls are available; restricting file creation permissions to trusted users reduces immediate risk but does not eliminate the vulnerability.

Patch guidance

Apply Gogs version 0.14.3 or newer. Review release notes for any breaking changes or dependency updates. Test the upgrade in a non-production environment first, particularly if you maintain local customizations. Restart the Gogs service after updating. Verify that repository and wiki page listings load without 500 errors by accessing them through the web interface. If using containerized deployments, pull the updated image tag and redeploy.

Detection guidance

Monitor Gogs access logs for repeated HTTP 500 errors on repository or wiki file listing endpoints. These typically appear as requests to paths like /repo/[name]/wiki or /repo/[name]/src. A spike in 500 errors from authenticated users following file creation activity may indicate exploitation. Review Gogs audit logs or Git push logs for unusual file creation patterns. Verify your running Gogs version using the admin panel or by checking the binary version output. After patching, baseline normal error rates to detect post-upgrade anomalies.

Why prioritize this

Although the CVSS score is moderate (4.9), the ease of exploitation and low friction to trigger the denial of service warrant prompt attention. The vulnerability affects the core Git collaboration interface and can be triggered by any authenticated user. Organizations with large development teams or high write-access counts face greater risk of accidental or intentional disruption. The fix is straightforward and carries low risk, making this suitable for prioritization in the next maintenance window.

Risk score, explained

The CVSS 3.1 score of 4.9 (Medium) reflects a high-availability impact (A:H) but requires high privilege (PR:H) and produces no confidentiality or integrity loss. The score is accurate for a denial-of-service flaw that requires authentication and offers no data breach potential. However, context matters: in a small team or development environment with few authenticated users, the practical risk may be lower; in a large organization with hundreds of developers, the likelihood of accidental or intentional triggering increases. The medium rating appropriately reflects this bounded but real threat to system availability.

Frequently asked questions