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

Trigger.dev: Trigger CLI debug deployment logs expose resolved environment secret valuesGHSA-fj2x-mqqp-3v2w

MEDIUMFix: triggerdotdev/trigger.dev#4420

GHSA-fj2x-mqqp-3v2w is a medium-severity (CVSS 5.5) vulnerability in trigger.dev. A fix is available for trigger.dev — see the affected versions and patch details below.

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 2, 2026 · OSV.dev, 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
961Kdownloads / week

Description

Affected version: trigger.dev 4.5.3 (4.5.6 was advertised by the CLI but was not tested).

A staging dry-run executed with trigger.dev deploy --env staging --dry-run --log-level debug. The debug output logged the complete build-worker options object. Its envVars property contained unredacted values for every resolved staging variable, including database connection strings and service credentials. The non-debug environment listing correctly hides values, so users can reasonably expect deployment logs not to print secrets.

Impact: anyone with access to a developer terminal transcript, CI debug log, captured agent/tool output, or support bundle can recover deployment secrets even though no deployment occurs.

Reproduction:

  1. Configure a Trigger.dev project with a secret environment variable.
  2. Run the command above with an authenticated profile.
  3. Inspect the Starting buildWorker debug record.
  4. options.envVars contains the plaintext value.

No real credential is included in this report. The observed customer credentials are being rotated separately.

Suggested remediation: never serialize envVars values in debug output; log names only or replace every value with a fixed marker. Add regression coverage for deploy, dry-run, and debug logging, and review adjacent debug records for resolved secrets.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmtrigger.devall versions4.5.9npm install trigger.dev@4.5.9

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.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fj2x-mqqp-3v2w is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

Affected version: trigger.dev 4.5.3 (4.5.6 was advertised by the CLI but was not tested). A staging dry-run executed with `trigger.dev deploy --env staging --dry-run --log-level debug`. The debug output logged the complete build-worker options object. Its `envVars` property contained unredacted values for every resolved staging variable, including database connection strings and service credentials. The non-debug environment listing correctly hides values, so users can reasonably expect deployment logs not to print secrets. Impact: anyone with access to a developer terminal transcript, CI de
O3 Security · Impact-Aware SCA

Is GHSA-fj2x-mqqp-3v2w in your dependencies?

Find it across npm, including transitive dependencies.

Trigger.dev: Trigger CLI debug deployment logs expose…