CVE-2026-114090 in cli
Summary
by MITRE • 10/21/2026
Trigger.dev cli-v3 from 3.0.0 before 4.5.4 contains a missing authentication vulnerability in the trigger dev --mcp server, which binds all network interfaces and exposes the /sse and /messages endpoints. LAN attackers or malicious web pages can send MCP tools/call requests to invoke trigger-task, cancel-run, list-runs, and get-run-logs using the developer's stored access token.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Trigger.dev CLI versions prior to 4.5.4 represents a critical security flaw stemming from improper authentication controls within its Model Context Protocol server implementation. Specifically, the --mcp flag activates an internal HTTP server that binds to all available network interfaces rather than restricting access to localhost or requiring explicit authorization tokens for incoming requests. This architectural decision effectively exposes sensitive management endpoints, namely /sse and /messages, to any entity capable of reaching the host machine over the local area network or through cross-site scripting attacks originating from malicious web pages. The absence of a mandatory authentication mechanism at this layer means that unauthenticated actors can interact directly with the Trigger.dev API surface without providing valid credentials, bypassing standard security boundaries designed to protect developer workflows and infrastructure state.
From an operational perspective, this misconfiguration allows LAN attackers or remote adversaries leveraging browser-based attacks to execute arbitrary operations within the victim's Trigger.dev environment. By sending crafted MCP tool calls, an attacker can invoke critical functions such as trigger-task to initiate new workflow executions, cancel-run to disrupt ongoing processes, list-runs to enumerate historical activity, and get-run-logs to extract sensitive data contained in execution logs. The exploitation of this vulnerability is particularly severe because it leverages the developer's stored access token implicitly through the context of the running CLI session or potentially via cookie-based authentication if applicable, allowing the attacker to act with the full privileges of that account without needing to steal the token directly from disk memory first. This capability enables a wide range of malicious outcomes including data exfiltration, service disruption, and potential lateral movement within connected cloud environments depending on the permissions associated with the compromised access token.
This vulnerability aligns closely with CWE-287, which describes Improper Authentication, as the system fails to verify the identity of users or services before granting access to protected resources. Furthermore, it maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter through the abuse of MCP tools to execute remote commands, and potentially T1537 Transfer Data to Cloud Account if sensitive data is exfiltrated via log retrieval functions. The exposure of internal development tooling over network interfaces without authentication creates a significant attack surface that contradicts security best practices for local-first developer tools which should assume the surrounding environment may be hostile or untrusted.
To mitigate this risk, users must immediately upgrade to Trigger.dev CLI version 4.5.4 or later where these endpoints are either removed from external exposure or secured with proper authentication checks. In environments where upgrading is not instantly feasible, administrators should restrict network access to the specific ports used by the MCP server using firewall rules that limit connectivity to trusted localhost addresses only. Additionally, developers should audit their stored access tokens for any signs of unauthorized usage and rotate them if compromise is suspected. It is also recommended to review CI/CD pipeline configurations and local development environments to ensure no unnecessary network exposure exists for internal tooling services until the patch is applied across all affected installations.