Coder PKCS#7 bypass exposes workspace agent secrets on Azure

At a glance

What this is: This is a high-severity Coder vulnerability that allows unauthenticated theft of workspace agent tokens and related secrets through a forged Azure instance-identity flow.

Why it matters: It matters because workspace identities, developer tokens, and source-code access can all sit behind the same trust path, so IAM, PAM, and NHI teams need to treat platform authentication flaws as supply-chain and blast-radius problems.

By the numbers:

• CVE-2026-46354 carries a CVSS score of 9.1.
• v2.33.0-rc.0 through v2.33.2

👉 Read Orca Security's analysis of the Coder PKCS#7 bypass and Azure workspace identity flaw

Context

A forged instance-identity flow is a trust failure, not just a signature bug. In this case, the Coder endpoint accepted a PKCS#7 envelope that looked credible enough to reach token issuance, which means Azure-backed workspace identity was being used as a gateway to secrets rather than as a tightly verified proof of origin.

For IAM and NHI programmes, the important detail is the blast radius. A single unauthenticated request path could surface workspace agent session tokens, Git SSH private keys, and OAuth credentials, turning a development access control flaw into repository exposure and pipeline compromise.

This is typical of modern platform identity failures: the control plane assumes cryptographic proof was fully validated, but the implementation only checked part of the chain. When developer workspaces depend on instance identity, that partial check becomes a credential-extraction path.

Key questions

Q: What breaks when a workspace identity flow accepts forged identity data?

A: The trust boundary collapses before authentication ever occurs. If a platform issues session tokens from partially verified identity data, an attacker can impersonate the workspace agent, inherit downstream access, and reach secrets that were never meant to be exposed through an unauthenticated path.

Q: Why do developer workspaces create supply-chain risk when identity is misvalidated?

A: Because workspace identities often bridge into Git repositories, OAuth-connected services, and CI/CD systems. When the identity layer is weak, the attacker does not just gain a login. They gain a route into code, automation, and build infrastructure that can affect many other systems.

Q: How can security teams know whether workspace agent tokens are being over-trusted?

A: Look for token issuance paths that are not tied to strong proof of origin, and then test whether those tokens can reach secrets, repositories, or pipelines without additional checks. If a token can unlock multiple systems after a single validation step, it is being over-trusted.

Q: Who is accountable when an unauthenticated workspace identity flaw exposes secrets?

A: Accountability sits with the platform owner first, then with the teams responsible for identity validation, secret access, and downstream integration governance. In regulated or audited environments, the control failure also belongs in incident reporting because it can affect source code, credentials, and operational resilience.

Technical breakdown

PKCS#7 verification bypass in Azure instance identity

The flaw sits in validation logic that confirms a signer certificate chains to a trusted Azure CA, but does not verify the cryptographic signature on the PKCS#7 envelope itself. That means the platform can be persuaded to accept attacker-controlled content if the outer certificate chain looks legitimate. In practice, this is a classic trust-boundary mistake: the certificate appears valid, while the payload that it is supposed to bind remains unauthenticated. Because the endpoint is unauthenticated, the attacker does not need an existing session, only the vmId and a forged envelope.

Practical implication: treat certificate-chain checks and signature verification as separate controls, and verify both before any token is issued.

Workspace agent session token issuance

Once the bypass succeeds, the platform issues a valid workspace agent session token. That token is the high-value identity artifact because it can authenticate the agent to the workspace control plane and unlock adjacent secrets. In developer-platform architectures, token issuance is often the real privilege boundary, not the login screen. If issuance can be induced without genuine identity proof, the attacker inherits the trust of the workspace agent and can move from request forgery into authenticated access to internal developer resources.

Practical implication: instrument token issuance as a protected trust event, not just an application response.

Secret exposure through developer workspace identity

The attack chain does not stop at the token. The resulting session can reveal Git SSH private keys and OAuth credentials used for GitHub, GitLab, and Bitbucket integrations, which can in turn expose source repositories and CI/CD pipelines. That makes the flaw an identity-to-supply-chain problem: a single compromised workspace identity can become a route into code, automation, and downstream infrastructure. This is why remote development platforms must be treated as identity brokers with repository and pipeline consequences.

Practical implication: tie workspace identity events to repository, pipeline, and secret-access monitoring so compromise is visible before code access is abused.

Threat narrative

Attacker objective: The attacker seeks authenticated access to workspace-managed secrets and downstream developer infrastructure without ever proving legitimate identity.

