VYPR

Coder

by Coder

Source repositories

CVEs (4)

  • CVE-2026-46354criMay 19, 2026
    risk 0.59cvss epss

    ## Summary `azureidentity.Validate()` verifies that the PKCS#7 signer certificate chains to a trusted Azure CA but never verifies the PKCS#7 signature itself. An attacker can embed a legitimate Azure certificate alongside arbitrary content e.g. `{"vmId":""}` and the forged `vmId` will be accepted returning the victim workspace agent's session token. **No authentication is required.** The attacker only needs to know a target VM's `vmId` which is a `UUIDv4`. > that's a practical limitation which would typically require prior access to be exploited ## Root Cause In unpatched Coder releases the signature over the PKCS#7 content is not validated - only the signing certificate is checked. ## Impact An attacker on any Azure VM or with access to a publicly available Azure IMDS certificate from CT logs can: 1. **Steal an agent session token** by sending a forged PKCS#7 envelope to `POST /api/v2/workspaceagents/azure-instance-identity` which is unauthenticated. 2. **With the stolen token** access: - **Git SSH private key** via `GET /workspaceagents/me/gitsshkey`: push to repositories and impersonate the workspace owner. - **OAuth access tokens** via `GET /workspaceagents/me/external-auth`: GitHub, GitLab, and Bitbucket tokens in plaintext. - **Workspace secrets** via the agent manifest: environment variables, file paths, and API keys. ## Attack Path Diagram ## Affected Versions All versions of Coder v2 are affected. ## Patches Fixed in [#25286 ](https://github.com/coder/coder/pull/25286) The fix was backported to all supported release lines: | Patched Versions | | --- | | [**v2.33.3**](https://github.com/coder/coder/releases/tag/v2.33.3) | | [**v2.32.2**](https://github.com/coder/coder/releases/tag/v2.32.2) | | [**v2.31.12**](https://github.com/coder/coder/releases/tag/v2.31.12) | | [**v2.30.8**](https://github.com/coder/coder/releases/tag/v2.30.8) | | [**v2.29.13**](https://github.com/coder/coder/releases/tag/v2.29.13) | | [**v2.24.5**](https://github.com/coder/coder/releases/tag/v2.24.5) | ## Workarounds If unable to patch we recommend immediately reconfiguring any Azure templates to use token authentication rather than `azure-instance-identity` until the patch is released and you are fully upgraded. 1. Modify the [`coder_agent.auth`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#auth-1) value to be `token`. 2. Add `CODER_AGENT_TOKEN=${coder_agent.main.token}` to the set of environment variables for the Coder Workspace Agent initialization script. ## Recognition We'd like to thank [Ben Tran](https://github.com/bencalif) of [calif.io](http://calif.io) and Anthropic’s Security Team (`ANT-2026-22445`) for independently disclosing this issue!

  • CVE-2026-45796May 19, 2026
    risk 0.00cvss epss

    ## Summary Unauthenticated semi-blind Server-Side Request Forgery (SSRF) via the Azure instance identity endpoint (`POST /api/v2/workspaceagents/azure-instance-identity`). An external attacker can force the Coder server to issue HTTP GET requests to arbitrary internal or external hosts by submitting a crafted PKCS#7 signature. The server does not return the target's response body, but error messages in the API response reveal whether the target is reachable and what type of failure occurred. ## Details The `POST /api/v2/workspaceagents/azure-instance-identity` endpoint accepts a PKCS#7 signature without authentication. During certificate chain verification, [`azureidentity.Validate()`](https://github.com/coder/coder/blob/aa0e288b88/coderd/azureidentity/azureidentity.go#L83-L88) iterates over the signer certificate's `IssuingCertificateURL` extension and fetches each URL using `http.DefaultClient` with no host restriction, no private-IP blocking, and no response-size limit. An attacker crafts a self-signed certificate whose Common Name matches `*.metadata.azure.com` (passing the `allowedSigners` regex) and whose `IssuingCertificateURL` points to an attacker-chosen target. The server fetches that URL and feeds the response body into `x509.ParseCertificate`. The parsed result is discarded, but the wrapped error string is returned verbatim in the JSON response via `Detail: err.Error()`. Connection-level errors ("connection refused", "i/o timeout", DNS failures) and certificate-parse errors give the attacker enough signal to infer host reachability and port state without seeing the actual response content. **Root causes:** 1. No allowlist on `IssuingCertificateURL` hosts. Any URL was accepted. 2. `http.DefaultClient` was used. It follows redirects and connects to private, link-local, and loopback addresses. 3. Unbounded `io.ReadAll` on the response body (memory exhaustion vector). 4. Raw `err.Error()` was returned in the JSON response, leaking internal HTTP client errors to the caller. ## Impact This is a semi-blind SSRF: the server makes the outbound request but the HTTP response body is consumed by `x509.ParseCertificate` and never returned to the attacker. - **Internal network reconnaissance.** The attacker can map internal hosts and ports by observing error differentiation in the API response: "connection refused" (port closed), "i/o timeout" (host unreachable or firewalled), DNS failure (host does not exist), or certificate-parse error (port open and responding). This enables systematic scanning of the internal network from the Coder server's vantage point. - **Requests to sensitive endpoints.** The server can be directed to hit cloud metadata services (e.g. `http://169.254.169.254/`), internal admin interfaces, or other services. The attacker cannot read the response content, but the request itself may have side effects depending on the target. - **Error-based information disclosure.** Wrapped Go HTTP client errors in the `Detail` field expose internal hostnames, IP addresses, port numbers, and network topology details. - **Memory exhaustion.** The unbounded `io.ReadAll` on the response body allows an attacker to point `IssuingCertificateURL` at a large resource, forcing the server to buffer it entirely in memory. ## Patches Fixed in [#25274](https://github.com/coder/coder/pull/25274) (commit [`57b11d405`](https://github.com/coder/coder/commit/57b11d405f17492aa789d4b9ff33366f961a37f8)): The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.33 | [v2.33.3](https://github.com/coder/coder/releases/tag/v2.33.3) | | 2.32 | [v2.32.2](https://github.com/coder/coder/releases/tag/v2.32.2) | | 2.31 | [v2.31.12](https://github.com/coder/coder/releases/tag/v2.31.12) | | 2.30 | [v2.30.8](https://github.com/coder/coder/releases/tag/v2.30.8) | | 2.29 | [v2.29.13](https://github.com/coder/coder/releases/tag/v2.29.13) | | 2.24 (ESR) | [v2.24.5](https://github.com/coder/coder/releases/tag/v2.24.5) | ## Workarounds If the Azure identity-auth mechanism is not being used then restrict access to the corresponding endpoint (`/api/v2/workspaceagents/azure-instance-identity`) using ingress firewall and/or proxy ACLs. ### Recognition We'd like to thank [Ben Tran](https://github.com/bencalif) of [calif.io](http://calif.io/) and Anthropic's Security Team (`ANT-2026-22447`) for independently disclosing this issue!

  • CVE-2025-66411Dec 3, 2025
    risk 0.00cvss epss 0.00

    Coder allows organizations to provision remote development environments via Terraform. Prior to 2.26.5, 2.27.7, and 2.28.4, Workspace Agent manifests containing sensitive values were logged in plaintext unsanitized. An attacker with limited local access to the Coder Workspace (VM, K8s Pod etc.) or a third-party system (SIEM, logging stack) could access those logs. This vulnerability is fixed in 2.26.5, 2.27.7, and 2.28.4.

  • CVE-2025-58437Sep 6, 2025
    risk 0.00cvss epss 0.00

    Coder allows organizations to provision remote development environments via Terraform. In versions 2.22.0 through 2.24.3, 2.25.0 and 2.25.1, Coder can be compromised through insecure session handling in prebuilt workspaces. Coder automatically generates a session token for a user when a workspace is started. It is automatically exposed via coder_workspace_owner.session_token. Prebuilt workspaces are initially owned by a built-in prebuilds system user. When a prebuilt workspace is claimed, a new session token is generated for the user that claimed the workspace, but the previous session token for the prebuilds user was not expired. Any Coder workspace templates that persist this automatically generated session token are potentially impacted. This is fixed in versions 2.24.4 and 2.25.2.