External risk intelligence

Trigger.dev Authentication Bypass via Default Secrets in Self-Hosted Deployments

CVE advisorySeverity: CRITICAL (CVSS 9.2)

CVE-2026-114087

The vulnerability exists in a self-hosted web application platform that is designed to be internet-facing for workflow automation and API integration. While it requires a specific misconfiguration—the use of default secrets in a production deployment—such web platforms are commonly deployed as internet-reachable services, making the exposed surface likely in standard usage contexts.

Authentication Bypass

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security issue has been identified in Trigger.dev self-hosted deployments, affecting how authentication is handled. If default secrets are used, an attacker could bypass authentication and gain access to tenant data through default credentials in related services.

Authentication can be bypassed using default secrets.
Affects self-hosted deployments using default configurations.
Confirm relevance and assess exposure for affected systems.

Attack Path

How an attacker could exploit the issue

An attacker can bypass authentication in self-hosted Trigger.dev deployments by exploiting a hardcoded secret for magic link tokens. This allows them to log in as any user and then access sensitive data within the deployment's databases and network infrastructure due to default credentials in runner containers.

Requires default secrets in deployment.
Forges magic link tokens to log in.
Compromises tenant data from databases.

Live Threat

Current exploitation, exposure, and threat context

In self-hosted Docker Compose deployments, the use of default secrets can allow unauthenticated attackers to bypass authentication and gain access to sensitive tenant data. This is possible because a hardcoded secret enables the forging of valid magic link tokens, allowing attackers to log in as any user. Once authenticated, attackers can potentially access databases like Postgres, Redis, and ClickHouse using default credentials, leading to a compromise of all tenant data.

Tenant data and backend services are at risk.
Attackers forge magic links to gain access.
All tenant data could be compromised.

Operational Fix

Recommended remediation, mitigation, and detection steps

This critical vulnerability in self-hosted Trigger.dev deployments with default secrets enables unauthenticated attackers to bypass authentication and gain access to sensitive tenant data through connected databases. Owners of the Trigger.dev application and the underlying infrastructure teams are likely responsible for addressing this issue. The first practical step is to identify all Trigger.dev instances, confirm their reachability and business criticality, and then plan remediation based on these findings.

Identify Trigger.dev instances and assess risk.
Confirm reachable instances and accountable owners.
Plan remediation or temporary risk reduction.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Trigger.dev?

Trigger.dev is a web application platform used to build, run, and manage automated workflows and API integrations. It allows developers to create complex event-driven tasks. When self-hosted via Docker Compose, it manages various backend services like Postgres, Redis, and ClickHouse to support its automation engine and data storage.

What does CWE-653 mean for CVE-2026-114087?

CWE-653 refers to the use of hardcoded credentials. In this specific vulnerability, the application ships with a default MAGIC_LINK_SECRET. Because this secret is public knowledge in the default configuration files, an attacker can use it to forge valid authentication tokens, effectively bypassing the login mechanism entirely.

How does an attacker trigger this vulnerability?

An attacker triggers the flaw by using the default secret to generate a forged magic link token, which the system then accepts as valid. It is important to note that this exploit path only functions if the deployment is using the original, unchanged default secret provided in the sample environment files; deployments that have rotated to unique, custom secrets are not susceptible to this specific authentication bypass.

Is my self-hosted instance at risk?

Halo Surface Signal indicates that because Trigger.dev is designed to be an internet-facing platform for workflow and API automation, the attack surface is likely accessible. If your instance is reachable over the internet and retains the default secrets from the initial setup, it is at high risk of unauthorized access to your tenant data and backend infrastructure.

What is the first step to secure my deployment?

The most important immediate action is to locate all self-hosted Trigger.dev instances in your infrastructure. Once identified, confirm whether they are currently using the default configuration files. If they are, you must rotate the secrets to unique, cryptographically strong values and update your deployment environment to ensure the hardcoded values are no longer in use.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.