Trigger.dev Environment Variable Exposure: Track the Consumers After Rotating Keys

Rotating a model API key does not establish that every running job now uses the replacement. Responding to exposed environment variables requires tracking both the credential and the processes that consume it.

In its November 1, 2026 status notice, Trigger.dev said an attacker accessed environment variables belonging to a subset of organizations. It reported blocking the exploit and emailing affected account owners with mitigation steps. We have not verified an independent investigation.

Read the boundary of the disclosure

The notice we checked does not specify the number of affected organizations or the complete attack path. It supports neither a claim that all customers lost their keys nor a safety determination based solely on not receiving email. A provider’s resolved status does not establish the revocation state of credentials issued by other services.

Follow the individual official instructions first. The workflow below is our general operational guidance, not an attack reproduction or an account of Trigger.dev internals.

Inventory consumers without copying secrets

Record variable names, issuers, permissions, and consuming processes. Keep actual secret values out of tickets and chats.

This is not a list of credentials confirmed exposed in the incident. Investigate only the entries relevant to your organization. Updating an environment-variable field does not prove the old credential was revoked at its issuer.

The following educational example prints consumer metadata without reading secret values. Save it as inventory.mjs and run node inventory.mjs with Node.js 18 or later. We ran it locally; it does not contact Trigger.dev:

const inventory = [
  { name: 'MODEL_API_KEY', consumers: ['worker', 'retry-worker'] },
  { name: 'DATABASE_URL', consumers: ['worker'] },
];
for (const item of inventory) {
  console.log(item.name + ' -> ' + item.consumers.join(', '));
}

MODEL_API_KEY -> worker, retry-worker
DATABASE_URL -> worker

Build the real inventory from your deployment and job definitions. This code discovers nothing automatically and is not a secret scanner. Even variable names can expose internal structure, so keep the inventory in access-controlled incident records.

Rotation and recovery have different completion criteria

If notified, follow the official account-specific instructions to rotate and revoke potentially exposed credentials at their issuers, preserve and examine access records, and confirm which deployments and jobs received replacements. Creating a new key while leaving the old one valid does not close the old access path.

Recovery checks extend beyond successful authentication. Look for duplicated jobs across the transition, retry queues growing after authentication failures, and duplicated notifications or payments. These are general consequences to check when changing credentials in a workflow system, not confirmed effects of this incident.

An absence of suspicious log entries is meaningful only within the logs’ retention and coverage. Do not invent an exposure window and stop searching at that boundary; adjust the investigation as the provider supplies more information.

For each credential, retain evidence of old-key revocation, consumer transition, and job-result verification. Those records let a team distinguish provider remediation from its own recovery. See agent sandbox and permission boundaries for the related execution model.

The paid course below addresses harness constraints and verification around agent execution. It is not a Trigger.dev incident-response course or security certification program.