GHSA-jq8v-rmf6-65jw is a high-severity (CVSS 8.9) Cross-site Scripting (XSS) vulnerability in gogs.io/gogs. O3 Security confirms whether GHSA-jq8v-rmf6-65jw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gogs has Stored XSS in `.ipynb` Preview
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.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-jq8v-rmf6-65jw.
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.
How urgent is this, really
GHSA-jq8v-rmf6-65jw plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 358,265 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
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
Although .ipynb previews are sanitized on the server side via /-/api/sanitize_ipynb, the inserted content is re-rendered on the client side without sanitization using marked() on elements with the .nb-markdown-cell class. During this process, links containing schemes such as javascript: can be regenerated.
As a result, when a victim views an attacker-crafted .ipynb file and clicks the link, arbitrary JavaScript is executed in the Gogs origin, leading to a click-based Stored XSS.
Details
After the rendered output of a .ipynb file is sanitized via /-/api/sanitize_ipynb and inserted into the DOM, only the Markdown cell portions are re-rendered using marked() and overwritten in the DOM. During this process, links with the javascript: scheme can be regenerated.
templates/repo/view_file.tmpl:42–71
{{else if .IsIPythonNotebook}}
<script>
$.getJSON("{{.RawFileLink}}", null, function(notebook_json) {
var notebook = nb.parse(notebook_json);
var rendered = notebook.render();
$.ajax({
type: "POST",
url: '{{AppSubURL}}/-/api/sanitize_ipynb',
data: rendered.outerHTML,
processData: false,
contentType: false,
}).done(function(data) {
$("#ipython-notebook").append(data);
$("#ipython-notebook code").each(function(i, block) {
$(block).addClass("py").addClass("python");
hljs.highlightBlock(block);
});
// Overwrite image method to append proper prefix to the source URL
var renderer = new marked.Renderer();
var context = '{{.RawFileLink}}';
context = context.substring(0, context.lastIndexOf("/"));
renderer.image = function (href, title, text) {
return `<img src="${context}/${href}"`
};
$("#ipython-notebook .nb-markdown-cell").each(function(i, markdown) {
$(markdown).html(marked($(markdown).html(), {renderer: renderer}));
});
});
});
</script>
While regular HTML pages (including .ipynb preview pages) are served without a Content Security Policy (CSP), CSP headers are applied only to attachment delivery routes.
internal/cmd/web.go:323
c.Header().Set("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; sandbox")
Steps to Reproduce
-
As the attacker, add and push/commit a
.ipynbfile containing ajavascript:link in a Markdown cell to a repository.-
Example (PoC):
{ "nbformat": 4, "nbformat_minor": 2, "metadata": {}, "cells": [ { "cell_type": "markdown", "metadata": {}, "source": [ "[poc](javascript:alert(document.domain))" ] } ] }
-
-
The victim opens the file on Gogs (e.g.,
<img width="2386" height="1218" alt="image" src="https://github.com/user-attachments/assets/b0d93fd8-c5ca-4058-8af0-98dee590d3ad" />/<user>/<repo>/src/<branch>/poc.ipynb). -
When the victim clicks the
<img width="2390" height="1388" alt="image" src="https://github.com/user-attachments/assets/0eb6ebe8-632c-4a41-8a11-46471514b4c4" />poclink displayed in the preview,alert(document.domain)is executed in the same Gogs origin.
Minimum Required Privileges
-
Attacker: Ability to place a
.ipynbfile as a regular (non-admin) user- For example: a general user who can create a public repository and add files.
- Or: write access (collaborator, etc.) to an existing repository that the victim will view.
-
Victim: Permission to view the repository (a click is required).
Impact
- Unauthorized actions performed with the victim’s account privileges (e.g., repository settings changes, Issue operations,誘導 to token creation).
- Theft of information accessible to the victim (repository/Issue/Wiki contents, tokens exposed in page context).
- If the victim is an administrator, the impact may escalate to instance-wide configuration changes and user management.
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-jq8v-rmf6-65jw 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-jq8v-rmf6-65jw 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-jq8v-rmf6-65jw. 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-jq8v-rmf6-65jw in your dependencies?
O3 detects GHSA-jq8v-rmf6-65jw across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.