TL;DR: A CVE-2026-46354 flaw in Coder lets an unauthenticated attacker forge a PKCS#7 envelope, obtain a workspace agent session token, and potentially steal Git SSH keys and OAuth credentials from Azure-backed development workspaces, according to Orca Security. The issue shows how instance-identity trust can become secret-exposure risk when signature verification is incomplete.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Orca Security's research: A critical Coder vulnerability can let an unauthenticated attacker bypass Azure instance identity checks and harvest workspace agent secrets.
Why it matters: It matters because development workspaces often hold the credentials that bridge source code, CI/CD, and cloud access, so one trust failure can widen into supply chain exposure.
By the numbers:
- CVE-2026-46354 carries a CVSS score of 9.1, reflecting the severity of the signature bypass and secret exposure path.
- The issue affects Coder v2.33.0-rc.0 through v2.33.2, v2.32.0-rc.0 through v2.32.1, v2.31.0 through v2.31.11, v2.30.0 through v2.30.7, v2.29.0 through v2.29.12, and all versions prior to v2.24.5.
Context
Coder’s Azure instance identity flow was supposed to turn machine trust into a controlled authentication path for workspace agents. In this case, the control boundary breaks earlier than expected because the platform validates certificate lineage but not the PKCS#7 signature itself, which leaves room for forged identity material.
For IAM and NHI practitioners, the important question is not whether Azure instance identity is a useful pattern, but whether the application verifies the full cryptographic envelope before converting it into a bearer token. When that check fails, the workspace agent becomes a secret delivery mechanism instead of a trusted workload.
The result is a high-impact secret exposure path across developer workspaces, source control, and CI/CD integrations. That makes the issue relevant to NHI governance, workload identity design, and secrets handling in cloud development platforms.
Key questions
A: The platform can mint a valid session token from forged identity material, which turns unauthenticated input into workspace access. That failure means the real control boundary is not the certificate chain but the full signed envelope, and any downstream secrets tied to the agent become reachable.
Q: Why does a signature bypass in a development platform create supply chain risk?
A: Because workspace agents often hold credentials for Git hosting and CI/CD systems, one compromised session can expose the paths that move code into production. The risk is not only secret theft but unauthorized access to the systems that depend on those secrets.
Q: What are the signs that instance-identity based authentication is failing safely?
A: You should see strict signature verification, no token issuance on malformed envelopes, and clear rejection of identity material that cannot be cryptographically proven. If an application accepts a trusted certificate without validating the signed payload, the control is not working as intended.
Q: Should teams disable Azure instance identity or patch first after this issue?
A: Patch first where a fixed version is available, and disable the feature immediately as a temporary containment step only when patching is delayed. The right order is to remove exposure fast, then restore the control on a version that verifies the full signature path.
Technical breakdown
How the PKCS#7 validation bypass works
The vulnerable function checks whether a signer certificate chains to a trusted Azure CA, but it does not verify the PKCS#7 signature over the envelope. That matters because a valid certificate chain only proves that the certificate exists and is trusted, not that the payload was signed by the holder for this request. An attacker can pair a publicly discoverable Azure IMDS certificate with attacker-controlled content and submit it to the unauthenticated endpoint. The application then mistakes forged identity material for a legitimate Azure instance identity assertion.
Practical implication: Treat certificate-chain validation without signature verification as incomplete identity proofing for machine-authentication flows.
Why the workspace agent token becomes the pivot point
The endpoint converts the forged Azure instance identity into a workspace agent session token. Once that token exists, the attacker is no longer trying to break the cloud provider’s identity system directly. Instead, they are abusing a token issued by the development platform to move from identity assertion to workspace access. This is the core control failure: the platform trusts a weakly validated assertion enough to mint a session credential, and that credential becomes the real security boundary.
Practical implication: Validate the issuance path for session tokens as strictly as the upstream identity assertion they depend on.
Why secret exposure is broader than one stolen key
The reported impact is not limited to one credential type. The attack path can surface workspace agent session tokens, Git SSH private keys, and OAuth credentials for GitHub, GitLab, and Bitbucket integrations. That creates a compound exposure model where a single forged assertion can open source repositories, CI/CD systems, and downstream cloud workflows. In practice, the exploit turns a workspace trust failure into a secrets-management failure with supply chain implications.
Practical implication: Scope remediation to every secret class reachable from the workspace agent, not only the token exposed at the endpoint.
Threat narrative
Attacker objective: The attacker aims to obtain workspace and developer credentials that unlock source repositories, automation pipelines, and adjacent cloud access.
- Entry occurs through an unauthenticated POST to the Azure instance identity endpoint with a forged PKCS#7 envelope.
- Credential abuse follows when the application mints a valid workspace agent session token from the forged assertion.
- Escalation happens as the attacker uses that token to enumerate and extract Git SSH private keys and OAuth credentials tied to the workspace.
- Impact is secret exposure that can extend into source code access, CI/CD access, and broader infrastructure compromise.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
PKCS#7 chain validation without envelope signature verification is not identity assurance. The issue is not that Azure instance identity exists, but that the application accepted a certificate chain as if it were proof of request authenticity. That breaks the premise that machine identity assertions are trustworthy only when both provenance and signature integrity are checked. Practitioners should treat this as a failure of the identity acceptance boundary, not just a bug in one parser.
Instance-identity trust debt accumulates when bearer tokens are minted from weak assertions. Once the platform converts a forged identity document into a session token, the token becomes the true attack surface. This is the same pattern that repeatedly appears in NHI compromises: a low-friction trust shortcut upstream creates a high-value credential downstream. The governance question is whether any machine-authentication path can still be called controlled if its issuance step can be triggered anonymously.
Secret exposure in developer workspaces is an identity governance issue, not only a code-security issue. Git SSH keys and OAuth credentials sitting behind workspace agents connect developers to repositories and pipelines, which means one compromised session can span multiple trust domains. That makes workspace identity a governance boundary for NHI lifecycle, secrets scope, and downstream access containment. Security teams should treat development platforms as credential brokers with blast radius, not just remote terminals.
Workspace agent session tokens are the pivot credential in this attack pattern. The vulnerability shows that the security model depends on a short chain of trust between cloud instance identity and application-issued session credentials. When that chain is weak, the platform can become a credential issuer for an unauthenticated attacker. Practitioners need to re-evaluate any design that assumes cloud instance identity is self-validating once a trusted certificate appears.
Instance identity was designed for cloud-attested machines, not for unauthenticated proof synthesis. That assumption fails when an attacker can construct a believable Azure identity envelope without owning the underlying workload. The implication is that identity governance for workload access must be anchored in verified request integrity, not just trusted certificate lineage.
From our research library:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- Read next: Guide to NHI Rotation Challenges
What this signals
Identity trust must be measured at issuance, not assumed after certificate lookup. This incident shows why machine-authentication paths need to be reviewed as credential-minting flows, not just protocol integrations. When a platform turns signed identity material into a session token, the failure mode is about issuance integrity and downstream secret scope, not only about the input format.
Workspace agents now sit inside the NHI governance perimeter. Teams that still treat development environments as tooling rather than identity-bearing systems will miss the blast radius created by Git SSH keys, OAuth tokens, and agent session credentials. The governance model has to follow the credential, not the container or the IDE.
79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs. A vulnerability like this widens that problem because one unauthenticated path can expose multiple secret classes at once.
For practitioners
- Disable unauthenticated instance-identity trust paths Turn off Azure instance identity authentication in Coder deployments until patched versions are in place, especially where internet exposure exists. Keep the control disabled for any environment that cannot verify the full PKCS#7 signature path.
- Patch to a fixed Coder release immediately Move affected instances to v2.33.3, v2.32.2, v2.31.12, v2.30.8, v2.29.13, or v2.24.5. Treat all affected v2 and v1 installations as urgent remediation candidates until their version is confirmed.
- Inventory secrets reachable from workspace agents Map every Git SSH key, OAuth token, and repository integration that a workspace agent can reach so you know the blast radius if session issuance is bypassed.
- Prioritise internet-facing Coder instances Rank exposed development platforms ahead of internal-only deployments because the attack requires only network access and a UUIDv4 vmId, not user interaction or authentication.
- Review token issuance logic for cryptographic completeness Verify that every machine-authentication path checks the full signature on signed identity material before minting a session token, not just the certificate chain.
Key takeaways
- The vulnerability shows that incomplete PKCS#7 validation can turn Azure instance identity into an unauthenticated token issuance path.
- The impact is broad because the exposed workspace agent can surface Git SSH keys, OAuth credentials, and session tokens.
- The limiting control is full cryptographic verification before session minting, paired with temporary feature disablement until patched versions are deployed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The flaw turns forged Azure identity material into a trusted session token. |
| NHI-02 — Secret Leakage | The exploit can expose Git SSH keys and OAuth credentials from workspaces. | |
| NHI-05 — Overprivileged NHI | A single agent token can open access to repositories and pipelines beyond its intended scope. | |
| Recommendation — Verify machine-authentication paths end-to-end before issuing any workspace session token. Reduce secret sprawl in workspaces and revoke any credential reachable from a compromised agent. Constrain workspace agent scope to the minimum repositories and services it genuinely needs. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path steals credentials and uses them to pivot into other systems. |
| Recommendation — Map the issue to credential access and lateral movement detections around workspace-issued tokens. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is about whether entitlement issuance is properly bound to authenticated identity. |
| Recommendation — Review entitlement issuance so tokens cannot be minted from unauthenticated or incomplete identity proofs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle matters because stolen workspace credentials become reusable access paths. |
| Recommendation — Enforce authenticator management to rotate, revoke, and scope workspace credentials tightly. | ||
Key terms
- PKCS#7 Signature Bypass: A cryptographic validation failure where software checks the certificate chain but not the actual signature on the signed envelope. In machine-authentication flows, this can let attackers supply forged content that appears trusted enough to trigger token issuance.
- Workspace Agent Token: A workspace agent token is a credential that lets a development workspace prove itself to a control plane or related service. In practice, it becomes a high-value identity artifact because it can unlock broader access to repositories, secrets, or automation if issuance is not tightly verified.
- Instance Identity: Instance identity is the machine identity a cloud-hosted workload uses to prove it is an authorised instance. It is only trustworthy when the platform validates the full cryptographic assertion, not just part of the certificate path or metadata surrounding it.
- Secret Exposure Path: The route by which credentials, tokens, certificates, or other secrets become reachable after a compromise. In platform incidents, this can include service account context, configuration stores, and shared runtime nodes, which makes revocation and containment part of the same response.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org