Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/getarcaneapp/arcane/backend <= 1.19.3
Fixed in
1.19.4· Vendor fix available
Issue
ProjectService.GetProjectFileContent returns the contents of any Docker Compose include directive declared in a project's compose file before any path-traversal validation runs. Because ProjectService.CreateProject writes attacker-supplied compose content to disk without validating include paths, an authenticated user can create a project whose compose file declares include: ['../../../../etc/passwd'], then read the include via the project file API. The result is arbitrary read of any file readable by the Arcane backend process, including /app/data/arcane.db (the SQLite database containing every user's password hash and API key), enabling escalation to admin and, via Arcane's Docker control plane, RCE on the host. Details Root cause #1 — CreateProject writes compose content without validation (backend/internal/services/projectservice.go:1605-1644): Compare with UpdateProject (projectservice.go:2494, :2577), which calls validateComposeContentForUpdate. That validator (line…
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getarcaneapp/arcane/backend <= 1.19.1
Fixed in
1.19.2· Vendor fix available
Issue
The PUT /api/environments/{id}/templates/variables endpoint, which writes the system-wide .env.global file used for variable substitution in every project's compose file, is missing an admin authorization check. Any authenticated non-admin user can call this endpoint with their bearer token or API key and overwrite the global environment variables that are merged into every project deployment. By overriding values like REGISTRY, IMAGE, DATABASEURL, or SECRETKEY that other users reference via ${VAR} in compose files, an attacker can redirect image pulls to attacker-controlled registries (supply-chain RCE on the Docker host), exfiltrate database credentials, or disrupt all projects. Details The endpoint is registered at backend/internal/huma/handlers/templates.go:374: The handler at backend/internal/huma/handlers/templates.go:889 performs no role check: This is anomalous compared to every other admin-sensitive handler in the codebase, all of which begin with if err :=…
Recommended action: Upgrade to 1.19.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getarcaneapp/arcane/backend <= 1.18.1
Fixed in
1.19.0· Vendor fix available
Issue
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: 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…
Recommended action: Upgrade to 1.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getarcaneapp/arcane/backend <= 1.18.1
Fixed in
1.19.0· Vendor fix available
Issue
Arcane's huma-based REST API exposes nine endpoints under /api/customize/git-repositories and /api/git-repositories/sync for managing GitOps source repositories and their stored credentials. Eight of those endpoints (list, create, get, update, delete, test, listBranches, browseFiles) never call the checkAdmin(ctx) helper that every other admin-managed resource (container registries, environments, users, API keys, swarm, settings, system, notifications, events) uses, and the huma authentication middleware deliberately enforces only authentication, not the admin role. As a result, any logged-in user with the default user role can list, create, modify, delete, and test git repository configurations. By repointing an existing repository's URL to an attacker-controlled host while omitting the token/sshKey fields (which UpdateRepository only rewrites when explicitly supplied), the attacker causes Arcane to decrypt the legitimate PAT/SSH key on its next /test, /branches, or /files…
Recommended action: Upgrade to 1.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getarcaneapp/arcane/backend < 1.18.0
Fixed in
1.18.0· Vendor fix available
Issue
Four GET endpoints under /api/templates in Arcane's Huma backend are registered without any Security requirement, allowing any unauthenticated network client to list and read the full Compose YAML and .env content of every custom template stored in the instance. Because Arcane's UI exposes a "Save as Template" flow on the project / swarm-stack creation pages that persists the operator's real env content (database passwords, API keys, etc.) verbatim, this missing authorization is an unauthenticated read of operator secrets in practice — not a theoretical info-disclosure. The frontend explicitly treats /customize/templates/ as an authenticated area (PROTECTEDPREFIXES in frontend/src/lib/utils/redirect.util.ts), and every CRUD operation (POST/PUT/DELETE) on the same paths requires a Bearer/API key, so this is a clear backend authorization gap, not intended public access. Details Affected file: backend/internal/huma/handlers/templates.go:194-228. In RegisterTemplates, four…
Recommended action: Upgrade to 1.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getarcaneapp/arcane/backend <= 1.17.2
Fixed in
1.17.3· Vendor fix available
Issue
The /api/templates/fetch endpoint accepts a caller-supplied url parameter and performs a server-side HTTP GET request to that URL without authentication and without URL scheme or host validation. The server's response is returned directly to the caller. type. This constitutes an unauthenticated SSRF vulnerability affecting any publicly reachable Arcane instance. Details - No allowlist or denylist of destination hosts/CIDRs - No requirement for the caller to be authenticated Response handling produces four distinct outcomes observable by the caller: - Valid JSON targets return a fully reflected response body if the returned fields fit the expected internal struct - Non-JSON HTTP 200 responses produce an error leaking the first byte of the response ("Invalid JSON response: invalid character '<'...") - Non-200 responses leak the HTTP status code - TCP-level failures distinguish between closed ports ("connection refused") and filtered ones ("i/o timeout") PoC Send an…
Recommended action: Upgrade to 1.17.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getarcaneapp/arcane/backend < 0.0.0-20260114065515-5a9c2f92e11f
Fixed in
0.0.0-20260114065515-5a9c2f92e11f· Vendor fix available
Issue
Arcane’s updater service supported lifecycle labels com.getarcaneapp.arcane.lifecycle.pre-update and com.getarcaneapp.arcane.lifecycle.post-update that allowed defining a command to run before or after a container update. The label value is passed directly to /bin/sh -c without sanitization or validation. Because any authenticated user (not limited to administrators) can create projects through the API, an attacker can create a project that specifies one of these lifecycle labels with a malicious command. When an administrator later triggers a container update (either manually or via scheduled update checks), Arcane reads the lifecycle label and executes its value as a shell command inside the container. If the container is configured with host volume mounts in its Compose definition, the executed command may be able to read from or write to the host filesystem through the mounted paths. This can enable data theft and, in some configurations, escalation to full host…
Recommended action: Upgrade to 0.0.0-20260114065515-5a9c2f92e11f (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.