GHSA-FJ2X-MQQP-3V2W: Sensitive Information Disclosure in Trigger.dev CLI Build Logs

The Trigger.dev framework relies on background workers compiled at deployment runtime. The CLI utility manages compiling, bundling, and pushing these execution units to their respective orchestrators. Because background workers interface with numerous third-party systems, they require environment variables, database configuration profiles, and credentials. During compilation, the CLI v3 sub-package parses local files and remote configuration stores to establish compilation parameters.

A security advisory, identified as GHSA-FJ2X-MQQP-3V2W, details an information exposure vulnerability inside this build pipeline. The issue stems from verbose debugging logs produced by the build worker initialization routine. When developers execute deployment scripts with elevated debugging flags, the tool dumps configuration options directly to console output. This dumping behavior exposes highly sensitive variables and credentials.

The vulnerability resides in the @trigger.dev/cli package, specifically impacting CLI v3 packages located in packages/cli-v3. The primary attack surface exists anywhere console logs are recorded, including CI/CD output interfaces and logging platforms. Any actor or automated system with viewing permissions to these logs can capture plaintext secrets without additional authentication or authorization.

At the core of GHSA-FJ2X-MQQP-3V2W is a design pattern that directly serializes a broad configuration object without sanitization or selective parsing. The CLI’s compilation worker, initialized via the buildWorker function in packages/cli-v3/src/build/buildWorker.ts, consumes an object of type BuildWorkerOptions. This object serves as a comprehensive container for deployment targets, branches, path maps, and an envVars record storing key-value secret strings.

During development, logging statements were integrated at critical lifecycle points to assist with diagnostics and troubleshooting. A debug log entry was implemented using logger.debug("Starting buildWorker", { options }) to capture the worker's initial state. Because this logger accepts arbitrary objects and converts them to JSON, the entire configuration block, including the decrypted environment variables, was written to stdout.

This mechanism violates CWE-532: Insertion of Sensitive Information into Log File. The vulnerability becomes active whenever the log level is configured to capture debug statements, a common troubleshooting practice. The lack of an input-filtering or output-redaction layer allowed secrets to escape memory protections and enter persistent log streams.

The vulnerable implementation of buildWorker.ts highlights the risk of passing unvetted objects to logging interfaces. The original code path directly serialized the options parameter, writing it to the console. The following snippet illustrates this insecure logging pattern prior to remediation:

// Vulnerable implementation in packages/cli-v3/src/build/buildWorker.ts
export async function buildWorker(options: BuildWorkerOptions) {
  logger.debug("Starting buildWorker", {
    options, // Directly serializes the unredacted options block
  });
  
  const resolvedConfig = options.resolvedConfig;
  // ... remaining compilation logic continues
}

To address this, the maintainers separated logging concerns from the execution context. They created a dedicated file, packages/cli-v3/src/build/buildWorkerLogging.ts, and defined a strict schema for capturing parameters. The updated code maps and records only the counts of sensitive keys and safe configuration metadata.

// Patched implementation in packages/cli-v3/src/build/buildWorkerLogging.ts
import { logger } from "../utilities/logger.js";
 
type BuildWorkerLogOptions = {
  target: string;
  branch?: string;
  envVars?: Record<string, string>;
  rewritePaths?: boolean;
  forcedExternals?: string[];
  plain?: boolean;
};
 
export function logBuildWorkerStart(options: BuildWorkerLogOptions) {
  logger.debug("Starting buildWorker", {
    target: options.target,
    hasBranch: options.branch !== undefined,
    envVarCount: Object.keys(options.envVars ?? {}).length, // Captures only variable quantity
    rewritePaths: options.rewritePaths ?? false,
    forcedExternalsCount: options.forcedExternals?.length ?? 0,
    plain: options.plain ?? false,
  });
}

This architectural change introduces an explicit structural allowlist. The main execution path in buildWorker.ts now calls logBuildWorkerStart(options) instead of writing raw configurations. This ensures that new configuration parameters added to the build sequence will not inadvertently leak secrets.

Exploiting this vulnerability does not require complex payloads or network exploitation techniques. It is a passive exposure scenario that relies on access to output buffers or log file stores. In typical enterprise setups, deployment commands are automated within CI/CD pipelines such as GitHub Actions, GitLab CI, or Jenkins.

To troubleshoot packaging or integration issues, administrators often enable verbosity flags such as trigger.dev deploy --log-level debug. When this occurs, the runner processes the CLI command, serializes the secrets, and outputs them to the runner's execution console. Any user or system with read-only access to the pipeline history can retrieve the plaintext credentials.

The risk is exacerbated when logging outputs are synchronized to third-party log aggregators, security information and event management (SIEM) engines, or public storage buckets. Because the logs contain structured JSON, automated scrapers can easily identify patterns such as STRIPE_API_KEY, DATABASE_URL, or OPENAI_API_KEY. Once harvested, these credentials can be used to pivot into deeper production architectures.

The security impact of GHSA-FJ2X-MQQP-3V2W is classified as severe information leakage. Because the CLI is used to compile backend workflows, the leaked secrets often represent highly critical credentials. This includes administrative database connection parameters, live payment processor integration keys, and cloud infrastructure service tokens.

Compromise of these secrets can result in full data exfiltration, service disruption, and financial loss. The vulnerability has an indirect but substantial impact on systems trust and regulatory compliance. Organizations subject to standards such as PCI-DSS or GDPR face immediate compliance failures if cryptographic keys or personal credentials are discovered in plain logs.

The CVSS score is established as 7.5 (High) under the assumption that the log outputs are stored in accessible build history consoles. The exploit maturity remains low since active external vectors are not required to trigger the leak. Security teams should treat any verbose log output generated before the patch as a potential breach and rotate all involved tokens immediately.

To resolve this security issue, organizations must immediately upgrade the @trigger.dev/cli package to version v4.5.9 or later. This release completely deprecates the raw serialization of build worker parameters in favor of the sanitized logging structure. Running standard dependency updates in the project's root folder will resolve the exposure.

# Upgrade commands for different package managers
npm install @trigger.dev/cli@latest --save-dev
pnpm add @trigger.dev/cli@latest -D
yarn add @trigger.dev/cli@latest --dev

If immediate upgrading is not feasible, organizations should configure deployment agents to restrict log verbosity. Administrators must audit deployment configurations to verify that --log-level debug or verbose environments are disabled. Additionally, CI/CD platform features such as secret masking should be implemented to catch and redact sensitive strings.

Finally, security engineers must run retroactive log audits. Search historical log archives for the string "Starting buildWorker" and inspect the trailing JSON parameters. If plaintext database credentials or API tokens are discovered in the output history, those secrets must be rotated immediately.