GHSA-3w28-36p9-w929
Fix: gogs/gogs#8326GHSA-3w28-36p9-w929 is a CWE-80 vulnerability in gogs.io/gogs. O3 Security confirms whether GHSA-3w28-36p9-w929 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gogs's Unauthenticated Jupyter Notebook (ipynb) Sanitizer allows arbitrary data: URIs leading to XSS
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-3w28-36p9-w929.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
gogs.io/gogsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The Jupyter Notebook (ipynb) sanitizer endpoint at POST /-/api/sanitize_ipynb allows arbitrary data: URIs without proper restrictions, potentially leading to Cross-Site Scripting (XSS). The endpoint uses bluemonday.UGCPolicy() with p.AllowURLSchemes("data") which permits all data URI schemes including data:text/html, enabling attackers to inject malicious HTML/JavaScript. Additionally, the endpoint has no authentication middleware, allowing any registered user to exploit this vulnerability.
Severity
High
Affected Versions
All versions using the vulnerable endpoint
Vulnerability Details
- CVE ID: (To be assigned)
- Entry Point:
POST /-/api/sanitize_ipynb - Attack Vector: Network
- Authentication Required: No (only needs a registered user account)
Impact
An attacker with a registered user account can:
- Send malicious HTML containing
data:text/htmlURIs to the sanitization endpoint - Receive sanitized but attacker-controlled HTML in the response
- Execute arbitrary JavaScript in the attacker's browser context through XSS
- Potentially exploit other users if the sanitized output is rendered in their context
The vulnerability has higher severity because:
- No authentication required (only needs a registered user account)
- Unlike the safer pattern in
internal/markup/sanitizer.go:39which usesisSafeDataURIto only allow safe image MIME types, this endpoint allows ALL data URIs including HTML - The returned HTML can be used to craft XSS attacks
Proof of Concept
Attacker sends a POST request to the sanitization endpoint:
POST /-/api/sanitize_ipynb HTTP/1.1
Host: target.gogs.instance
Content-Type: text/plain
<a href="data:text/html,<script>alert(document.cookie)</script>">click</a>
The server returns the sanitized HTML with the data URI preserved:
<a href="data:text/html,<script>alert(document.cookie)</script>">click</a>
When this HTML is rendered in a browser, the JavaScript within the data URI will execute, leading to XSS.
Affected Component
File: internal/app/api.go:10-16
func ipynbSanitizer() *bluemonday.Policy {
p := bluemonday.UGCPolicy()
p.AllowAttrs("class", "data-prompt-number").OnElements("div")
p.AllowAttrs("class").OnElements("img")
p.AllowURLSchemes("data") // <-- VULNERABLE: allows all data URIs
return p
}
File: cmd/gogs/web.go:681-683 - No authentication middleware
m.Group("/-", func() {
m.Get("/metrics", app.MetricsFilter(), promhttp.Handler())
m.Group("/api", func() {
m.Post("/sanitize_ipynb", app.SanitizeIpynb()) // <-- No auth middleware
})
})
Root Cause
-
Unrestricted data URI scheme: The code at
internal/app/api.go:14usesp.AllowURLSchemes("data")without any restriction, unlike the safer implementation ininternal/markup/sanitizer.go:39which usesAllowURLSchemeWithCustomPolicy("data", isSafeDataURI)to only allow safe image MIME types. -
No authentication: The endpoint at
cmd/gogs/web.go:682does not have any authentication middleware applied, making it accessible to any registered user. -
Insufficient validation: The sanitization only removes dangerous tags/attributes but preserves data URIs, allowing
data:text/htmlpayloads to pass through.
Suggested Fix
Option 1: Use the same safe pattern as internal/markup/sanitizer.go
Replace p.AllowURLSchemes("data") with:
p.AllowURLSchemeWithCustomPolicy("data", isSafeDataURI)
Where isSafeDataURI is a function that only allows safe image MIME types (image/png, image/jpeg, image/gif, etc.).
Option 2: Add authentication middleware
Apply appropriate authentication to the endpoint:
m.Post("/sanitize_ipynb", middleware.signIn, app.SanitizeIpynb())
Option 3: Disable data URI scheme entirely
If data URIs are not required for ipynb sanitization:
// Remove this line entirely:
// p.AllowURLSchemes("data")
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | gogs.io/gogs | all versions | 0.14.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for gogs.io/gogs. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update gogs.io/gogs to 0.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3w28-36p9-w929 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3w28-36p9-w929 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-3w28-36p9-w929. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3w28-36p9-w929 in your dependencies?
O3 detects GHSA-3w28-36p9-w929 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.