CVE-2026-52800: Gogs CSRF Vulnerability Allows Organization Owner Compromise

Technical summary

Gogs versions before 0.14.3 permit organization team member management operations via GET requests without CSRF token validation. The vulnerability exists in the endpoint(s) responsible for adding team members to organization teams, specifically the Owners team. Because the vulnerable action uses HTTP GET semantics and lacks anti-CSRF protections (such as token validation or SameSite cookie attributes), an attacker can embed a crafted URL in a webpage, email, or chat message. When a victim with organization owner privileges navigates to that URL while authenticated to Gogs, the browser automatically includes the victim's session cookies, causing the malicious team membership change to execute in the victim's security context. This is a classic CSRF vulnerability (CWE-352) affecting state-changing operations.

Business impact

A successful exploit grants an attacker persistent administrative access to a Gogs organization, including the ability to read, modify, or delete repositories, manage team memberships, alter organization settings, and potentially access sensitive code or credentials stored within. For enterprises using Gogs as an internal Git platform, this represents a direct pathway to code repository compromise, intellectual property theft, or supply chain sabotage. The attack is particularly dangerous because it requires only that a victim visit a link—no phishing of credentials, no exploit development, no vulnerability chaining. Recovery requires identifying unauthorized owner accounts, auditing all actions taken by compromised accounts, and potentially rolling back unwanted changes.

Affected systems

Gogs versions 0.14.2 and earlier are vulnerable. This includes all self-hosted instances running versions prior to 0.14.3, regardless of deployment environment (on-premises, cloud, containerized). The official Gogs project has confirmed the issue and released a patch. Organizations that maintain internal Gogs instances or those that rely on community-managed Gogs deployments should prioritize inventory and assessment of their Gogs version.

Exploitability

The attack is trivial to execute and requires no authenticated access from the attacker. An attacker simply constructs a URL embedding the malicious action (e.g., adding a user to the Owners team) and distributes it via email, forum post, chat, or embedded in a webpage. The victim must be logged into Gogs at the time they visit the link, but no warning or confirmation is presented. The barrier to exploitation is social engineering capability, not technical skill. The CVSS 3.1 score of 8.8 (HIGH severity) reflects the combination of network accessibility, low attack complexity, no privilege requirement, and user interaction that results in high confidentiality, integrity, and availability impact.

Remediation

Upgrade Gogs to version 0.14.3 or later. This patch adds proper CSRF token validation to team management endpoints and likely implements additional state-change protections. Before upgrading, review your Gogs instance for unauthorized organization owners added after the initial deployment, audit recent team membership changes, and verify that no malicious actions were taken by compromised accounts. After patching, monitor for any additional suspicious activity.

Patch guidance

Update your Gogs installation to version 0.14.3 or a later stable release as soon as feasible. If running Gogs in a container, rebuild or pull the image tagged 0.14.3 or later. If running from source, pull the latest code from the official Gogs repository and rebuild. Test the upgrade in a staging environment first to confirm compatibility with any custom configurations or plugins. Once deployed, verify that existing team memberships are still intact and correct. Monitor Gogs logs for any failed or suspicious team management operations immediately after deployment.

Detection guidance

Review organization team membership logs, particularly additions to the Owners team, for entries that lack corresponding audit records or that were added by accounts you do not recognize. Check for unusual HTTP GET requests to team management endpoints (typically paths like /org/{org}/teams/*/members) from external or unexpected origins. Enable HTTP access logging if not already enabled, and search for GET requests to team-related endpoints that result in state changes (HTTP 200 or 302 responses). If Gogs supports request logging or CSRF-related warnings, review those logs for POST-to-GET downgrades or missing CSRF tokens. Correlate team membership changes with phishing emails or suspicious links sent to your organization owners during the same timeframe.

Why prioritize this

This vulnerability merits immediate prioritization because it combines high ease of exploitation with severe impact. An attacker needs no technical sophistication, no discovered credentials, and no persistence mechanism—a single click by a victim grants permanent administrative access. The impact includes full repository compromise and potential code theft or supply chain attacks. Unlike vulnerabilities requiring multi-step exploitation or rare conditions, CSRF attacks on administrative functions are a proven and common attack vector. Any Gogs instance exposed to the internet or accessible to users who might receive social-engineered messages should be patched urgently.

Risk score, explained

The CVSS 3.1 score of 8.8 reflects: Network accessibility (attacker requires no direct network access to the target system, only ability to send a link to victims); Low attack complexity (no special tools, timing, or conditions required); No privilege requirement (attacker begins unauthenticated); User interaction required (victim must click the link, but no special awareness is needed); and Unchanged scope. The impact is rated high across all three dimensions—confidentiality (attacker can read all organization repositories), integrity (attacker can modify or delete code), and availability (attacker can lock out legitimate owners or delete repositories). Together, these factors yield an 8.8 HIGH severity rating, placing this in the upper tier of exploitable vulnerabilities that demand rapid remediation.

Frequently asked questions