Security2 distinct publishers2 min readPublished
Rapid7 scored it 9.9 and Gogs shipped 0.14.3 on June 7, 2026. The reason it rates that high is configuration: open registration and unlimited repository creation let a stranger own the repo they attack from.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
Four actions, all inside the attacker's own account: sign up, create a repository, flip one setting in it, open a pull request [3]. The flaw sits in the last step. According to runZero, Gogs hands the pull request's source branch name straight to `git rebase` without a `--` delimiter to mark the end of options [3], so a branch name beginning with --exec is parsed as a flag and its value runs as a command during the rebase merge [2].
Version 0.14.2 is the awkward part. runZero's own timeline lists 0.14.2 as the fix for CVE-2026-25921, the March 2026 cross-repository LFS overwrite scored 9.3 and reachable without authentication [14]. Rapid7 lists 0.14.2 as confirmed vulnerable to 52806. Anyone who upgraded in March to clear the LFS bug is sitting on the June one, and 0.14.3 is the first build that satisfies both [1].
Execution lands as the Gogs process user, which on Docker installs is git at UID 1000 and on binary installs is whatever account the administrator chose [16]. Every repository on the instance then sits under one REPOSITORY_ROOT with no OS-level isolation between them [9]. That is the same shape as the LFS flaw, where all objects shared a single location without per-repository separation [14]; in both cases one tenant gets leverage over another tenant's data because nothing separates them on disk [5].
This is the third separately tracked Gogs flaw in the seven months from December 2025 to June 2026 [2]. The first, CVE-2025-8110, was an authenticated arbitrary file overwrite scored 7.8 in versions 0.13.3 and earlier, and runZero notes evidence of exploitation in the wild for it [15]. That is the closest thing available to a base rate for attacker interest in this software.
The 1,141 figure is a floor. It counts hosts whose Gogs sign-in title is visible to Shodan, and Rapid7 says the real install base is much larger because most instances sit behind VPNs or on internal networks [7]; a project carrying roughly 50,000 GitHub stars and 5,000 forks is not deployed 1,141 times [11][4]. For instances that cannot restart on 0.14.3 quickly, runZero's configuration advice still applies: DISABLE_REGISTRATION = true, MAX_CREATION_LIMIT = 0, and no internet path to the web interface [13]. Rapid7's own triage line is the account count. Any Gogs instance with more than one user is effectively multi-tenant, and on those, a single member holds everything the git user can read [10].
Ranked by verification strength, evidence, and original report placement.
Rapid7 Labs discovered CVE-2026-52806, an argument injection (CWE-88) flaw in Gogs scored CVSSv3.1 9.9 (Critical), allowing any authenticated user to achieve remote code execution on the server via a pull request; the exploit requires no admin privileges and no interaction with other users.
The malicious branch name injects the --exec flag into git rebase during the "Rebase before merging" merge operation, producing arbitrary command execution as the Gogs server process user.
runZero describes the cause as a malicious pull request branch name passed directly to the git rebase command without a -- delimiter to indicate the end of options, so the branch name is interpreted as the --exec flag.
Gogs ships with open registration enabled by default (DISABLE_REGISTRATION = false) and no limit on repository creation (MAX_CREATION_LIMIT = -1); any registered user who creates a repo is automatically its owner, enabling rebase merging is a single toggle in settings, and the entire chain can be operated without interaction from any other user.
On June 7, 2026, the Gogs maintainer accepted Rapid7's patch and released version 0.14.3, which fixes the vulnerability; the CVE was assigned via GHSA-qf6p-p7ww-cwr9.
Gogs 0.14.2 and 0.15.0+dev (commit b53d3162) were confirmed affected, and all prior versions supporting the "Rebase before merging" style are likely vulnerable as well.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026
1 article · August 27, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Gogs checks the path, then follows the symlink out of the repository1 distinct publisher
build
Honeypots logged a SharePoint JWT bypass hunting for a Business Data Catalog sink1 distinct publisher
security
Washington names industrial-scale distillation, then hands the detection bill to abuse teams1 distinct publisher
security
A North Korean IT worker got hired by a federal agency. Vetting is a security control now.1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Strong first-party technical evidence with one stale corroborator
The root cause is described consistently by two independent publishers, versions are confirmed by testing, a CVSS vector and CVE/GHSA identifier exist, and a vendor patch shipped. Confidence is capped short of the top because the deep technical detail and the exploitability claims come from a single discoverer-authored post, the second source is a derivative roll-up that is wrong on patch and CVE status, and the referenced Metasploit module and indicators of compromise are not reproduced in the supplied text.
Wide install base and confirmed exposure, no patch-uptake data
Deployment footprint is well evidenced — roughly 50,000 stars, 5,000+ forks, 1,141 internet-facing sign-in pages as an explicit lower bound, and a vendor shipping inventory queries because customers run it. What is absent is the other half of adoption: no source reports how many instances have moved to 0.14.3, and no exploitation of CVE-2026-52806 in the wild is reported, though the earlier CVE-2025-8110 was actively exploited.
Severity is earned; residual-risk framing is overstated
The 9.9 rating and impact narrative are supported by mechanism, defaults and post-exploitation reach, so the substance is not inflated. The overstatement is in status framing: the Rapid7 post is titled "NOT FIXED" while its own update confirms 0.14.3 shipped on June 7, 2026, and runZero asserts no CVE and no patch exist. Both leave readers with a bigger unremediated-risk impression than the evidence supports, and neither offers patch-uptake data to justify it.
Both publishers are commercial vendors selling the remedy
Rapid7 discovered the flaw, discloses under its own policy, and notes a Metasploit module — direct promotion of its research brand and offensive-security product. runZero's post exists to route readers into its software and service inventory queries for finding impacted assets. Neither incentive is hidden, and the technical content is checkable, but commercial framing shapes emphasis on both sides, including the persistence of alarming status language.
Mechanism and fix well grounded; remediation reality unknown
Root cause, severity drivers, affected versions and the fix version are all firmly established and cross-referenced, and the two publishers agree on the technical core. Confidence is held down by the single-discoverer dependency for exploitability details, the secondary source's stale CVE and patch status, and the total absence of upgrade-rate or in-the-wild exploitation data for this specific CVE.