1. Entry occurs when an attacker submits a forged PKCS#7 envelope to the unauthenticated Azure instance-identity endpoint using only the target VM’s vmId.
2. Credential access occurs when the validation flaw causes Coder to issue a valid workspace agent session token even though the signature on the envelope was never verified.
3. Impact follows when the stolen session can expose Git SSH private keys and OAuth credentials, enabling repository access, CI/CD abuse, and potential supply-chain compromise.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Instance identity is only safe when the entire cryptographic object is verified. This flaw shows that checking certificate lineage without validating the envelope signature leaves a false sense of assurance. The control failed at the trust boundary, not at privilege management, which means the security model trusted metadata instead of proof. Practitioners should read this as a verification failure, not a configuration mistake.

Workspace agents are NHI brokers, not just developer conveniences. Once a workspace identity can yield Git SSH keys and OAuth tokens, the platform sits between human access, machine access, and source-code trust. That makes the compromise path broader than a single application flaw. It exposes the governance gap where an NHI is allowed to mint access into repositories and pipelines with insufficient attestation.

Secret exposure through remote development platforms creates an identity blast radius. The real risk is not only token theft but the chain reaction from one compromised workspace identity into source control and CI/CD systems. This is where NHI governance overlaps with software supply-chain security, because the attacker is not just stealing a credential, they are inheriting an operating context. Practitioners should treat workspace identity as a high-risk issuer.

Runtime trust in developer platforms depends on provenance, not just reachability. The endpoint was network-accessible, but the deeper issue is that reachability was allowed to substitute for proof. That pattern is common in identity systems that assume a signed-looking request is the same as a valid request. Security teams need to re-evaluate any workspace or agent flow that can mint secrets from partial validation.

Secret sprawl becomes exploit sprawl when a single platform can access multiple downstream systems. OAuth access for GitHub, GitLab, and Bitbucket means one identity failure can radiate across multiple ecosystems. The named concept here is identity blast radius: the number of downstream systems reachable from one broken trust decision. In this case, the blast radius is defined by the workspace agent’s ability to reach code, keys, and pipelines.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• For a broader control baseline, review Ultimate Guide to NHIs for governance, lifecycle, and visibility patterns.

What this signals

Identity blast radius is the practical metric this incident should change. If a workspace token can unlock repository access, OAuth grants, and CI/CD paths, the issue is not just authentication integrity but downstream reach. Teams should inventory where remote development platforms can mint credentials and which systems they can reach without a second proof step.

The article’s remediation advice points to a wider control pattern: reduce dependency on unauthenticated trust paths and make secret-access decisions visible in telemetry. That aligns with Zero Trust thinking, but the operational test is simple. If one broken identity check can expose multiple classes of secret, the programme still treats provenance as optional.

For practitioners

• Disable Azure instance identity authentication where it is not essential Remove the unauthenticated trust path from Coder deployments until patched versions are in place, and confirm that the configuration change is applied consistently across all environments.
• Patch every affected Coder version immediately Move to the fixed releases listed by the vendor, then inventory any downstream workspaces that may still be running versions older than v2.24.5 or within the affected release bands.
• Treat workspace agent tokens as high-risk credentials Log issuance, correlate it with runtime reachability, and alert on unusual token creation from internet-facing or unexpected workspace identities before repository access is exercised.
• Map workspace identity to repository and pipeline exposure Identify every Git SSH key, OAuth credential, and CI/CD path reachable from the workspace agent so incident response can revoke the right downstream access in the right order.

Key takeaways

• CVE-2026-46354 turns a partial PKCS#7 verification failure into a path for unauthenticated workspace token issuance and secret theft.
• The practical scale of the issue is broader than one application because exposed workspace identity can reach Git SSH keys, OAuth tokens, and CI/CD systems.
• The control that would have limited the damage is complete cryptographic verification before token issuance, paired with removal of unnecessary Azure instance-identity trust paths.

Key terms

• 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.
• Identity Blast Radius: Identity blast radius is the downstream scope that becomes reachable when one identity is compromised or misvalidated. For remote development platforms, it includes the number of secrets, repositories, and pipelines that can be reached from a single trusted token or agent session.

Deepen your knowledge

Workspace identity validation and secret exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are hardening developer-platform identity flows like the one described here, it is worth exploring.

This post draws on content published by Orca Security: the Coder vulnerability affecting Azure instance identity authentication and workspace agent secrets. Read the original.