GHSA-9cpj-qc93-vw8v
HIGHGHSA-9cpj-qc93-vw8v is a high-severity (CVSS 8.7) Cross-site Scripting (XSS) vulnerability in code.gitea.io/gitea. O3 Security confirms whether GHSA-9cpj-qc93-vw8v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gitea: Stored XSS via glTF `extensionsRequired` in Gitea 3D File Viewer
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-9cpj-qc93-vw8v.
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-9cpj-qc93-vw8v 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 360,482 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
code.gitea.io/giteaReal-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
Me again.
Gitea's built-in 3D file viewer (powered by Online3DViewer) is vulnerable to stored cross-site scripting (XSS) through crafted .gltf files. When a glTF file declares an unsupported required extension, Online3DViewer generates an error message containing the extension name and Gitea inserts it into the DOM using innerHTML without sanitization. An attacker who can push a .gltf file to any repository can execute arbitrary JavaScript in the context of any user who views the file.
Affected Versions
- Gitea 1.25.0 and later (3D file preview was introduced in 1.25 via the Online3DViewer integration)
- Confirmed on
gitea:1.25-nightly(SHAe33d1da...), which bundlesonline-3d-viewernpm package v0.16.0 - The upstream Online3DViewer library is the root cause
Severity
- Stored XSS: the payload persists in the repository and fires on every page view
- Executes under the Gitea origin with the victim's session (cookies, CSRF tokens)
- Any authenticated user viewing the file is compromised
- Enables full account takeover (token creation, settings modification, repository manipulation)
- No user interaction beyond viewing the file page is required
Details
Root Cause
When Online3DViewer parses a glTF file, it checks whether all extensionsRequired entries are supported. For unsupported extensions, it calls:
// In the Online3DViewer bundle (online-3d-viewer.js)
// Approximate offset 1142618 in the bundled chunk
this.SetError(yp("Unsupported extension: {0}.", unsupportedExtensions.join(", ")));
The SetError method stores this message, and Gitea's rendering code inserts it into the page using innerHTML:
// Gitea's error display handler
element.innerHTML = errorMessage; // unsanitized
The extension names from extensionsRequired are taken directly from the JSON file with no escaping or sanitization, allowing HTML injection.
Attack Vector
- An attacker creates a
.gltffile with a maliciousextensionsRequiredvalue:
{
"asset": {"version": "2.0"},
"buffers": [],
"extensionsRequired": ["<img src=x onerror=\"alert(document.cookie)\">"],
"scenes": []
}
-
The attacker pushes this file to any Gitea repository they have write access to (including forks of public repositories).
-
When any user navigates to the file's page in the Gitea web UI, the 3D viewer attempts to render it, encounters the "unsupported extension," and inserts the error message (containing the attacker's HTML) into the DOM via
innerHTML. -
The injected
<img onerror>handler executes arbitrary JavaScript under the Gitea origin with the victim's authenticated session.
Impact
From the XSS context, an attacker can:
- Create API access tokens for the victim by POSTing to
/user/settings/applicationswith the page's CSRF token - Read private repositories via same-origin API calls
- Modify repository contents (supply chain attacks)
- Escalate to admin if the victim is a Gitea administrator
- Exfiltrate data via
fetch,XMLHttpRequest, ornavigator.sendBeacon
Proof of Concept
Minimal PoC (alert box)
Save as poc.gltf and push to any Gitea 1.25+ repository:
{
"asset": {"version": "2.0"},
"buffers": [],
"extensionsRequired": ["<img src=x onerror=\"alert('XSS: '+document.domain)\">"],
"scenes": []
}
Navigate to the file in the Gitea web UI. The alert will fire.
Suggested Fixes
Sanitize or text-encode the error message before DOM insertion. Replace innerHTML with textContent for error display:
// Instead of:
element.innerHTML = errorMessage;
// Use:
element.textContent = errorMessage;
Alternatively, escape HTML entities in the error message before insertion.
Additional hardening
- Render 3D file previews inside a sandboxed
<iframe>withsandbox="allow-scripts"and a restrictive CSP (default-src 'none'), similar to how Gitea already handles SVG attachments - Apply Content-Security-Policy headers to file preview pages that restrict inline script execution
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | code.gitea.io/gitea | ≥ 1.25.0&&< 1.26.0 | 1.26.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea. 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 code.gitea.io/gitea to 1.26.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9cpj-qc93-vw8v 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-9cpj-qc93-vw8v 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-9cpj-qc93-vw8v. 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-9cpj-qc93-vw8v in your dependencies?
O3 detects GHSA-9cpj-qc93-vw8v across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.