Join our Newsletter — 33% off our NHI Course

Coder Azure instance identity bypass: what IAM teams need to know

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 21730
Topic starter  

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.

Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Critical Coder Signature Bypass Exposes Developer Keys and Tokens”.

By the numbers:

  • 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.

Key questions

Q: What breaks when a workspace agent trusts Azure instance identity without verifying the PKCS#7 signature?

A: The platform can mint a valid session token from forged identity material, which turns unauthenticated input into workspace access.

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.

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.

Practitioner guidance

  • 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.
  • 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.
  • 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.

Bottom line: The vulnerability shows that incomplete PKCS#7 validation can turn Azure instance identity into an unauthenticated token issuance path.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →


This topic was modified 1 day ago by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 21566
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: Coder PKCS#7 bypass exposes workspace agent secrets on Azure



   
ReplyQuote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 21566
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: Coder PKCS#7 bypass exposes workspace agent secrets on Azure



   
ReplyQuote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 21566
 

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.

A few things that frame the scale:

  • 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.

A question worth separating out:

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.

👉 Read our full editorial: Coder PKCS#7 bypass exposes workspace agent secrets on Azure


This post was modified 1 day ago by NHI Mgmt Group

   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.