CVE-2026-92773 in Trigger.dev
Summary
by MITRE • 09/16/2026
Trigger.dev before 4.6.0 fails to verify that an authenticated user controls a GitHub App installation before binding it to their organization. Attackers can claim another user's GitHub App installation by replaying state cookies and supplying sequential installation identifiers, gaining unauthorized access to the victim's repositories.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Trigger.dev versions prior to 4.6.0 represents a critical failure in authorization logic related to the integration of external services with organizational accounts. Specifically, the application fails to verify that an authenticated user possesses legitimate control over a GitHub App installation before binding it to their organization context. This flaw allows attackers to bypass standard access controls by exploiting how state cookies and sequential identifiers are handled during the OAuth or app installation flow. The core issue lies in the server-side validation process which trusts client-supplied data regarding ownership without performing adequate cross-referencing against identity provider records or permission scopes associated with the authenticated session.
From a technical perspective, this vulnerability enables an attacker to claim another user's GitHub App installation through a combination of state cookie replay and sequential identifier manipulation. By capturing valid authentication tokens or state parameters from legitimate sessions, attackers can reuse these credentials in subsequent requests. When combined with predictable or sequentially generated installation identifiers provided by the victim organization’s GitHub integration settings, the application incorrectly associates the external app instance with the attacker-controlled account rather than maintaining strict ownership boundaries. This misalignment results in unauthorized access to repositories that should remain restricted to the original owner of the GitHub App installation.
The operational impact of this flaw is severe as it directly compromises data confidentiality and integrity within connected repository environments. Attackers gain elevated privileges allowing them to read sensitive source code, modify project configurations, or potentially inject malicious changes into production pipelines if automated deployment processes are linked to these integrations. This scenario aligns with CWE-284 Improper Access Control where insufficient verification of user permissions leads to unauthorized resource access. Furthermore, the exploitation technique involving state parameter manipulation and session fixation elements corresponds to ATT&CK tactic T1078 Valid Accounts combined with techniques for privilege escalation within application contexts such as TA0005 Defense Evasion or TA0006 Credential Access depending on how initial authentication was obtained.
Mitigation strategies must focus on implementing robust server-side validation mechanisms that strictly enforce ownership verification before binding external integrations to organizational accounts. Developers should ensure that every request involving GitHub App installations includes comprehensive checks against the authenticated user’s actual permissions and installed apps within their personal or enterprise account hierarchy. Additionally, employing cryptographically signed state parameters with short expiration times prevents replay attacks while randomizing installation identifiers reduces predictability risks. Upgrading to version 4.6.0 or later resolves this issue by correcting the authorization logic to properly validate ownership relationships between users and external service installations ensuring that only authorized individuals can bind applications to their respective organizations.