Summary
Trigger.dev before 4.5.6 contains an SQL injection vulnerability in the /realtime/v1/runs endpoint because the tags query parameter is inserted into an ElectricSQL shape condition without adequate escaping. An authenticated attacker with any project API key holding read:runs scope may bypass the runtime environment tenant guard and access TaskRun records, including payloads and metadata, across organizations on the same self-hosted instance.
Trigger.dev before 4.5.6 contains an SQL injection vulnerability in the /realtime/v1/runs endpoint because the tags query parameter is inserted into an ElectricSQL shape condition without adequate escaping. An authenticated attacker with any project API key holding read:runs scope may bypass the runtime environment tenant guard and access TaskRun records, including payloads and metadata, across organizations on the same self-hosted instance.
Affected context
The issue occurs in self-hosted Trigger.dev deployments where the realtime runs endpoint processes the tags query parameter and builds an ElectricSQL shape WHERE clause. Risk is present when attacker-controlled query input reaches that clause without parameterization or equivalent safe query construction, and when tenant isolation depends on a runtime environment condition that can be logically altered.
The issue occurs in self-hosted Trigger.dev deployments where the realtime runs endpoint processes the tags query parameter and builds an ElectricSQL shape WHERE clause. Risk is present when attacker-controlled query input reaches that clause without parameterization or equivalent safe query construction, and when tenant isolation depends on a runtime environment condition that can be logically altered.
Exploit preconditions
- Attack surface: The
/realtime/v1/runsrealtime API endpoint - Required access: An authenticated project API key with the
read:runsscope - Trigger point: Processing the attacker-controlled
tagsquery parameter while constructing the ElectricSQL shape condition - Why exploitation is possible: Unescaped input is incorporated into a database predicate, allowing additional boolean conditions to alter filtering and undermine the runtime environment tenant guard
- Attack surface: The
/realtime/v1/runsrealtime API endpoint - Required access: An authenticated project API key with the
read:runsscope - Trigger point: Processing the attacker-controlled
tagsquery parameter while constructing the ElectricSQL shape condition - Why exploitation is possible: Unescaped input is incorporated into a database predicate, allowing additional boolean conditions to alter filtering and undermine the runtime environment tenant guard
Why this happens
The vulnerability results from constructing a database query condition by concatenating an untrusted request parameter into SQL-like predicate logic. Without parameterized queries, strict query builders, or equivalent escaping guarantees, attacker-controlled syntax can change the intended condition rather than remain a data value. This is CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
The vulnerability results from constructing a database query condition by concatenating an untrusted request parameter into SQL-like predicate logic. Without parameterized queries, strict query builders, or equivalent escaping guarantees, attacker-controlled syntax can change the intended condition rather than remain a data value. This is CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Potential impact
- Unauthorized access to TaskRun records belonging to other organizations
- Disclosure of task payloads, metadata, and potentially sensitive operational data
- Circumvention of intended tenant isolation on a shared self-hosted instance
- Increased exposure of downstream systems or secrets contained in run data
- Loss of confidence in project and organization data boundaries
- Unauthorized access to TaskRun records belonging to other organizations
- Disclosure of task payloads, metadata, and potentially sensitive operational data
- Circumvention of intended tenant isolation on a shared self-hosted instance
- Increased exposure of downstream systems or secrets contained in run data
- Loss of confidence in project and organization data boundaries
General mitigation guidance
Mitigation generally focuses on ensuring that all request-derived values remain data rather than query syntax.
Common defensive patterns include:
- Use parameterized queries or trusted query-builder APIs for all dynamic predicates
- Validate and constrain tag values against an explicit schema before query construction
- Avoid string concatenation when assembling SQL or SQL-like ElectricSQL conditions
- Enforce tenant filters independently of user-controlled query parameters
- Apply least-privilege database and API permissions to limit accessible records
- Treat API keys as narrowly scoped credentials and protect their distribution
- Add regression tests for tenant isolation and unexpected predicate manipulation
Mitigation generally focuses on ensuring that all request-derived values remain data rather than query syntax.
Common defensive patterns include:
- Use parameterized queries or trusted query-builder APIs for all dynamic predicates
- Validate and constrain tag values against an explicit schema before query construction
- Avoid string concatenation when assembling SQL or SQL-like ElectricSQL conditions
- Enforce tenant filters independently of user-controlled query parameters
- Apply least-privilege database and API permissions to limit accessible records
- Treat API keys as narrowly scoped credentials and protect their distribution
- Add regression tests for tenant isolation and unexpected predicate manipulation
How teams detect issues like this
Detection approaches may include:
- Static analysis rules that flag SQL or query-condition concatenation involving request parameters
- Code review checks for dynamic
WHEREclauses, shape definitions, and missing parameter binding - Runtime monitoring for unusual boolean expressions, malformed tag filters, or broad cross-tenant result patterns
- Authorization tests that verify a project credential cannot retrieve records outside its permitted organization
- Policy enforcement requiring approved parameterized query APIs and security regression tests in CI
- Neutral automated code review or software composition tools that identify injection-prone query construction
Detection approaches may include:
- Static analysis rules that flag SQL or query-condition concatenation involving request parameters
- Code review checks for dynamic
WHEREclauses, shape definitions, and missing parameter binding - Runtime monitoring for unusual boolean expressions, malformed tag filters, or broad cross-tenant result patterns
- Authorization tests that verify a project credential cannot retrieve records outside its permitted organization
- Policy enforcement requiring approved parameterized query APIs and security regression tests in CI
- Neutral automated code review or software composition tools that identify injection-prone query construction
