CVE-2026-52810: Gogs Unauthorized Repository Push Vulnerability - What It Means for Your Business and How to Respond

Introduction

CVE-2026-52810 is a high-severity access-control flaw in Gogs, a widely used self-hosted Git service. It can allow a person with only read access to a repository to push unauthorized code, overwrite branches, or remove development history. For organizations that rely on Gogs to manage source code, infrastructure configurations, or internal documentation, this is not merely a technical defect. It is a direct threat to the integrity of the software your teams build, deploy, and operate.

Any business running a vulnerable Gogs instance should treat this as a priority. The issue is especially consequential where repositories contain production deployment code, customer-facing applications, or security-sensitive configuration. This post explains who is exposed, what the risk means operationally and commercially, how to determine whether your organization is affected, and the practical steps to contain and remediate the vulnerability.

Background & History

Gogs is an open-source, self-hosted Git service that organizations use to store and collaborate on source code. CVE-2026-52810 was published through the National Vulnerability Database on June 24, 2026, and the underlying GitHub security advisory was published on June 19, 2026. The flaw affects all Gogs versions before 0.14.3 and was fixed in Gogs 0.14.3.

In plain language, Gogs incorrectly decided whether a Git request was a read or a write based on information supplied by the client. A user could send a request to the write endpoint while claiming it was a read operation. The system authorized it as a read, but then executed it as a write, allowing an unauthorized push to a repository. GitHub assigned the issue a CVSS v4 base score of 7.1, classified as High, and categorized it as Improper Access Control, or CWE-284.

The advisory credits Aikido Security and reporters JorianWoltjer, reindaelman, and grumpinout1. The vendor released version 0.14.3 with a corrective change tracked in Gogs pull request 8331 and commit 7c9cf53aca957959bcd98b0cc987d9901b7cb184.

What This Means for Your Business

The central business risk is loss of control over your source code. An attacker who can write to a repository can introduce malicious changes, alter deployment scripts, modify application logic, or force-push a branch in a way that removes prior history. That can turn a routine code repository into a delivery mechanism for software supply chain attacks, fraudulent changes, or operational disruption.github

The impact extends beyond engineering. If altered code reaches production, it can cause outages, data mishandling, fraudulent transactions, or exposure of customer information. Even when malicious code is caught before deployment, your teams may need to pause releases, audit recent commits, restore repositories, and reassure customers and partners that their systems remain trustworthy.

There are also compliance and contractual consequences. Organizations subject to frameworks such as SOC 2, ISO 27001, HIPAA, PCI DSS, or state and federal privacy obligations may need to document the incident, assess whether regulated data or systems were affected, and demonstrate timely remediation. A preventable authorization failure in a core development platform can undermine customer confidence, particularly for software vendors, financial institutions, healthcare organizations, and enterprises handling sensitive data.

Real-World Examples

Regional Financial Services Provider: A regional bank uses Gogs to manage internal applications and payment-processing integrations. A compromised or malicious read-only collaborator pushes altered transaction-validation code. If the change reaches production, transactions could be processed incorrectly, creating financial loss, regulatory exposure, and customer harm.

Mid-Market SaaS Company: A software provider gives contractors read-only access to a product repository. One contractor exploits the flaw to insert a backdoor into a deployment pipeline. The company later discovers unauthorized changes in its release history and must halt releases, audit every commit, notify customers, and rebuild trust in its software delivery process.

Healthcare Technology Organization: A healthcare vendor stores integration code and configuration files in Gogs. An unauthorized push modifies data-handling logic or infrastructure settings. Even if no patient data is directly exposed, the organization may need to conduct a formal security assessment and demonstrate that protected health information was not affected.

Small Professional Services Firm: A small firm hosts internal automation scripts and client project repositories on Gogs. A former or current low-privilege user force-pushes changes that overwrite the main branch. The firm loses development history, experiences project delays, and must spend limited internal resources recovering the repository and investigating the incident.github

Am I Affected?

• You are running Gogs version 0.14.2 or any earlier version.
• You have enabled Git smart HTTP access to repositories on your Gogs instance.
• You have granted read-only collaborator access to any repository.
• Your Gogs instance uses REQUIRE_SIGNIN_VIEW = true, which makes any signed-in user a potential attacker against repositories they can view.
• You host private repositories where read-only users should never be able to push changes.
• You rely on Gogs for source code, deployment automation, infrastructure configuration, or client deliverables.
• You have not yet upgraded to Gogs 0.14.3 or later.

Public repositories that can be viewed anonymously are not exploitable in the same way because the flaw causes an internal error in that specific case, but private repositories and sign-in-required instances remain materially exposed.github

