GHSA-pp95-gc86-jq6qHigh· 7.1▾ TwilightTrigger.dev: Missing Authentication in Run Replay Action Allows Cross-Organization Task Execution (IDOR)
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 39.1 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
The run replay action function at apps/webapp/app/routes/resources.taskruns.$runParam.replay.ts has no authentication or authorization check. While the loader (GET) in the same file properly calls requireUser(request) and scopes queries to the user's organizations, the action (POST) at line 166 does neither — allowing any authenticated user to replay task runs from any organization by knowing the run's friendlyId.
Vulnerable file: apps/webapp/app/routes/resources.taskruns.$runParam.replay.ts
The loader (line 28-29) — properly authenticated:
export async function loader({ request, params }: LoaderFunctionArgs) {
const user = await requireUser(request); // ✓ Auth check
const userId = user.id;
// ... queries scoped to user's orgs
}
The action (line 166-193) — NO authentication:
export const action: ActionFunction = async ({ request, params }) => {
const { runParam } = ParamSchema.parse(params);
// ✗ NO requireUser() call
// ✗ NO requireUserId() call
// ✗ NO org membership check
const taskRun = await prisma.taskRun.findFirst({
where: {
friendlyId: runParam, // Queries ANY run, no org scoping
},
include: {
runtimeEnvironment: { select: { slug: true } },
project: { include: { organization: true } },
},
});
// ... proceeds to replay the run in the victim's environment
const replayRunService = new ReplayTaskRunService();
The Prisma query at line 177 fetches the run by friendlyId only — no userId or organization filter. The ReplayTaskRunService then creates a new task run in the victim's environment, executing with the victim's environment variables and secrets.
Same bug class exists in: apps/webapp/app/routes/resources.batches.$batchId.check-completion.ts (line 17) — the action has zero authentication, allowing any user to trigger batch completion for any batch ID.
Run replay IDOR:
# Any authenticated user can replay any org's task run
POST /resources/taskruns/run_abc123def/replay
Cookie: <any-valid-session>
Content-Type: application/x-www-form-urlencoded
environmentId=<victim-env-id>&failedRedirect=/
The friendlyId values (e.g., run_abc123def) are short, incrementing strings that can be enumerated.
Batch completion (same bug class):
# Any authenticated user can trigger batch completion for any batch
POST /resources/batches/<batchId>/check-completion
Cookie: <any-valid-session>
Content-Type: application/x-www-form-urlencoded
redirectUrl=/
friendlyId values are short, predictable strings — enumeration is feasibletrigger.dev <= 4.5.1Upgrade to a patched release:
trigger.dev 4.5.2Connected by shared product, vendor, weakness, or advisory.
GHSA-q567-cr4x-96w4Medium· 5.4Trigger.dev: Blind SSRF via alert-channel webhook
GHSA-qxpp-qjg8-x4jvHigh· 7.1Trigger.dev: Run replay injects a task run into an attacker-chosen environment (cross-tenant write)
CVE-2026-85651High· 8.5Trigger.dev versions before 4.5.2 fail to validate environment membership during run replay operations, allowing authenticated attackers to inject task runs into arbitrary environments
GHSA-xxv7-2vv3-h682High· 7.7Trigger.dev: Server-side request forgery via unvalidated webhook alert-channel URL
GHSA-gg6r-gp4c-89hpCriticalTrigger.dev: V1 coordinator default-secret unauth Socket.IO
GHSA-59h8-w5q6-mfmpMedium· 5.3Trigger.dev: Unauthenticated Realtime Stream Data Injection via Run FriendlyId