Trigger.dev EUVD-2026-106884

Requires an authenticated Trigger.dev customer account with a valid API key (PR:L) and the ability to submit a TSQL/TRQL query to the customer-facing endpoint POST /api/v1/query - a standard product feature, so no non-default configuration is needed. The specific technical prerequisite is placing a backtick-quoted identifier in the window-function name position, which the lexer accepts and visitIdentifier unescapes, bypassing the TSQL_CLICKHOUSE_FUNCTIONS/TSQL_AGGREGATIONS allowlist that gates the normal visitCall path. Limiting factors: exploitation is impossible without valid authentication, and the highest real-world impact occurs only in multi-tenant deployments where distinct untrusted organizations share the same ClickHouse backend; single-tenant/self-hosted-for-one-org installs have little cross-tenant data to steal. Affected: Trigger.dev <= 4.5.5; fixed in 4.5.6.

This is a credible, high-priority issue for organizations running Trigger.dev, though not a mass-exploitation emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/SC:H, score 8.3) indicates a network-reachable, low-complexity attack requiring only low privileges - i.e., any valid authenticated customer account. The PR:L requirement is the single most important mitigating factor: this is not anonymous internet-wide exploitation but an authenticated cross-tenant data-theft primitive, most relevant to multi-tenant/SaaS deployments where untrusted customers share a ClickHouse backend. Impact is confidentiality-only (VC:H, VI:N/VA:N) with a scope/subsequent-system change (SC:H) reflecting that one tenant reads another tenant's data. No EPSS score, no CISA KEV listing, and no published exploit code were provided, so there is no public evidence of active exploitation; however, the GHSA/VulnCheck advisory documents the exact vulnerable sink and states the attack was verified end-to-end against the real compiler and a live ClickHouse, meaning a working technique is effectively public even if packaged exploit code is not. Net: treat as a genuine priority for self-hosted multi-tenant operators (patch to 4.5.6), but EPSS/KEV absence suggests opportunistic mass scanning is not yet a demonstrated threat.

An attacker signs up for (or already holds) a legitimate low-privilege Trigger.dev customer account and sends a crafted TSQL query to POST /api/v1/query containing a backtick-quoted window-function name. Because the window-function name is concatenated into the generated ClickHouse SQL without allowlisting or escaping, the attacker smuggles a raw subquery that executes outside the per-tenant WHERE guard, returning another organization's analytics rows (e.g., task_runs data). No separate public exploit tool is required; the reporter (VulnCheck) verified the technique end-to-end against the live compiler.