Summary
Coder: PKCS#7 signature bypass in Azure instance identity allows unauthenticated agent token theft
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":"<target>"} 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.
Attack Path Diagram
Affected Versions
All versions of Coder v2 are affected.
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.
- Modify the
coder_agent.authvalue to betoken. - 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 of calif.io and Anthropic’s Security Team (ANT-2026-22445) for independently disclosing this issue!
Impact
An attacker on any Azure VM or with access to a publicly available Azure IMDS certificate from CT logs can:
- Steal an agent session token by sending a forged PKCS#7 envelope to
POST /api/v2/workspaceagents/azure-instance-identitywhich is unauthenticated. - 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.
- Git SSH private key via
CVE-2026-46354 has a CVSS score of 9.1 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.33.3, 2.32.2, 2.31.12, 2.30.8, 2.29.13, 2.24.5); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in #25286
The fix was backported to all supported release lines:
Frequently Asked Questions
- What is CVE-2026-46354? CVE-2026-46354 is a critical-severity security vulnerability in github.com/coder/coder/v2 (go), affecting versions >= 2.33.0-rc.0, < 2.33.3. It is fixed in 2.33.3, 2.32.2, 2.31.12, 2.30.8, 2.29.13, 2.24.5.
- How severe is CVE-2026-46354? CVE-2026-46354 has a CVSS score of 9.1 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by CVE-2026-46354?
github.com/coder/coder/v2(go) (versions >= 2.33.0-rc.0, < 2.33.3)github.com/coder/coder(go) (versions <= 0.27.3)
- Is there a fix for CVE-2026-46354? Yes. CVE-2026-46354 is fixed in 2.33.3, 2.32.2, 2.31.12, 2.30.8, 2.29.13, 2.24.5. Upgrade to this version or later.
- Is CVE-2026-46354 exploitable, and should I be worried? Whether CVE-2026-46354 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-46354 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-46354?
- Upgrade
github.com/coder/coder/v2to 2.33.3 or later - Upgrade
github.com/coder/coder/v2to 2.32.2 or later - Upgrade
github.com/coder/coder/v2to 2.31.12 or later - Upgrade
github.com/coder/coder/v2to 2.30.8 or later - Upgrade
github.com/coder/coder/v2to 2.29.13 or later - Upgrade
github.com/coder/coder/v2to 2.24.5 or later
- Upgrade