Build1 distinct publisher2 min readPublished
The patch for the last Gogs RCE validated the path parameter and never looked at where a committed symlink pointed. Wiz counted more than 700 already-compromised instances before v0.13.4 shipped.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The write never touches the git protocol. Gogs exposes a file modification API, PutContents, and that is where the earlier path traversal lived [9]. The maintainers' fix for CVE-2024-55947, reported by ManassehZhou, added input validation on the path parameter [9][10]. That check covers the string you sent. Resolution happens later, when the file is opened. The link is an ordinary committed git object, because Gogs follows standard Git behaviour and permits symlinks that point outside the repository [11]. Write through one and the filesystem does the traversal on your behalf [13]. The productive target is .git/config, where setting sshCommand converts a file write into command execution [14].
On the counts: more than 700 compromised against more than 1,400 exposed works out near one in two [19]. Both figures are floors, and the denominator is what an external scan can see [6], so every instance behind a VPN or on an internal subnet sits outside it. For that rate to say anything about your install, the install has to be internet-reachable with repository creation and registration at their shipped defaults, which Wiz reports is common [15][7]. If it is reachable, the version string is not a defence. The infected host ran 0.13.2, a build that already carried the fix for CVE-2024-55947 [16].
Gogs earns its deployments on easy setup and minimal resource usage [8]. In my experience that is the profile of a service someone stands up on a spare VM for a team of five and never enters in an asset inventory. It also holds source code, and on this bug it hands over execution on the host that holds it [14]. Note where the detection came from: malware findings on a customer workload, not from the Gogs instance itself [1]. The repository list carried the tell, with names no human chose [17]. Nobody was reading it.
Wiz places this in a run of symlink handling flaws in the same codebase, alongside CVE-2024-56731 and CVE-2024-54148 [18]. That history is what changes the value of the upgrade for me. It closes this write path [4]. It does not change the underlying fact that the API accepts symlinks as normal repository content [11], and the class of bug has now been exploited more than once in the same component. So in my context the release goes on with open registration turned off and proxy authentication in front, because the API should not be reachable by anyone who can load a signup page.
Ranked by verification strength, evidence, and original report placement.
Wiz Research discovered an active Gogs zero-day while investigating a malware infection on a customer cloud workload.
CVE-2025-8110 is a symlink bypass of a previously patched RCE (CVE-2024-55947) that allows authenticated users to overwrite files outside the repository, leading to remote code execution.
Wiz identified over 700 compromised Gogs instances that were public-facing on the internet.
As of January 23, 2026, a fix has been issued in Gogs version v0.13.4, after Wiz disclosed the flaw to the maintainers.
On July 10 the Wiz Threat Research team observed malware findings on public-facing instances of Gogs.
In an external scan, Wiz identified over 1,400 Gogs servers publicly exposed to the internet.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
security
CVE-2026-52806 turns a Gogs branch name into command execution as the git user2 distinct publishers
product
AI writes the Dockerfile, and the pipeline is still checking the app code1 distinct publisher
security
A repo compromise found in week four outlives GitHub's seven-day Git event log1 distinct publisher
build
Your test grid is an RCE surface: SeleniumGreed turns exposed Selenium hubs into miners2 distinct publishers
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.
Detailed first-party technical evidence, single publisher
The mechanism is specified end to end - failed path-only validation, symlink commit, PutContents write-through, .git/config sshCommand overwrite - and is tied to a CVE identifier, a named prior CVE it bypasses, host-level forensic artifacts and a shipped fix version. What is missing is independence: every element comes from the discovering vendor, with no maintainer advisory, CVE database text, or third-party confirmation in the cluster, and the compromise-detection heuristic behind the 700+ figure is described only as an artifact pattern.
Mass in-the-wild exploitation with a shipped fix
This is not a theoretical finding: exploitation is observed at fleet scale (700-plus of roughly 1,400 exposed instances, identical malware across hosts) and the remediation path exists as a released version, v0.13.4. Adoption is scored on the strength of real-world deployment and exploitation signal, not on evidence that operators have actually upgraded, which the source does not measure.
Slightly overstated by unreplicated counts
Language is measured for a vendor blog and the technical claims are specific and falsifiable, which keeps the gap small. The tilt toward overstatement comes from headline population statistics - 1,400 exposed, 700+ compromised, 'over 50%' - that rest on one vendor's scan and its own compromise heuristic with no independent replication, and from 'zero-day actively exploited' framing where the exposure window between observation and the January 2026 fix is never quantified.
Discovering vendor publishing its own research
Wiz is a commercial cloud-security vendor and simultaneously the discoverer, disclosure party, and sole narrator here; publicising a live zero-day found on a customer workload directly demonstrates its threat-research and workload-detection value. That does not make the technical content wrong, but the framing, the choice to lead with fleet-wide compromise counts, and the absence of any note on the vendor's own commercial stake are all consistent with a marketing-adjacent research incentive.
Mechanism solid, scale figures unreplicated
Confidence is limited by the single-publisher structure of the cluster. The vulnerability mechanics, the failed prior patch and the fixed version are internally consistent and specific enough to act on, so the actionable core is reliable; the quantitative scale claims and the implied timeline (a July 10 observation with no stated year, a fix dated January 23, 2026) would need maintainer or third-party confirmation before being treated as settled.