CVE-2026-45627 — backend
HIGHCVE-2026-45627 is a high-severity (CVSS 8.2) Cross-site Scripting (XSS) vulnerability in github.com/getarcaneapp/arcane/backend. A fix is available for github.com/getarcaneapp/arcane/backend — see the affected versions and patch details below.
Arcane: Unauthenticated reflected XSS via SVG color parameter in /api/app-images/logo 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 CVE-2026-45627.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-45627 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 380,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
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.0go get github.com/getarcaneapp/arcane/backend@v1.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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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 CVE-2026-45627 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is CVE-2026-45627 in your dependencies?
Find it across Go, including transitive dependencies.