Arcane EUVD-2026-103175

Requires an authenticated Arcane principal holding BOTH the registries:update and registries:test permissions, plus a pre-existing generic (non-ECR) registry entry that already has a stored encrypted token. The attacker changes the registry URL to an attacker-controlled host WITHOUT supplying a replacement token (omitted or empty token field); the vulnerable normalizeRegistryServerAddressInternal does not restrict the destination host, so the preserved credential is decrypted and transmitted on test/login. Limiting factors: exploitation is gated by those two specific registry permissions (not available to unprivileged users), depends on a stored credential existing, and does not apply to ECR-type registries which were excluded from the vulnerable path.

This is a credible, moderately-high priority credential-disclosure flaw rather than a hype-driven high-CVSS score. The vendor CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, 8.5) is internally consistent with the mechanism: a network-reachable, low-complexity action performed by an already-authenticated operator that leaks a secret belonging to a separate security authority (the external registry), justifying the scope change and High confidentiality impact. The key limiting signal is PR:L - exploitation requires an existing user who already holds the registries:update and registries:test permissions, so this is a privilege-abuse/insider or post-compromise escalation path, not an unauthenticated internet drive-by. No EPSS score, KEV listing, or public exploit was provided in the input, so there is no evidence of active or widespread exploitation; the only 'code' available is the upstream FIX diff (PR #3317), which is not an attack POC. Net: real and worth patching promptly where Arcane manages registries, but the authentication prerequisite and the niche product footprint keep realistic mass-exploitation risk lower than the 8.5 alone suggests.

An Arcane user who holds the registries:update and registries:test permissions edits an existing generic container registry, changing only its URL to a host the attacker controls and leaving the token field empty. When the registry connection is tested, Arcane decrypts the previously stored registry PAT/password and sends it to the attacker-controlled host during login, handing over valid registry credentials. No public exploit code was identified at time of analysis; only the vendor's fix in PR #3317 is available.