CVE-2026-114087 in Trigger.dev
Summary
by MITRE • 10/21/2026
Trigger.dev before 4.5.6 self-hosted Docker Compose deployments using the default secrets from hosting/docker/.env.example allow authentication bypass because the hardcoded MAGIC_LINK_SECRET lets anyone forge valid magic link tokens. Unauthenticated attackers can log in as any email address, then reach Postgres, Redis, and ClickHouse with default credentials from runner containers on infrastructure networks, compromising all tenant data.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Trigger.dev versions prior to 4.5.6 represents a critical authentication bypass resulting from the improper handling of cryptographic secrets within self-hosted Docker Compose deployments. The core technical flaw lies in the use of hardcoded default values for the MAGIC_LINK_SECRET, which is stored in the hosting/docker/.env.example configuration file and often copied directly into production environments without modification. This secret serves as the signing key for generating magic link tokens used for passwordless authentication. Because this value remains static across all standard installations, it lacks the entropy required to prevent forgery. Attackers possessing knowledge of this default secret can algorithmically generate valid JWT-style or signed token structures that mimic legitimate login requests issued by the application server. This effectively neutralizes the integrity checks performed during the authentication process, allowing any individual with network access to impersonate arbitrary users without requiring a password reset email or external verification step.
The operational impact of this vulnerability is severe due to its direct correlation with lateral movement and data exfiltration capabilities within the deployment architecture. Once an attacker successfully forges a magic link token and authenticates as a target user, they gain full access to the application interface associated with that account. However, the risk extends far beyond the web application layer because of the default credential configuration found in the runner containers. These internal services typically connect to backend infrastructure components such as Postgres databases, Redis caches, and ClickHouse analytics engines using hardcoded or easily guessable credentials provided by the same deployment template. An authenticated attacker can leverage their session to interact with these downstream systems directly if network segmentation is insufficient, effectively bypassing application-level controls entirely. This allows for comprehensive compromise of all tenant data stored within the database clusters, including sensitive user information, workflow execution logs, and proprietary business logic configurations.
From a classification perspective, this vulnerability aligns closely with CWE-798: Use of Hard-coded Credentials, as it involves the use of static secrets that are known to attackers or easily discoverable through public documentation. Additionally, the exploitation path demonstrates elements of CWE-287: Improper Authentication, specifically regarding the failure to verify the integrity and origin of authentication tokens against a secure, unique key source. In terms of offensive security frameworks like MITRE ATT&CK, this scenario maps to T1078: Valid Accounts, where adversaries use legitimate credentials obtained through forgery rather than theft or brute force. The subsequent access to backend databases via default runner credentials further illustrates T1552.004: Unsecured Credentials, highlighting the danger of embedding sensitive connection strings and passwords directly within container configurations without encryption or external secret management integration.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The most urgent action is to upgrade Trigger.dev to version 4.5.6 or later, where this default behavior has been corrected to require unique, randomly generated secrets for each deployment instance. For environments that cannot immediately patch due to operational constraints, administrators should manually override the MAGIC_LINK_SECRET in their .env files with a cryptographically strong random string of sufficient length and complexity. Furthermore, it is imperative to audit all runner container configurations to ensure that database credentials are not hardcoded but instead managed through secure secret management solutions such as HashiCorp Vault or cloud-native key management services. Network segmentation should also be reviewed to restrict direct access from application containers to backend data stores, ensuring that even if an attacker gains a valid session, they cannot easily pivot to the underlying infrastructure using default administrative credentials.