CVE-2026-92773: Trigger.dev Auth Bypass Vulnerability

CVE-2026-92773 Overview

CVE-2026-92773 is a broken access control vulnerability [CWE-639] in Trigger.dev versions prior to 4.6.0. The application fails to verify that an authenticated user actually controls a GitHub App installation before binding that installation to their organization. Attackers can replay state cookies and supply sequential installation identifiers to claim GitHub App installations belonging to other users. Successful exploitation grants unauthorized access to the victim organization's source code repositories through the linked GitHub App.

Critical Impact
Attackers can take over another user's GitHub App installation on Trigger.dev, gaining unauthorized read and write access to that user's connected GitHub repositories.

Affected Products

Trigger.dev versions prior to 4.6.0
apps/webapp/app/services/gitHub.server.ts in the Trigger.dev web application
Self-hosted and cloud deployments of Trigger.dev that expose GitHub App installation flows

Discovery Timeline

2026-09-16 - CVE-2026-92773 published to the National Vulnerability Database
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92773

Vulnerability Analysis

CVE-2026-92773 is an Insecure Direct Object Reference (IDOR) affecting the GitHub App installation callback in Trigger.dev. When a user installs the Trigger.dev GitHub App, GitHub redirects the browser back to the application with an installation_id parameter. The vulnerable code, located in apps/webapp/app/services/gitHub.server.ts, associates that installation identifier with the requesting organization without confirming that the authenticated Trigger.dev user is the same GitHub account that authorized the installation.

Because installation identifiers are integers issued sequentially by GitHub, an attacker can enumerate or guess valid values. Combined with a replayable state cookie, an attacker can bind any active installation, including installations created by other Trigger.dev customers, to their own organization.

Root Cause

The root cause is missing ownership validation on a user-controllable identifier. The callback handler trusts the installation_id query parameter and the state cookie, but does not call the GitHub API to confirm that the authenticated user has administrative rights over the referenced installation. This is the classic pattern described by CWE-639: Authorization Bypass Through User-Controlled Key.

Attack Vector

Exploitation requires the attacker to hold a low-privileged authenticated account on the target Trigger.dev instance. The attacker triggers the GitHub App connection flow to obtain a valid state cookie, then replays that cookie against the OAuth callback endpoint while substituting sequential installation_id values that correspond to victim installations. The server links the victim's GitHub App installation to the attacker's organization, exposing all repositories the installation is authorized to access. Full technical details are available in the GitHub Security Advisory GHSA-9rx3-j5hm-5f27 and the corresponding VulnCheck advisory.

No verified public exploit code is available. The vulnerable and patched logic can be reviewed in the GitHub App service source.

Detection Methods for CVE-2026-92773

Indicators of Compromise

Multiple GitHub App installation callback requests from the same authenticated Trigger.dev user containing different sequential installation_id values.
Repeated requests to the GitHub App callback endpoint reusing an identical state cookie value.
New GitHub App installations appearing on Trigger.dev organizations that do not correspond to any GitHub authorization initiated by that organization's members.
Unexpected GitHub audit log entries showing repository access from the Trigger.dev GitHub App originating from unfamiliar Trigger.dev workspaces.

Detection Strategies

Review Trigger.dev application logs for GitHub App callback requests where the authenticated user identity does not match the GitHub account that installed the App.
Correlate Trigger.dev organization-to-installation bindings with the GitHub App installation events in GitHub's audit log to identify mismatches.
Alert on enumeration behavior: a single session issuing sequential installation_id values against the callback route within a short time window.

Monitoring Recommendations

Ingest Trigger.dev web application access logs and GitHub organization audit logs into a central analytics platform to enable cross-source correlation.
Monitor for anomalous repository clone or read activity attributed to the Trigger.dev GitHub App outside normal working hours or from newly created Trigger.dev workspaces.
Track creation of new Trigger.dev organizations followed immediately by GitHub App installation binding attempts, which is the primary exploitation pattern.

How to Mitigate CVE-2026-92773

Immediate Actions Required

Upgrade all Trigger.dev deployments to version 4.6.0 or later without delay.
Audit existing GitHub App installations linked to Trigger.dev organizations and remove any bindings that cannot be attributed to a legitimate installer.
Rotate the Trigger.dev GitHub App credentials and revoke suspicious installation tokens through the GitHub App settings.
Review GitHub repository audit logs for unauthorized access performed via the Trigger.dev App during the exposure window.

Patch Information

The issue is fixed in Trigger.dev 4.6.0. The patched callback logic now validates that the authenticated user controls the GitHub App installation before persisting the binding. Refer to the fix in gitHub.server.ts lines 83-86 and the Trigger.dev repository for release notes.

Workarounds

If immediate upgrade is not possible, disable the GitHub App integration feature in Trigger.dev until version 4.6.0 can be deployed.
Restrict Trigger.dev account creation to trusted users through SSO or invite-only registration, reducing the pool of attackers able to authenticate to the callback endpoint.
Uninstall the Trigger.dev GitHub App from any GitHub organizations that do not currently require the integration to minimize the set of installations available for takeover.