Summary
Trigger.dev’s organization-level Slack OAuth flow uses the target Trigger.dev organization ID directly as the OAuth state value. The callback does not verify that the authenticated browser session initiated the OAuth transaction.
An attacker can authorize the Trigger.dev Slack application in an attacker-controlled Slack workspace, preserve the unredeemed callback URL, and convince an authenticated member of a target Trigger.dev organization to open it. Trigger.dev may then store the attacker-controlled Slack integration in the victim organization.
Safe reproduction design
I did not test Trigger.dev production or contact Slack.
A safe local regression test can:
-
Create a target organization and an authenticated victim member.
-
Ensure the victim session never initiated Slack OAuth.
-
Mock oauth.v2.access() so ATTACKER_CODE returns credentials for a synthetic attacker-controlled workspace.
-
Send the victim session to:
/integrations/slack/callback?code=ATTACKER_CODE&state=ORG_TARGET
-
On the vulnerable revision, verify that the exchange occurs and an integration for ORG_TARGET is created with the attacker workspace.
-
After remediation, verify rejection occurs before token exchange and that no integration or secret is created.
This report is based on a high-confidence static source trace. The local runtime harness was not executed because the available offline dependency cache lacked @changesets/cli@2.26.2.
Impact
The attacker may cause a victim Trigger.dev organization to connect an attacker-selected Slack workspace. Subsequent operational alerts or Slack integration actions could be delivered to that workspace.
Prerequisites include knowledge of the target organization ID, a valid short-lived Slack authorization code, and interaction from an authenticated member of the target organization.
danielcadev Reporter
Summary
Trigger.dev’s organization-level Slack OAuth flow uses the target Trigger.dev organization ID directly as the OAuth
statevalue. The callback does not verify that the authenticated browser session initiated the OAuth transaction.An attacker can authorize the Trigger.dev Slack application in an attacker-controlled Slack workspace, preserve the unredeemed callback URL, and convince an authenticated member of a target Trigger.dev organization to open it. Trigger.dev may then store the attacker-controlled Slack integration in the victim organization.
Safe reproduction design
I did not test Trigger.dev production or contact Slack.
A safe local regression test can:
Create a target organization and an authenticated victim member.
Ensure the victim session never initiated Slack OAuth.
Mock
oauth.v2.access()soATTACKER_CODEreturns credentials for a synthetic attacker-controlled workspace.Send the victim session to:
/integrations/slack/callback?code=ATTACKER_CODE&state=ORG_TARGETOn the vulnerable revision, verify that the exchange occurs and an integration for
ORG_TARGETis created with the attacker workspace.After remediation, verify rejection occurs before token exchange and that no integration or secret is created.
This report is based on a high-confidence static source trace. The local runtime harness was not executed because the available offline dependency cache lacked
@changesets/cli@2.26.2.Impact
The attacker may cause a victim Trigger.dev organization to connect an attacker-selected Slack workspace. Subsequent operational alerts or Slack integration actions could be delivered to that workspace.
Prerequisites include knowledge of the target organization ID, a valid short-lived Slack authorization code, and interaction from an authenticated member of the target organization.