CVE-2026-55435: Coder AI Bridge Suspended User API Key Access

Technical summary

The AI Bridge proxy authentication logic in `coderd/aibridgedserver` uses the `Server.IsAuthorized` function to validate incoming requests. This function correctly checks the key format, expiration timestamp, secret, and whether the account is marked as deleted or a system account. However, it does not verify that the account is not suspended. Coder's suspension mechanism does not automatically invalidate existing API keys—it is an account state change only. As a result, an attacker with a valid, unexpired API key issued to a now-suspended user can authenticate to AI Bridge endpoints and perform actions the suspended account was previously authorized to perform. The vulnerability is classified as CWE-863 (Incorrect Authorization), reflecting the gap in access control checks.

Business impact

For most organizations, the business risk is contained. Suspension is typically an administrative action taken when an employee departs, violates policy, or requires temporary access revocation. If that person retains an API key and the key has not been rotated or revoked before suspension, they retain access to AI Bridge proxy functionality for the remaining lifetime of that key. This could enable a departing employee or insider threat to continue provisioning or modifying remote development environments. However, because API keys have expiration dates and are typically rotated periodically, and because the vulnerability requires the attacker to possess a key that was already issued, the window of exposure is usually weeks or months rather than indefinite. The risk is most acute in high-turnover environments or organizations with long API key lifespans and inconsistent key rotation practices.

Affected systems

Coder versions 2.30.0 through 2.34.1 are vulnerable. Patched versions are 2.32.7, 2.33.8, and 2.34.2. Any Coder deployment running an affected version and using AI Bridge proxy endpoints is at risk. Organizations on versions prior to 2.30.0 are not affected. If you maintain a Coder instance, verify your version against your deployment manifest or the `coder version` command output.

Exploitability

Exploitation requires two preconditions: the attacker must possess a valid, unexpired API key issued before the account suspension, and that key must be usable against AI Bridge endpoints in the target deployment. An attacker cannot forge keys or exploit authentication bypass without a genuine key. This means exploitation is primarily an insider threat vector—former employees, contractors, or departing team members with retained credentials. The barrier to exploitation is low once those preconditions are met; no special tools or techniques are required, only knowledge of the endpoint and a valid key. External threat actors would need to compromise a user's API key first, making this a secondary risk factor rather than a direct attack surface.

Remediation

Coder has released patches in versions 2.32.7, 2.33.8, and 2.34.2 that add account suspension checks to the `Server.IsAuthorized` validation logic. Upgrading to a patched version is the definitive fix. As an immediate workaround for deployed instances, administrators can manually revoke the API keys of suspended users via the Coder API endpoint `DELETE /api/v2/users/{user}/keys`, which deletes all keys for a given user. This should be done as part of the standard offboarding or suspension workflow until the system is patched.

Patch guidance

1. Identify your current Coder version using the `coder version` command or your infrastructure-as-code configuration. 2. If running version 2.30.0 or later, check whether your version is 2.32.7, 2.33.8, 2.34.2 or later. 3. Plan an upgrade to the nearest patched version that aligns with your release branch (e.g., 2.34.x users should upgrade to 2.34.2). 4. Before upgrading, review the Coder release notes for any breaking changes or migration steps. 5. Test the patch in a non-production environment first, then roll out to production during a maintenance window. 6. After patching, verify that the `IsAuthorized` function now rejects suspended users by conducting a test with a suspended test account and an old API key.

Detection guidance

Review your API audit logs for calls to AI Bridge proxy endpoints authenticated with API keys from suspended accounts. Most Coder deployments log authentication attempts; filter logs by timestamp (looking for attempts after account suspension) and by the user ID associated with the API key. Check for patterns such as repeated proxy endpoint calls from a suspended user's key within hours or days of suspension—legitimate activity is unlikely. For proactive defense, audit all active API keys periodically and cross-reference them against your current user roster and suspension list. Consider implementing a policy that revokes all user API keys immediately upon suspension, independent of this patch, as a defense-in-depth measure.

Why prioritize this

This vulnerability merits medium priority for most organizations. The CVSS score of 5.4 (Medium) reflects limited attack scope and the requirement for the attacker to possess an already-issued credential. Patch it within your standard maintenance cycle—there is no need for emergency response unless you operate in a high-risk environment with frequent turnover and sensitive development workloads. If you have robust API key rotation practices and revoke keys on suspension, your practical risk is low. If you have long-lived keys and weak offboarding processes, raise priority and implement the workaround immediately while preparing to patch.

Risk score, explained

The CVSS v3.1 score of 5.4 reflects a network-accessible vulnerability (AV:N) that requires a login session (PR:L), has low complexity (AC:L), affects confidentiality and integrity minimally (C:L/I:L), and does not affect availability (A:N). The score is not in the Critical or High range because the attack requires pre-existing authenticated access (an issued API key), not the ability to exploit authentication from scratch. The Medium severity appropriately signals that the risk is real but not urgent for organizations with standard security practices.

Frequently asked questions