Trigger.dev CLI's trigger dev --mcp server has no authentication: people on your network or a malicious web page can act on your project as you

Who is affected

You are exposed only when all of the following hold (vendor advisory and CVE record):

About the starting version: 3.0.0 is the CNA’s starting point. The vendor announced trigger dev --mcp with the v4 beta on April 9, 2025, and vendor posts suggest the flag only shipped then. Our analysis is that real exposure may start later than 3.0.0, but no vendor version statement confirms this.

How it works

MCP (Model Context Protocol) is a standard that lets AI coding assistants call external tools. When you run trigger dev --mcp, the CLI starts an MCP server on the developer’s computer so tools like Cursor and Claude Code can trigger tasks and check runs for you.

There are two layers to the problem:

1. The door opens onto the wrong place. Instead of binding only to localhost, the server listens on every network interface and exposes the /sse and /messages endpoints to the whole network. The vendor advisory gives 3333 as the default port.
2. The door has no lock. Neither endpoint checks any token. Yet the server calls Trigger.dev using the access token (a string that proves who you are) saved by trigger login.

So anyone who can reach it can use its tools as the developer. The vendor advisory lists the impact: queueing real task runs (not preview or sandbox), cancelling runs in progress, and listing recent runs with their payloads (often containing personal data or secrets). Depending on the project’s tasks, this may have downstream payment, external-API or customer-facing effects. The damage is bounded by the token’s scope, which for dev is typically the full project.

No source says the attacker can run arbitrary code on the developer’s computer; the described impact is misuse of the Trigger.dev API through the developer’s token. This maps to CWE-306 (missing authentication for critical function).

The flawed approach (conceptual illustration, not the original source code):

// Open on every network interface, with no token check
server.listen({ host: "0.0.0.0", port: 3333 });
onToolCall((call) => api.run(call, storedLoginToken));

A safer approach (conceptual illustration):

// No network port; the MCP client starts it and talks over standard input/output
runMcpOverStdio((call) => api.run(call, storedLoginToken));

The vendor’s release notes only say that 4.5.4 removes the --mcp and --mcp-port flags from the dev command, with the separate trigger mcp command used instead. PlainCVE’s judgement: the fix appears to be removing the listener rather than adding authentication to the old server; the release notes do not describe a security mechanism.

Timeline

The vendor’s GitHub advisory GHSA-pqmg-rq46-vm4m: that page contains attack code, so this site does not link to it.

Further reading

• Scoring: Only the CNA (VulnCheck) has scored it: CVSS 4.0 7.6 and CVSS 3.1 7.1, both “High”. The difference is that 3.1 rates attack complexity as high, while 4.0 expresses this as “attack requirements present”. Our data contains no NVD score.
• Disclosure date: The maintainer’s advisory (published 2026-07-21) and the CVE record’s public date (2026-07-21) agree. VulnCheck’s 2026-10-20 is only the date of its own advisory, not a public disclosure date.
• Exploitation: Not in CISA KEV as of 2026-10-22; CISA’s SSVC assessment of 2026-10-21 rates exploitation as none. Whether it was exploited before a fix existed is unknown. In the GitHub Advisory Database snapshot, EPSS (a predicted chance of exploitation in the next 30 days) is about 0.2%, at the 9.9th percentile.
• Other IDs: The GitHub Advisory Database also has entry GHSA-8v2q-27xw-2fjh, not yet reviewed by GitHub. OSV lists the introducing and fixing commits (798a47e8… and 16595578…).
• Related weakness type: CWE-306; design principle: local dev services should bind to localhost by default.