Trigger.dev CLI CSRF Flaw in Authorization Flow Allows Account Takeover

Trigger.dev contains a cross-site request forgery vulnerability in its CLI authorization-code flow. The issue affects versions prior to 4.5.2 and allows attackers to take over user accounts by stealing personal access tokens.

What happened

The vulnerability exists in the Trigger.dev command-line interface for versions earlier than 4.5.2. According to the NVD record, the flaw is classified as CWE-352, which relates to cross-site request forgery. The issue stems from how the system handles the authorization-code flow within the CLI environment.

When a user loads the path /account/authorization-code/<code>, the system mints a Personal Access Token. This action occurs without any consent step from the user. An attacker can generate an unauthenticated code and then lure a logged-in user to that specific URL.

Once the victim visits the link, the attacker can retrieve the victim's Personal Access Token. This retrieval happens through the unauthenticated /api/v1/token endpoint. The attacker gains full account access using the stolen token, effectively taking over the compromised account.

Why it matters

Security operations teams must understand that this flaw allows account takeover without traditional authentication bypasses. The attacker relies on social engineering to get the victim to visit a crafted URL. This makes the threat dependent on user interaction rather than a direct server-side exploit.

The exposure of the Personal Access Token is significant because it grants persistent access. Unlike a session cookie, a PAT often remains valid until explicitly revoked. This means the attacker can maintain control of the account even after the user logs out or changes their password, if the token is not revoked.

What to watch

• Monitor logs for requests to the /api/v1/token endpoint from unexpected IP addresses.
• Look for unusual activity on accounts shortly after users click external links.
• Check for new Personal Access Tokens being generated without corresponding user consent logs.
• Alert on any access to /account/authorization-code paths from untrusted sources.

Signals worth monitoring

Teams usually start by examining web server access logs for requests to the specific authorization endpoints mentioned in the advisory. Look for patterns where a user agent interacts with the token retrieval endpoint immediately after an authorization code URL is accessed. Check whether there are multiple failed attempts or rapid sequential requests to the unauthenticated token endpoint, which could indicate an attacker trying to harvest tokens. Review user session logs for sudden changes in activity location or unusual API calls made under the guise of a legitimate user. These behavioral anomalies often precede a full account compromise in CSRF scenarios.

Background: Cross-site request forgery (CSRF)

Cross-site request forgery tricks a victim’s browser into sending unwanted state-changing requests to a trusted site. Attackers rely on the browser automatically including session cookies. Defenses include synchronizer tokens, same-site cookie attributes, and verifying the Origin header to ensure requests originate from your own domain.

Read the full guide: Cross-Site Request Forgery (CSRF): Mechanisms, Mitigations, and Edge Cases

What to do and how to stay safe: Trigger.dev

• Update Trigger.dev CLI to version 4.5.2 or later once the vendor provides an update.
• Revoke all existing Personal Access Tokens for affected accounts to invalidate stolen credentials.
• Audit recent account activity for unauthorized changes or new tokens generated after the vulnerability was disclosed.
• Educate users to avoid clicking on unsolicited links that direct them to authorization pages.

General security guidance from the Firewall Chronicle newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Trigger.dev are affected by this vulnerability?

The vulnerability affects Trigger.dev CLI versions prior to 4.5.2.

What is the CVSS score for CVE-2026-114089?

The Common Vulnerability Scoring System rate is 8.7, which is classified as HIGH severity.

How does the attacker obtain the Personal Access Token?

The attacker lures a logged-in user to a specific URL, then retrieves the token from the unauthenticated /api/v1/token endpoint.