Trigger.dev fixes default secrets and a cross-tenant SQL injection in a batch of advisories

Serguey Asael Shinder05 October 2026, 07:062 min read

Trigger.dev, an open-source platform for running background jobs and AI agent tasks, had a batch of security advisories published in the GitHub Advisory Database on 2 October. Several are rated critical or high. The most serious affect people who host the platform themselves.

Secrets that were never secret. One critical advisory describes a Socket.IO namespace, /coordinator, that mounted on every boot of the web app and authenticated callers with a default secret, the literal string coordinator-secret, defined in the public source. The variable that overrides it was not documented in the self-hosting docs, the example .env file or the Helm values, so operators who did not read the source shipped the default. On instances still running the older Run Engine 1.0, a message called READY_FOR_EXECUTION then returned a run's decrypted environment variables, which typically hold database URLs and API keys, for any run whose internal ID an attacker could find. Other handlers on the same namespace accepted writes against arbitrary runs. The fix in v4.5.4 removed the end-of-life V1 execution stack entirely. The managed cloud service was not affected because it used non-default secrets.

A second advisory concerns the Docker Compose setup: hosting/docker/.env.example contained fixed cryptographic secrets, including the one used to sign magic login links. Anyone who knew it could forge a link for any email address and, because accounts are created automatically when no email allowlist is set, log in. The advisory describes this as a chain to full infrastructure compromise, since the runner containers sat on the same networks as Postgres, Redis and ClickHouse with default passwords. It is fixed in v4.5.6.

Cross-tenant SQL injection. A high-severity advisory affects the hosted product as well as self-hosted ones. The query endpoint POST /api/v1/query compiles a customer's query language to ClickHouse SQL and adds a tenant filter. Every input was parameterised or escaped except the name of a window function, which was concatenated into the SQL. A backtick-quoted name could carry a whole subquery that sat outside the tenant filter, and the reporter showed it reading another organisation's rows on a live ClickHouse. It is also fixed in v4.5.6.

What it means

The pattern is old and keeps recurring: example configuration files become production configuration. Self-hosters of any platform should check whether secrets in their deployment still match the values in the project's public examples. Trigger.dev users who host it themselves should be on v4.5.6 or later and rotate every secret that came from an example file.