GHSA-jpjh-jm2p-39hh
HIGHGHSA-jpjh-jm2p-39hh is a high-severity (CVSS 8.8) CWE-862 vulnerability in github.com/getarcaneapp/arcane/backend. O3 Security confirms whether GHSA-jpjh-jm2p-39hh is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Arcane: Missing admin authorization on global variables endpoint
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- 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-jpjh-jm2p-39hh.
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-jpjh-jm2p-39hh 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 362,881 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 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, DATABASE_URL, or SECRET_KEY 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:
huma.Register(api, huma.Operation{
OperationID: "updateGlobalVariables",
Method: "PUT",
Path: "/environments/{id}/templates/variables",
...
Security: []map[string][]string{
{"BearerAuth": {}},
{"ApiKeyAuth": {}},
},
}, h.UpdateGlobalVariables)
The handler at backend/internal/huma/handlers/templates.go:889 performs no role check:
func (h *TemplateHandler) UpdateGlobalVariables(ctx context.Context, input *UpdateGlobalVariablesInput) (*UpdateGlobalVariablesOutput, error) {
if h.templateService == nil {
return nil, huma.Error500InternalServerError("service not available")
}
if input.EnvironmentID != "0" {
return h.updateGlobalVariablesForRemoteEnvironmentInternal(ctx, input)
}
if err := h.templateService.UpdateGlobalVariables(ctx, input.Body.Variables); err != nil {
return nil, huma.Error500InternalServerError((&common.GlobalVariablesUpdateError{Err: err}).Error())
}
...
}
This is anomalous compared to every other admin-sensitive handler in the codebase, all of which begin with if err := checkAdmin(ctx); err != nil { return nil, err } (see users.go, events.go, swarm.go, settings.go, apikeys.go, environments.go, notifications.go, container_registries.go, git_repositories.go, system.go). The helper exists at backend/internal/huma/handlers/helpers.go:12 but is never invoked from templates.go.
The auth middleware at backend/internal/huma/middleware/auth.go:192-254 only validates that some authenticated user is present (Bearer JWT, API key, or environment access token); it does not enforce roles. Role enforcement is the responsibility of each handler.
That this endpoint is intended to be admin-only is evidenced by the UI customization search at backend/internal/huma/handlers/customize.go:82-91 and :106-114, which explicitly hides the variables and registries categories from non-admin users:
if !humamw.IsAdminFromContext(ctx) {
filtered := []category.Category{}
for _, cat := range results.Results {
if cat.ID != "registries" && cat.ID != "variables" {
filtered = append(filtered, cat)
}
}
results.Results = filtered
...
}
The corresponding container_registries.go handlers all enforce admin via checkAdmin() (e.g. container_registries.go:273,329,360,387,442); the equivalent enforcement for the global-variables write was forgotten.
The service layer at backend/internal/services/template_service.go:1107 writes attacker-supplied keys/values to <projectsDirectory>/.env.global:
func (s *TemplateService) UpdateGlobalVariables(ctx context.Context, vars []env.Variable) error {
envPath, err := s.getGlobalVariablesPath(ctx)
...
for _, v := range vars {
if strings.TrimSpace(v.Key) == "" { continue }
key := strings.TrimSpace(v.Key)
value := strings.TrimSpace(v.Value)
if strings.ContainsAny(value, " \t\n\r#") {
value = fmt.Sprintf(`"%s"`, strings.ReplaceAll(value, `"`, `\"`))
}
_, _ = fmt.Fprintf(&builder, "%s=%s\n", key, value)
}
if err := projects.WriteFileWithPerm(envPath, builder.String(), common.FilePerm); err != nil { ... }
}
That file is then loaded for every project at deploy time via backend/pkg/projects/env.go:65-82 (EnvLoader.LoadEnvironment → loadAndMergeGlobalEnv):
if strings.TrimSpace(l.projectsDir) != "" {
globalEnvPath := filepath.Join(l.projectsDir, GlobalEnvFileName)
if err := l.loadAndMergeGlobalEnv(ctx, globalEnvPath, envMap, injectionVars); err != nil ...
}
loadAndMergeGlobalEnv (env.go:94-125) populates both envMap (used by compose-go for ${VAR} substitution in compose files) and injectionVars (auto-injected into containers). The result: a single non-admin write to the global variables endpoint changes the resolved compose state of every project on the host.
Additionally, the key field is only strings.TrimSpace'd (template_service.go:1128); embedded newlines inside the key are not removed, so a key like "FOO\nINJECTED" will write two lines into .env.global, allowing arbitrary key injection and overwrite of variables an attacker did not include in their request body.
Impact
- Cross-project supply-chain RCE on the Docker host. Compose files commonly reference
${REGISTRY}/${IMAGE}:${TAG}. By pointingREGISTRY(orIMAGE) at an attacker-controlled registry, the next deploy of any affected project pulls and runs attacker code with whatever privileges Arcane gives that container (commonly Docker socket access, host volume mounts, etc.). - Credential theft from other users' projects. Variables like
DATABASE_URL,SMTP_HOST,WEBHOOK_URL,S3_ENDPOINTcan be redirected to attacker-controlled servers; the next deploy will hand the new connection strings to applications that then submit credentials/data to the attacker. - Cross-tenant integrity and availability. A single non-admin user can corrupt
.env.globalto break every project on the instance. - Bypass of intended privilege boundary. The UI explicitly hides the variables and registries surfaces from non-admins, indicating these are admin-only controls; this finding closes the gap between the documented privilege model and the API enforcement.
The privilege delta is significant: the project clearly distinguishes admin from non-admin users (separate roles, admin-only UI categories, checkAdmin() enforced on dozens of other endpoints), yet this endpoint grants a non-admin the ability to execute attacker-controlled images on the host on behalf of every other tenant.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/getarcaneapp/arcane/backend | all versions | 1.19.2 |
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.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jpjh-jm2p-39hh 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-jpjh-jm2p-39hh 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-jpjh-jm2p-39hh. 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-jpjh-jm2p-39hh in your dependencies?
O3 detects GHSA-jpjh-jm2p-39hh across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.