GHSA-q2pj-8v84-9mh5
HIGHGHSA-q2pj-8v84-9mh5 is a high-severity (CVSS 8.2) Cross-site Scripting (XSS) vulnerability in github.com/getarcaneapp/arcane/backend. O3 Security confirms whether GHSA-q2pj-8v84-9mh5 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Arcane Backend: Unauthenticated reflected XSS via SVG color parameter enables admin account takeover
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-q2pj-8v84-9mh5.
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-q2pj-8v84-9mh5 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 0 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
github.com/getarcaneapp/arcane/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
The unauthenticated GET /api/app-images/logo endpoint reflects a user-supplied color query parameter into the body of an SVG document via strings.ReplaceAll with no escaping. The substitution lands inside a <style> element of the embedded logo.svg, allowing an attacker to close the style block and inject executable <script> content. Because the response is served as image/svg+xml and Arcane sets no Content-Security-Policy or X-Content-Type-Options headers, navigating a logged-in admin victim to a crafted URL executes attacker-controlled JavaScript in Arcane's origin and rides the victim's HttpOnly JWT cookie to fully compromise the admin account.
Details
The route is registered in backend/internal/huma/handlers/appimages.go:53-61 with an explicitly empty security requirement, marking it as public:
huma.Register(api, huma.Operation{
OperationID: "get-logo",
Method: http.MethodGet,
Path: "/app-images/logo",
...
Security: []map[string][]string{}, // explicit: no auth
}, h.GetLogo)
backend/internal/huma/middleware/auth.go:209-213 honors the empty Security value by returning reqs.isRequired == false and short-circuiting with next(ctx), so no JWT/API-key check runs.
GetLogoInput.Color (appimages.go:23) is declared with no validation tags:
type GetLogoInput struct {
Full bool `query:"full" default:"false" ...`
Color string `query:"color" doc:"Optional accent color override ..."`
}
The handler passes the value straight through getImageWithColor → ApplicationImagesService.GetImageWithColor → applyAccentColorToSVG (backend/internal/services/app_images_service.go:79-105):
svgStr = strings.ReplaceAll(svgStr, "fill:#6D28D9", fmt.Sprintf("fill:%s", accentColor))
svgStr = strings.ReplaceAll(svgStr, "fill:#6d28d9", fmt.Sprintf("fill:%s", accentColor))
The bundled backend/resources/images/logo.svg contains:
<style id="style1" type="text/css">.st0{fill:#6d28d9}</style>
so a color value like red}</style><script>fetch('/api/users',...)</script><style>x{ produces a valid SVG that closes the <style> element and embeds a <script> element. The response Content-Type is image/svg+xml (from pkg/utils/image/image_util.go), and a grep of the backend confirms no Content-Security-Policy, X-Content-Type-Options, or framing headers are emitted on any route.
Browsers execute scripts in SVG documents loaded as top-level navigations or via <iframe src=…> / window.open(…). The execution context is origin(arcane-host), so the victim's __Host-token / token HttpOnly JWT cookie (recognized by extractTokenFromCookieHeaderInternal at auth.go:274-286) is automatically attached to subsequent same-origin fetch() calls. From there the attacker can invoke any privileged API the victim possesses — most damagingly POST /api/users to create a new admin account, after which the attacker has standalone admin access to manage Docker containers, registries, GitOps secrets, and SSH/registry credentials stored by Arcane.
Impact
- Same-origin script execution from an unauthenticated, reachable URL — only user interaction (clicking/visiting the crafted link) is required.
- Full session-riding against any authenticated user, including admins. Because Arcane manages Docker daemons, container exec, image registries, and GitOps repositories, an attacker who lands script execution as an admin victim can:
- Create persistent attacker-controlled admin accounts via
POST /api/users. - Read/modify secrets stored in environments, registries, and Git repositories the admin can access.
- Start or exec into containers on connected Docker hosts.
- Create persistent attacker-controlled admin accounts via
- HttpOnly cookies do not mitigate the issue — cookies are auto-attached to same-origin
fetch(). Absence of CSP andX-Content-Type-Options: nosniffremoves available defenses-in-depth.
Defense-in-depth — add to all responses (and especially to /api/app-images/*):
X-Content-Type-Options: nosniffContent-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; img-src 'self' data:on the SVG image responses (or the most permissive policy compatible with the frontend on app routes).- Consider serving these images with
Content-Disposition: inlineand from a separate cookie-less origin to remove the same-origin session-riding primitive entirely.
Also enforce the same allowlist on the settings write path (SettingsService → AccentColor) so a stored XSS variant cannot be introduced via the settings API.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/getarcaneapp/arcane/backend | all versions | 1.19.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/getarcaneapp/arcane/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/getarcaneapp/arcane/backend to 1.19.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q2pj-8v84-9mh5 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-q2pj-8v84-9mh5 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-q2pj-8v84-9mh5. 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-q2pj-8v84-9mh5 in your dependencies?
O3 detects GHSA-q2pj-8v84-9mh5 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.