GHSA-9pr4-rf97-79qh
HIGHGHSA-9pr4-rf97-79qh is a high-severity (CVSS 8.7) Cross-site Scripting (XSS) vulnerability in github.com/enchant97/note-mark/backend. O3 Security confirms whether GHSA-9pr4-rf97-79qh is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Note Mark has Stored XSS via Unrestricted Asset Upload
Blast Radius
github.com/enchant97/note-mark/backendReal-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
A stored same-origin XSS vulnerability allows any authenticated user to upload an HTML, SVG, or XHTML file as a note asset and have it executed in a victim’s browser under the application’s origin. Because the application serves these files inline without a safe content type and without nosniff, browsers can sniff and render active content, giving the attacker access to authenticated Note Mark API actions as the victim.
Details
This issue results from three compounding flaws in the asset handling and delivery path.
1. Asset delivery can be used as an attack vector
The asset delivery route can be used to deliver attacker-controlled uploaded content directly to a victim by URL.
Relevant route:
handlers/assets.go:40
huma.Get(api, "/api/notes/{noteID}/assets/{assetID}", h.GetNoteAssetContentByID)
This makes the uploaded asset reachable by direct navigation, which provides the delivery mechanism for the payload.
2. Text-based active content is served with an empty Content-Type
The asset handler relies on h2non/filetype for content-type detection:
handlers/assets.go:147
kind, _ := filetype.Match(buf)
if kind != filetype.Unknown {
contentType = kind.MIME.Value
}
The detection library uses magic-byte matching and does not identify text-based formats such as HTML, SVG, JavaScript, XML, or XHTML. For those files, filetype.Match returns Unknown, leaving Content-Type unset or empty.
As a result, uploaded active content is served without an authoritative MIME type.
3. Files are rendered inline and sniffed by the browser
The asset response is sent with inline disposition:
handlers/assets.go:153
w.Header().Set("Content-Disposition", fmt.Sprintf("inline; filename=\"%s\"", asset.Name))
At the same time, the response does not set:
X-Content-Type-Options: nosniff
This combination is dangerous:
- the uploaded file contains attacker-controlled active markup
- the browser is instructed to render it inline
- the response does not provide a trustworthy content type
- content sniffing is not disabled
Under these conditions, browsers may detect HTML or SVG content and execute embedded JavaScript. Because the asset is served from the application’s own origin, the script runs with same-origin access to the application and its authenticated APIs.
This turns an uploaded asset into a stored XSS payload that executes when a victim opens the asset URL.
PoC
The issue can be reproduced by uploading a text-based active content file such as HTML or SVG as a note asset, then opening the served asset URL in a browser and observing that script executes in the context of the application origin.
Impact
- Type: Stored same-origin cross-site scripting (XSS)
- Who is impacted: Any user who can be induced to open a malicious asset URL, and any deployment allowing asset uploads
- Security impact: An attacker can execute JavaScript in the victim’s authenticated application context, allowing access to private notes, books, profile data, and authenticated API actions
- Privileges required: A valid low-privilege user account capable of uploading note assets
- User interaction: Required, because the victim must navigate to the malicious asset URL
- Scope: Changed, because attacker-controlled content executes in the victim’s origin and impacts other users rather than remaining confined to the attacker’s own account
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/enchant97/note-mark/backend | all versions | 0.0.0-20260411145018-6bb62842ccb9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/enchant97/note-mark/backend. 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 github.com/enchant97/note-mark/backend to 0.0.0-20260411145018-6bb62842ccb9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9pr4-rf97-79qh 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-9pr4-rf97-79qh 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-9pr4-rf97-79qh. 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-9pr4-rf97-79qh in your dependencies?
O3 detects GHSA-9pr4-rf97-79qh across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.