AI Threat Alert
A password-reset endpoint in Coder (`PUT /api/v2/users/{user}/password`) let any account holding the `user-admin` role silently reset an `owner` account's password and log in as that owner, escalating from a mid-tier admin role to full deployment control over templates, workspaces, licensing and organization settings. This matters because Coder is widely used to provision the isolated dev/agent workspaces where AI coding agents and ML pipelines actually run, so an owner-level compromise means an attacker can rewrite the templates that provision those environments, embedding backdoors that persist across every future workspace. The blast radius across the ecosystem is meaningful — the `coder/coder` module has 5,435 downstream dependents — but real-world exploitability is bounded: it requires an attacker to already hold the privileged `user-admin` role, there is no public exploit, PoC, or Nuclei template, and it is not in CISA KEV or EPSS-scored. CISOs running self-hosted Coder should patch to 2.34.2/2.33.8/2.32.7/2.29.17 (ESR) immediately and, until then, restrict `user-admin` grants to fully trusted operators as the vendor-recommended workaround. Audit logs for password-reset events targeting owner accounts and review who currently holds `user-admin` as an interim detection step.
What is the risk?
CVSS 7.2 (High) with AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H reflects low attack complexity and no user interaction once the prerequisite privilege is met, but PR:H (high privileges required) is the key limiting factor — this is a privilege-escalation bug, not an unauthenticated takeover. Practical risk concentrates in deployments that grant `user-admin` broadly (e.g., to helpdesk/ops staff, contractors, or via SSO group mapping) rather than reserving it for a small trusted set. No EPSS score, no CISA KEV listing, and no public exploit or scanner template exist, so this is not currently being mass-exploited; risk is best characterized as insider-threat / compromised-mid-tier-account exposure rather than internet-opportunistic exploitation.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Anthropic Python | go | >= 2.34.0, < 2.34.2 | 2.34.2 |
Do you use Anthropic Python? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Patch immediately to the release matching your line: 2.34.2, 2.33.8, 2.32.7, or 2.29.17 (ESR). Until patched, restrict the
user-adminrole to a minimal set of fully trusted administrators — do not grant it to contractors, support staff, or via broad SSO group mappings. Audit existinguser-adminrole assignments now to identify any over-provisioned accounts. For detection, review Coder audit logs for password-reset API calls (PUT /api/v2/users/{user}/password) targeting accounts holding theownerrole, especially resets not initiated by the owner's own session, and alert on any subsequent role self-assignment toowner.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-55077?
A password-reset endpoint in Coder (`PUT /api/v2/users/{user}/password`) let any account holding the `user-admin` role silently reset an `owner` account's password and log in as that owner, escalating from a mid-tier admin role to full deployment control over templates, workspaces, licensing and organization settings. This matters because Coder is widely used to provision the isolated dev/agent workspaces where AI coding agents and ML pipelines actually run, so an owner-level compromise means an attacker can rewrite the templates that provision those environments, embedding backdoors that persist across every future workspace. The blast radius across the ecosystem is meaningful — the `coder/coder` module has 5,435 downstream dependents — but real-world exploitability is bounded: it requires an attacker to already hold the privileged `user-admin` role, there is no public exploit, PoC, or Nuclei template, and it is not in CISA KEV or EPSS-scored. CISOs running self-hosted Coder should patch to 2.34.2/2.33.8/2.32.7/2.29.17 (ESR) immediately and, until then, restrict `user-admin` grants to fully trusted operators as the vendor-recommended workaround. Audit logs for password-reset events targeting owner accounts and review who currently holds `user-admin` as an interim detection step.
Is CVE-2026-55077 actively exploited?
No confirmed active exploitation of CVE-2026-55077 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-55077?
Patch immediately to the release matching your line: 2.34.2, 2.33.8, 2.32.7, or 2.29.17 (ESR). Until patched, restrict the `user-admin` role to a minimal set of fully trusted administrators — do not grant it to contractors, support staff, or via broad SSO group mappings. Audit existing `user-admin` role assignments now to identify any over-provisioned accounts. For detection, review Coder audit logs for password-reset API calls (`PUT /api/v2/users/{user}/password`) targeting accounts holding the `owner` role, especially resets not initiated by the owner's own session, and alert on any subsequent role self-assignment to `owner`.
What systems are affected by CVE-2026-55077?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, training pipelines.
What is the CVSS score for CVE-2026-55077?
CVE-2026-55077 has a CVSS v3.1 base score of 7.2 (HIGH). The EPSS exploitation probability is 0.61%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0106 Exploitation for Credential Access Compliance Controls Affected
What are the technical details?
Original Advisory
### 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](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/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!
Exploitation Scenario
An organization grants the `user-admin` role to a member of its platform/DevOps team to handle routine user provisioning in its self-hosted Coder deployment used for AI agent development. That team member (or an attacker who compromises their session/credentials) calls `PUT /api/v2/users/{owner-username}/password` to set a new password on the deployment's `owner` account — no knowledge of the original password is required. They log in as the owner, gain access to all workspace templates including those provisioning AI coding-agent and ML training environments, and modify a template's startup script to exfiltrate cloud credentials or API keys embedded in every future workspace, then self-assign the `owner` role on a secondary account to maintain persistent access even if the original reset is discovered.
Weaknesses (CWE)
CWE-285 — Improper Authorization: The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H References
Timeline
Related Vulnerabilities
CVE-2026-27775 8.8 Gitea: cached permission check allows repo takeover
Same package: anthropic CVE-2026-54449 8.8 LangBot: RCE via arbitrary STDIO MCP command
Same package: anthropic CVE-2026-7574 8.7 Claude Desktop: VM integrity bypass enables RCE
Same package: anthropic CVE-2026-55429 8.7 Coder: cross-workspace agent hijack via app ID reuse
Same package: anthropic CVE-2026-67428 8.5 Flyto2 Core: SSRF via unvalidated URLs in agent tools
Same package: anthropic