CVE-2026-114065 in Trigger.dev
Summary
by MITRE • 10/22/2026
Trigger.dev before 4.7.3 contains a tenant filtering bypass vulnerability that allows authenticated users to read other tenants' data by using placeholder table syntax in POST /api/v1/query. Attackers can submit queries with FROM {database.table} expressions, including within subqueries, to skip table allowlist and tenant filters and expose run metadata and payloads.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Trigger.dev versions prior to 4.7.3 represents a critical failure in multi-tenant data isolation mechanisms, specifically classified under CWE-285 Improper Authorization. This flaw stems from the application's handling of dynamic table references within its query execution engine. The system is designed to enforce strict tenant boundaries by filtering database queries based on an allowlist and specific tenant identifiers to ensure that authenticated users can only access data belonging to their own organization or context. However, the implementation fails to adequately sanitize or validate placeholder syntax used in SQL-like expressions, particularly when these placeholders are embedded within complex query structures such as subqueries.
The technical root cause lies in how the application parses and executes queries submitted via the POST /api/v1/query endpoint. When a user submits a request containing table references formatted with curly braces, such as FROM {database.table}, the system's parser incorrectly interprets this syntax. Instead of treating it as a literal string or rejecting it due to invalid formatting, the engine attempts to resolve these placeholders dynamically. Crucially, during this resolution process, the security controls that enforce tenant-specific filtering are bypassed. The allowlist mechanism, which is intended to restrict access to predefined tables, does not account for queries where table names are constructed using variable substitution or placeholder syntax within nested query blocks. This oversight allows an attacker to construct a malicious payload that instructs the database engine to retrieve data from arbitrary tables without triggering the tenant isolation checks.
The operational impact of this vulnerability is severe, as it leads directly to unauthorized information disclosure across tenants. An authenticated attacker can exploit this flaw to read sensitive run metadata and execution payloads belonging to other organizations sharing the same Trigger.dev instance. This exposure compromises the confidentiality guarantees essential for a multi-tenant SaaS platform. The leaked data may include internal logs, configuration details, or proprietary business logic embedded within trigger executions, potentially leading to further attacks such as credential theft or system compromise if sensitive secrets are exposed in these payloads.
This vulnerability aligns with MITRE ATT&CK technique T1530 Data from Cloud Storage Object Misconfiguration and more broadly falls under the category of Broken Access Control (T1288). The exploitation requires authentication, meaning it is not a remote unauthenticated attack vector, but it significantly lowers the barrier for insider threats or compromised accounts to escalate their privileges beyond intended limits. To mitigate this risk, organizations must upgrade Trigger.dev to version 4.7.3 or later where these parsing logic flaws have been addressed. Additionally, developers should implement strict input validation that rejects any dynamic table references not explicitly whitelisted in a static configuration rather than relying on runtime placeholder resolution for security-critical boundaries. Enforcing parameterized queries and avoiding the direct interpolation of user-supplied values into SQL-like structures is also essential to prevent similar bypasses in other components of the application stack.