Summary
Trigger.dev's CLI authorization-code flow can mint a Personal Access Token when a logged-in user visits a crafted authorization-code URL, without requiring a consent step. An attacker may lure the user to that URL and then retrieve the resulting token through an unauthenticated token endpoint, potentially taking over the account.
Trigger.dev's CLI authorization-code flow can mint a Personal Access Token when a logged-in user visits a crafted authorization-code URL, without requiring a consent step. An attacker may lure the user to that URL and then retrieve the resulting token through an unauthenticated token endpoint, potentially taking over the account.
Affected context
The vulnerability occurs in Trigger.dev deployments using the affected CLI authorization-code flow. Risk is present when visiting an authorization-code URL in an authenticated browser session automatically creates a Personal Access Token and the resulting token can be retrieved without additional authentication or user confirmation.
The vulnerability occurs in Trigger.dev deployments using the affected CLI authorization-code flow. Risk is present when visiting an authorization-code URL in an authenticated browser session automatically creates a Personal Access Token and the resulting token can be retrieved without additional authentication or user confirmation.
Exploit preconditions
- Attack surface: Browser-accessible CLI authorization-code and token endpoints
- Required access: An attacker needs to create or obtain an authorization code and socially engineer a logged-in user into visiting the corresponding URL
- Trigger point: The victim's browser loads the authorization-code endpoint while carrying the victim's authenticated session
- Why exploitation is possible: The request changes server-side authentication state without CSRF protection or an explicit consent step, while a separate unauthenticated endpoint exposes the minted token
- Attack surface: Browser-accessible CLI authorization-code and token endpoints
- Required access: An attacker needs to create or obtain an authorization code and socially engineer a logged-in user into visiting the corresponding URL
- Trigger point: The victim's browser loads the authorization-code endpoint while carrying the victim's authenticated session
- Why exploitation is possible: The request changes server-side authentication state without CSRF protection or an explicit consent step, while a separate unauthenticated endpoint exposes the minted token
Why this happens
The flow performs a security-sensitive state change in response to a browser request without verifying that the request originated from an authorized application action or received explicit user consent. This is a cross-site request forgery weakness mapped to CWE-352, compounded by exposing the newly minted Personal Access Token through an unauthenticated retrieval path. The insecure pattern is allowing ambient browser credentials to authorize token creation without anti-CSRF controls, user confirmation, or protected token delivery.
The flow performs a security-sensitive state change in response to a browser request without verifying that the request originated from an authorized application action or received explicit user consent. This is a cross-site request forgery weakness mapped to CWE-352, compounded by exposing the newly minted Personal Access Token through an unauthenticated retrieval path. The insecure pattern is allowing ambient browser credentials to authorize token creation without anti-CSRF controls, user confirmation, or protected token delivery.
Potential impact
- An attacker may obtain a victim's Personal Access Token
- The attacker could access or modify resources available to the victim
- The victim's Trigger.dev account may be taken over
- Stored secrets, project data, or automation workflows could be exposed or altered
- Compromised tokens may enable further unauthorized API activity until revoked
- An attacker may obtain a victim's Personal Access Token
- The attacker could access or modify resources available to the victim
- The victim's Trigger.dev account may be taken over
- Stored secrets, project data, or automation workflows could be exposed or altered
- Compromised tokens may enable further unauthorized API activity until revoked
General mitigation guidance
Mitigation generally focuses on requiring explicit authorization for token creation and protecting all token issuance and retrieval operations.
Common defensive patterns include:
- Require an intentional user consent step before minting a Personal Access Token
- Apply CSRF protections such as unpredictable state values, origin checks, and appropriate SameSite cookie settings
- Require authentication and authorization for token retrieval endpoints
- Deliver tokens only through a tightly bound, single-use authorization transaction
- Avoid exposing tokens through browser-readable or unauthenticated responses
- Apply least privilege, short lifetimes, scoped permissions, and rapid revocation for issued tokens
- Treat authorization-code values as sensitive, single-use credentials with expiration
Mitigation generally focuses on requiring explicit authorization for token creation and protecting all token issuance and retrieval operations.
Common defensive patterns include:
- Require an intentional user consent step before minting a Personal Access Token
- Apply CSRF protections such as unpredictable state values, origin checks, and appropriate SameSite cookie settings
- Require authentication and authorization for token retrieval endpoints
- Deliver tokens only through a tightly bound, single-use authorization transaction
- Avoid exposing tokens through browser-readable or unauthenticated responses
- Apply least privilege, short lifetimes, scoped permissions, and rapid revocation for issued tokens
- Treat authorization-code values as sensitive, single-use credentials with expiration
How teams detect issues like this
Organizations can detect similar weaknesses through:
- Static analysis and code review checks for state-changing GET requests
- Review of token issuance flows for missing consent, CSRF validation, or origin verification
- API policy checks requiring authentication for token creation and retrieval
- Testing that authorization codes are single-use, short-lived, transaction-bound, and cannot be replayed cross-site
- Monitoring for unusual token issuance, immediate token retrieval, or access from unexpected locations
- Automated security testing for cross-origin requests and browser-based authorization flows
Organizations can detect similar weaknesses through:
- Static analysis and code review checks for state-changing GET requests
- Review of token issuance flows for missing consent, CSRF validation, or origin verification
- API policy checks requiring authentication for token creation and retrieval
- Testing that authorization codes are single-use, short-lived, transaction-bound, and cannot be replayed cross-site
- Monitoring for unusual token issuance, immediate token retrieval, or access from unexpected locations
- Automated security testing for cross-origin requests and browser-based authorization flows
