Trigger.dev versions prior to 4.6.0 allow an attacker to bind a GitHub App installation to an organization that the attacker does not control. The flaw arises because the application does not verify that the authenticated user actually owns or is authorized for the GitHub App installation before binding it. Once bound, the attacker gains the permissions granted to that installation, enabling them to read, modify, or delete the victim’s repositories and related data. This represents a significant confidentiality and integrity breach but does not provide arbitrary code execution on the host system.

The vulnerability exists in all releases of trigger.dev earlier than 4.6.0. The vendor product is triggerdotdev:trigger.dev. No specific subcomponent version numbers beyond the major release are listed; the fix begins with release 4.6.0.

The CVSS score of 7.1 indicates a high severity flaw. The EPSS score is reported as less than 1%, suggesting that the likelihood of exploitation is low at present. The vulnerability is not listed in the CISA KEV catalog, and no public exploits have been confirmed. The likely attack vector is via the web application, requiring the attacker to replay a state cookie from a victim and supply a sequential installation identifier. This implies the attacker must obtain a valid state cookie, which could be achieved through social engineering or credential compromise. If successful, the attacker can take over the targeted GitHub App and access the victim’s repositories.