Gitlab.com — CraftedSignal Threat Feed

Coder Azure Instance Identity PKCS#7 Signature Bypass Leads to Unauthenticated Agent Token Theft (CVE-2026-46354)

hello@craftedsignal.io — Tue, 19 May 2026 20:05:00 +0000

Coder v2 is susceptible to a critical vulnerability where the azureidentity.Validate() function fails to properly validate the PKCS#7 signature when using Azure instance identity for authentication. This flaw allows an unauthenticated attacker to bypass security measures by embedding a legitimate Azure certificate alongside a forged vmId within a PKCS#7 envelope. Successful exploitation allows retrieval of the victim workspace agent’s session token, granting unauthorized access to sensitive resources. The attacker only requires knowledge of the target VM’s vmId (UUIDv4), which, while a limitation, could be obtained through prior access or reconnaissance. This vulnerability impacts all versions of Coder v2 prior to the patched versions released in May 2026.

Attack Chain

Attacker identifies a target Coder workspace agent and obtains its vmId UUIDv4.
Attacker crafts a malicious PKCS#7 envelope containing a legitimate Azure certificate and a forged vmId targeting the identified workspace.
Attacker sends a POST request to the /api/v2/workspaceagents/azure-instance-identity endpoint with the crafted PKCS#7 envelope. This endpoint is unauthenticated.
Coder’s azureidentity.Validate() function incorrectly validates only the signer certificate, failing to verify the PKCS#7 signature itself.
The forged vmId is accepted, and the attacker retrieves the workspace agent’s session token.
Attacker uses the stolen token to access the GET /workspaceagents/me/gitsshkey endpoint to retrieve the Git SSH private key.
Attacker uses the stolen token to access GET /workspaceagents/me/external-auth endpoint, exfiltrating OAuth access tokens for GitHub, GitLab, and Bitbucket.
Attacker uses the stolen token to access workspace secrets via the agent manifest, including environment variables, file paths, and API keys.

Impact

Successful exploitation of this vulnerability (CVE-2026-46354) grants an attacker unauthorized access to sensitive resources within Coder workspaces. This can lead to complete compromise of the workspace, including the ability to push malicious code to repositories using the stolen Git SSH private key, impersonate the workspace owner, and access sensitive environment variables, file paths, and API keys. If an attacker gains access to source code repositories and developer secrets, they can cause significant data breaches, intellectual property theft, and supply chain attacks.

Recommendation

Immediately patch Coder instances to the latest versions (>= v2.33.3, v2.32.2, v2.31.12, v2.30.8, v2.29.13, v2.24.5) to address CVE-2026-46354.
As a temporary workaround, reconfigure Azure templates to use token authentication instead of azure-instance-identity, as described in the advisory. Specifically, modify the coder_agent.auth value to token.
Implement the provided Sigma rule to detect suspicious POST requests to the /api/v2/workspaceagents/azure-instance-identity endpoint with potentially crafted PKCS#7 envelopes.
Monitor web server logs for abnormal activity and unauthorized access attempts to the /api/v2/workspaceagents/azure-instance-identity, /workspaceagents/me/gitsshkey, and /workspaceagents/me/external-auth endpoints.

Arcane Git Repository Authentication Bypass Leads to Credential Exfiltration and GitOps Tampering (CVE-2026-45625)

hello@craftedsignal.io — Mon, 18 May 2026 13:45:14 +0000

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 never call the checkAdmin(ctx) helper used by other admin-managed resources, and the authentication middleware 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, 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, exfiltrating plaintext Git credentials. This affects Arcane versions 1.18.1 and earlier.

Attack Chain

The attacker authenticates to the Arcane backend using a normal user account, either through registration or a pre-existing account.
The attacker sends a GET request to /api/customize/git-repositories to enumerate all configured Git repositories, obtaining their IDs, URLs, and authentication types.
The attacker crafts a PUT request to /api/customize/git-repositories/{id} with a JSON payload containing the key url set to an attacker-controlled domain (e.g., https://attacker.tld/repo.git). The token or sshKey fields are intentionally omitted to preserve the existing encrypted credentials.
The Arcane backend updates the repository configuration, changing the repository URL while retaining the encrypted credentials.
The attacker sends a POST request to /api/customize/git-repositories/{id}/test to trigger a connection test, or alternatively triggers a GET request to .../branches or .../files to list branches or browse files.
Arcane decrypts the stored token or SSH key and attempts to authenticate to the attacker-controlled URL using HTTP Basic authentication or SSH key authentication.
The attacker’s server receives the decrypted credentials, which are exposed in cleartext.
Optionally, the attacker cleans up by sending another PUT request to restore the original URL or DELETE requests to all repos for DoS.

Impact

The vulnerability leads to cleartext exfiltration of stored Git credentials (PATs and SSH keys) configured by administrators for GitOps repositories. Stolen credentials grant write access to source repos, CI secrets, container registries, and production systems. Non-admin users can create, modify, and delete Git repository configurations, potentially injecting malicious code into deployments. An attacker can also trigger a denial of service by deleting repository configurations. Information disclosure of private repo contents is possible by listing files via the API. The default Arcane installations create new accounts with role user, making the attack easily exploitable. This has a critical impact on supply chain integrity and overall system security.

Recommendation

Apply authorization checks on the /api/customize/git-repositories and /api/git-repositories/sync endpoints, ensuring that only admin users can manage Git repository configurations.
Implement stricter validation and sanitization of input data, particularly the repository URL, to prevent redirection to malicious hosts.
Deploy the Sigma rule “Detect Arcane Git Repository URL Manipulation” to identify attempts to modify Git repository URLs to attacker-controlled domains.
Deploy the Sigma rule “Detect Arcane Git Repository Test Connection to External Domain” to detect attempts to test connections to external domains after a URL manipulation.
Upgrade Arcane backend to a patched version beyond 1.18.1 that addresses CVE-2026-45625.