Arcane Backend: Unauthenticated reflected XSS via SVG color parameter enables admin account takeover

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.
• HttpOnly cookies do not mitigate the issue — cookies are auto-attached to same-origin fetch(). Absence of CSP and X-Content-Type-Options: nosniff removes available defenses-in-depth.

Defense-in-depth — add to all responses (and especially to /api/app-images/*):

• X-Content-Type-Options: nosniff
• Content-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: inline and 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.