CVE-2026-96626 in Arcane
Summary
by MITRE • 10/17/2026
Arcane is an interface for managing Docker containers, images, networks, and volumes. Prior to 2.5.0, UpdateRegistry and TestRegistry in backend/api/services/container_registry_service.go allow the registry URL to change while preserving the stored encrypted token. When a holder of registries:update and registries:test repoints a generic registry URL without supplying a replacement token, TestRegistry decrypts the preserved token and RegistryLogin sends it to the attacker-controlled host because normalizeRegistryServerAddressInternal does not restrict the destination. This exposes the stored container-registry PAT or password and can enable image access or tampering. This issue is fixed in version 2.5.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in Arcane versions prior to 2.5.0 represents a critical authentication credential exposure flaw rooted in improper validation of registry URL changes during administrative operations. Arcane serves as an interface for managing Docker infrastructure, including containers, images, networks, and volumes. The core issue resides within the backend service logic responsible for handling container registries, specifically affecting the UpdateRegistry and TestRegistry functions located in the file backend/api/services/container_registry_service.go. These endpoints are designed to allow administrators with specific permissions to modify or validate registry configurations. However, the implementation fails to enforce a strict binding between the registry endpoint URL and its associated authentication credentials when an update is performed without providing new token data.
The technical mechanism of this flaw involves the preservation of stored encrypted tokens even when the target registry server address is altered by a user possessing registries:update or registries:test permissions. When such a user repoints the generic registry URL to a domain under their control but omits supplying a replacement authentication token, the system retains the previously stored credentials associated with that account entry. During the execution of the TestRegistry function, the application decrypts this preserved token and subsequently passes it to RegistryLogin. The critical failure occurs because the internal helper function normalizeRegistryServerAddressInternal does not implement sufficient restrictions or validation checks on the destination address. Consequently, the decrypted authentication payload is transmitted directly to an attacker-controlled host rather than a legitimate registry server.
This behavior results in a severe confidentiality breach where stored container-registry personal access tokens (PATs) or passwords are exfiltrated to unauthorized parties. The operational impact extends beyond simple credential theft; once an adversary obtains these valid credentials, they can authenticate against the actual Docker registries associated with those accounts. This enables the attacker to pull sensitive application images for analysis, push maliciously crafted images that may contain backdoors or malware into official repositories, and potentially compromise downstream systems that consume these tampered artifacts. The vulnerability effectively allows a lower-privileged user to escalate their impact by leveraging administrative credential storage mechanisms against external targets they control.
From a standards perspective, this flaw aligns with CWE-209, which describes the generation of an error message that includes sensitive information, although in this case it is more accurately categorized under CWE-798: Use of Hard-coded Credentials or CWE-359: Exposure of Private Information Due to Inadequate Protection. The attack vector corresponds to ATT&CK technique T1078: Valid Accounts, as the attacker utilizes legitimate credentials obtained through exploitation to gain unauthorized access. Furthermore, it relates to MITRE D3FEND's concept of Credential Access and Data Exfiltration via network communication channels.
To mitigate this vulnerability, organizations must immediately upgrade Arcane to version 2.5.0 or later, where the developers have addressed the logic flaw by ensuring that registry URL changes require explicit re-authentication or token updates if the destination domain differs from the original trusted context. In environments where upgrading is not instantly feasible, administrators should restrict access to the registries:update and registries:test endpoints to only those users with absolute trust and high-level privileges. Additionally, implementing network segmentation policies can limit the ability of compromised internal services to communicate freely with external attacker-controlled hosts. Regular auditing of registry configurations and monitoring for unusual outbound authentication attempts from Arcane instances are also recommended defensive measures to detect potential exploitation activities early.