CVE-2026-114072 in trigger.dev
Summary
by MITRE • 10/22/2026
The Trigger.dev webapp before 4.5.12 contains a cross-site request forgery vulnerability in its organization-level Slack OAuth flow, which uses the organization ID as the OAuth state without binding it to the initiating session. Attackers who know a target organization ID can trick an authenticated member into opening an unredeemed /integrations/slack/callback URL, connecting an attacker-controlled Slack workspace that may receive the organization's operational alerts.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Trigger.dev versions prior to 4.5.12 represents a critical failure in session management and state validation within its OAuth integration workflow for Slack. This flaw is classified as Cross-Site Request Forgery, or more specifically, an insecure direct object reference combined with missing CSRF protection mechanisms during the authentication exchange process. The core technical issue lies in how the application handles the OAuth state parameter, which is designed to prevent attackers from forcing users to submit requests that they did not intend to make. In this specific implementation, the system utilizes the organization ID as the sole value for the OAuth state token without binding it to the user's active session identifier or generating a cryptographically random nonce. This design decision creates a predictable and static target for exploitation, allowing external actors to construct valid-looking authentication requests that bypass standard security checks intended to verify the legitimacy of the request origin.
From an operational perspective, this vulnerability allows an attacker who is aware of a specific organization ID within the Trigger.dev ecosystem to manipulate authenticated users into initiating unauthorized integrations. By crafting a malicious link pointing to the unredeemed Slack callback endpoint and including the known organization ID as the state parameter, an adversary can trick a logged-in administrator or member into clicking the URL while their session remains active in the browser. When this action occurs, the application processes the request as valid because it correctly matches the expected organization identifier stored internally for that OAuth flow. Consequently, the system proceeds to authorize and link a Slack workspace controlled by the attacker to the victim's organization without requiring additional confirmation or verifying that the user explicitly intended to perform this integration change through their current session context.
The impact of this vulnerability extends beyond simple unauthorized access, posing significant risks to operational integrity and data confidentiality. Once an attacker successfully links their own Slack workspace to the target organization, they gain the ability to receive all operational alerts, notifications, and event triggers that are configured to be sent via Slack for that specific environment. This effectively creates a backdoor into the monitoring and alerting infrastructure of the victim's operations. The attacker can monitor system health, detect security incidents in real-time, or potentially use this access as a stepping stone for further attacks by analyzing patterns in alerts to identify other vulnerabilities or sensitive data exposures within the organization's workflows.
This flaw aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF), specifically highlighting the failure to verify that state parameters are bound to user sessions rather than just static identifiers like resource IDs. Furthermore, it relates to CWE-614, concerning Sensitive Cookie in OAuth 2.0 Authorization Response, as the improper handling of session context during token exchange compromises the integrity of the authorization flow. In terms of MITRE ATT&CK mapping, this vulnerability facilitates techniques associated with Initial Access and potentially Persistence if the linked workspace is used to maintain ongoing access or exfiltrate information through alert channels. The lack of binding between the OAuth state and the user's session identity allows for automated exploitation without requiring complex social engineering beyond simple link sharing.
To mitigate this risk, immediate updates to version 4.5.12 or later are required as these versions address the underlying architectural flaw in the Slack integration logic. For organizations unable to upgrade immediately, implementing strict SameSite cookie attributes on session cookies can help prevent some forms of cross-site request forgery by ensuring that cookies are not sent with requests initiated from third-party sites. Additionally, developers should enforce the use of cryptographically random state tokens generated per-session rather than relying on static resource identifiers like organization IDs for OAuth validation. Implementing double-submit cookie patterns or custom anti-CSRF tokens in form submissions and API endpoints further strengthens defense-in-depth strategies against such attacks. Regular security audits focusing on authentication flows and third-party integrations are essential to identify similar misconfigurations across other services within the platform.