Trigger.dev EUVD-2026-106891

Target must be a self-hosted Trigger.dev webapp (before 4.5.4) running with the default, undocumented COORDINATOR_SECRET value 'coordinator-secret' - i.e. any operator who did not discover and override the source-only variable - with the /coordinator Socket.IO namespace network-reachable. For decrypted environment-variable exfiltration via READY_FOR_EXECUTION, the deployment must still be running V1 (marqs/ Run Engine) code and the attacker must know or discover an internal runId; V2/Run Engine 2.0 deployments return nothing for this read handler and expose only the write/tamper handlers (TASK_RUN_FAILED_TO_RUN, TASK_RUN_COMPLETED, CHECKPOINT_CREATED, etc.). Limiting factors: operators who explicitly set the override secret are not vulnerable, and V2-only (v4) deployments are not exposed to secret exfiltration. Trigger.dev Cloud is not implicated by the self-host default-config description.

This is a genuine high-priority issue for self-hosted Trigger.dev operators, not an inflated CVSS number. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VC:H) correctly captures a network-reachable, unauthenticated flaw with high confidentiality impact: the /coordinator Socket.IO namespace authenticates against a hardcoded 'coordinator-secret' that is published in the public source repo (CWE-798) and is undocumented in self-host docs, .env.example, and helm values, so default deployments ship exploitable. The AT:P (Attack Requirement: Present) metric reflects the one real gating condition - the attacker must know an internal runId to exfiltrate that run's decrypted environment variables via READY_FOR_EXECUTION. Signals are consistent rather than conflicting: there is NO CISA KEV listing, NO EPSS score, and NO public exploit provided in the input, so exploitation status is low-visibility, but the trivial connect-with-published-secret primitive plus clear source-code evidence make real-world abuse plausible once a runId is discovered. Note an important scope limiter the raw score hides: the env-var read handler lives in V1-only marqs/ code, so only self-hosts still on Run Engine V1 are exposed to secret exfiltration; v4/V2-only deployments only expose the write (tamper) handlers. EPSS/KEV absence here most likely reflects recency and the self-hosted/niche footprint rather than low exploitability.

An attacker who can reach a default-configured self-hosted Trigger.dev webapp connects to the /coordinator Socket.IO namespace and authenticates using the public 'coordinator-secret' string baked into the source code. They emit READY_FOR_EXECUTION referencing an internal runId to retrieve that run's decrypted production environment variables, or send TASK_RUN_FAILED_TO_RUN and similar events to tamper with arbitrary runs across tenants. No public exploit code was identified in the provided data, but the technique is fully documented in the GHSA advisory with exact source locations, and exploitation complexity is low (AV:N/AC:L).