Key Takeaways

• CVE-2026-52810 allows users with read-only access to push unauthorized changes to vulnerable Gogs repositories.
• The primary danger is integrity: attackers can alter source code, deployment logic, or repository history.
• Gogs versions before 0.14.3 are affected, and the official fix is available in version 0.14.3.
• Organizations using sign-in-required Gogs instances face broader exposure because any authenticated user may be able to exploit the issue.
• Rapid patching, access review, commit auditing, and penetration testing are essential to reduce both immediate and long-term risk.

Call to Action

If your organization operates Gogs or any self-hosted code repository, do not wait for suspicious activity to confirm the risk. IntegSec can assess your exposure, validate whether the vulnerability is exploitable in your environment, and help you prioritize remediation across your development infrastructure. Contact IntegSec for a professional penetration test and a practical, business-focused path to deeper cybersecurity risk reduction at https://integsec.com.

Technical Appendix

This appendix is intended for security engineers, penetration testers, and IT professionals responsible for Gogs administration and remediation.

A — Technical Analysis

CVE-2026-52810 is an improper access-control flaw, tracked as CWE-284, in the Git Smart HTTP handler of Gogs. The handler derives the authorization mode from the client-supplied service query parameter rather than from the RPC path actually being dispatched. A request sent to /repo.git/git-receive-pack, the write path used for pushes, can include ?service=git-upload-pack, causing authorization to evaluate the request as a read while routing still executes git receive-pack.

The attack requires network access, low privileges, no user interaction, and low attack complexity. The CVSS v4 vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N, producing a base score of 7.1 High. Confidentiality impact is none, integrity impact is high, and availability impact is low because force pushes can overwrite branch history.github

Two exploitation conditions are relevant. First, a collaborator with read-only rights can write to a repository owned by another user. Second, on instances configured with REQUIRE_SIGNIN_VIEW = true, any authenticated user can potentially write to any public repository they can view. Fully anonymous, publicly viewable repositories are not exploitable because the relevant AuthUser value becomes nil and triggers a 500 Internal Server Error.github

The official advisory is GHSA-wmfg-5p4h-5fw3, and the NVD reference is CVE-2026-52810. The remediation is included in Gogs 0.14.3.

B — Detection & Verification

Version enumeration:

Scanner signatures: Vulnerability scanners should flag the Go module gogs.io/gogs at versions below 0.14.3. Container and software-composition analysis tools can identify the affected package directly from the application image or Go module metadata.

Log indicators:

• POST requests to /repo.git/git-receive-pack containing service=git-upload-pack.
• Successful pushes from accounts with read-only repository permissions.
• Unexpected force pushes, deleted branches, rewritten commit history, or new branches created by low-privilege users.
• Push activity from unusual source IP addresses, unusual times, or accounts with no prior write history.
• HTTP 500 responses associated with anonymous requests to git-receive-pack, which may indicate probing of the flaw.

C — Mitigation & Remediation

1. Immediate (0–24 hours): Upgrade Gogs to version 0.14.3 or later, using the official release and following the vendor upgrade procedure. If immediate patching is not possible, restrict Git Smart HTTP access at the reverse proxy or network layer, limit access to trusted IP ranges, and suspend read-only collaborator access where business operations allow. Review recent push events and branch changes for unauthorized activity.
2. Short-term (1–7 days): Audit all repositories for unexpected commits, force pushes, altered branches, and changes to CI/CD or deployment files. Rotate credentials for accounts with repository access, review collaborator permissions, and remove unnecessary read-only accounts. Confirm that the upgraded instance correctly rejects write requests to git-receive-pack when the service parameter claims git-upload-pack.
3. Long-term (ongoing): Establish a patch-management process for self-hosted development tools, including Gogs, Git servers, CI/CD systems, and artifact repositories. Implement least-privilege repository access, mandatory review for protected branches, immutable audit logging, and periodic access recertification. Include development infrastructure in regular penetration testing and vulnerability management programs.

Official patching should always take precedence over compensating controls. Interim network restrictions and permission reductions reduce exposure but do not correct the flawed authorization logic.github

D — Best Practices

• Apply security updates to self-hosted Git services promptly, especially when the flaw affects repository write access.
• Enforce least privilege so collaborators receive only the minimum access required for their role.
• Protect primary branches with mandatory code review, signed commits where appropriate, and restrictions on force pushes.
• Monitor Git activity for anomalous pushes, rewritten history, and access by low-privilege or dormant accounts.
• Include source-control platforms, build systems, and deployment pipelines in routine penetration tests and threat-modeling exercises