Summary
Trigger.dev batch-creation endpoints may accept a parentRunId belonging to another run or organization when called with an unrestricted environment API key. This authorization gap can allow an attacker to suspend, indefinitely block, or inject errors into runs they do not own.
Trigger.dev batch-creation endpoints may accept a parentRunId belonging to another run or organization when called with an unrestricted environment API key. This authorization gap can allow an attacker to suspend, indefinitely block, or inject errors into runs they do not own.
Affected context
The issue occurs in Trigger.dev batch-creation workflows that support resumeParentOnCompletion and trust a caller-supplied parentRunId. It becomes risky when an environment API key with broad operational permissions can reach the affected batch endpoints without an ownership or organization check binding the referenced run to the caller.
The issue occurs in Trigger.dev batch-creation workflows that support resumeParentOnCompletion and trust a caller-supplied parentRunId. It becomes risky when an environment API key with broad operational permissions can reach the affected batch endpoints without an ownership or organization check binding the referenced run to the caller.
Exploit preconditions
- Attack surface: Batch-creation HTTP endpoints, including
/api/v3/batchesand/api/v2/tasks/batch - Required access: An unrestricted environment API key or equivalent credential
- Trigger point: A batch request that supplies a foreign
parentRunIdwithresumeParentOnCompletion - Authorization gap: The service does not adequately verify that the referenced parent run belongs to the authenticated caller or organization
- Resulting condition: The attacker can influence lifecycle handling for runs outside their authorized scope
- Attack surface: Batch-creation HTTP endpoints, including
/api/v3/batchesand/api/v2/tasks/batch - Required access: An unrestricted environment API key or equivalent credential
- Trigger point: A batch request that supplies a foreign
parentRunIdwithresumeParentOnCompletion - Authorization gap: The service does not adequately verify that the referenced parent run belongs to the authenticated caller or organization
- Resulting condition: The attacker can influence lifecycle handling for runs outside their authorized scope
Why this happens
The underlying bug is a missing object-level authorization check. The application accepts a client-controlled identifier for a parent run and uses it to perform workflow operations without consistently confirming ownership, tenant membership, or permitted administrative scope. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where a user-supplied object reference is trusted without enforcing access control for the referenced resource.
The underlying bug is a missing object-level authorization check. The application accepts a client-controlled identifier for a parent run and uses it to perform workflow operations without consistently confirming ownership, tenant membership, or permitted administrative scope. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where a user-supplied object reference is trusted without enforcing access control for the referenced resource.
Potential impact
- An attacker could block or indefinitely suspend runs owned by other users or organizations.
- Production workflows could experience delays, failures, or reduced availability.
- Attackers may inject errors into unauthorized runs.
- Cross-organization workflow integrity could be compromised.
- Operational response and recovery efforts could be disrupted.
- An attacker could block or indefinitely suspend runs owned by other users or organizations.
- Production workflows could experience delays, failures, or reduced availability.
- Attackers may inject errors into unauthorized runs.
- Cross-organization workflow integrity could be compromised.
- Operational response and recovery efforts could be disrupted.
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization at every
operation that accepts a run identifier.
Defensive patterns include:
- Verify that the referenced parent run belongs to the authenticated principal, project, and organization before processing the request.
- Apply deny-by-default authorization to batch and workflow lifecycle operations.
- Avoid treating environment API keys as unrestricted authority; scope them by operation, project, and tenant where practical.
- Validate relationships between parent runs and newly created batches server-side rather than relying on caller-supplied context.
- Use short-lived, narrowly scoped credentials and rotate or revoke exposed keys.
- Add rate limits, idempotency controls, and workflow-state safeguards to reduce repeated disruption.
- Preserve least privilege for service identities and separate cross-organization administrative functions from routine execution APIs.
Mitigation generally focuses on enforcing object-level authorization at every
operation that accepts a run identifier.
Defensive patterns include:
- Verify that the referenced parent run belongs to the authenticated principal, project, and organization before processing the request.
- Apply deny-by-default authorization to batch and workflow lifecycle operations.
- Avoid treating environment API keys as unrestricted authority; scope them by operation, project, and tenant where practical.
- Validate relationships between parent runs and newly created batches server-side rather than relying on caller-supplied context.
- Use short-lived, narrowly scoped credentials and rotate or revoke exposed keys.
- Add rate limits, idempotency controls, and workflow-state safeguards to reduce repeated disruption.
- Preserve least privilege for service identities and separate cross-organization administrative functions from routine execution APIs.
How teams detect issues like this
Organizations can look for:
- Static analysis and code review checks for authorization decisions that use object IDs without ownership or tenant validation.
- Endpoint tests that attempt to access, modify, suspend, or resume resources belonging to another user, project, or organization.
- Policy rules requiring centralized authorization checks for batch creation and workflow lifecycle operations.
- Audit-log monitoring for parentRunId values that do not match the caller's project or organization.
- Alerts for unusual volumes of failed, suspended, or cross-tenant batch requests.
- Automated security testing and code review tools that identify missing object-level access checks.
Organizations can look for:
- Static analysis and code review checks for authorization decisions that use object IDs without ownership or tenant validation.
- Endpoint tests that attempt to access, modify, suspend, or resume resources belonging to another user, project, or organization.
- Policy rules requiring centralized authorization checks for batch creation and workflow lifecycle operations.
- Audit-log monitoring for parentRunId values that do not match the caller's project or organization.
- Alerts for unusual volumes of failed, suspended, or cross-tenant batch requests.
- Automated security testing and code review tools that identify missing object-level access checks.
