CVE-2026-73656 is a cross-tenant authorization bypass in Trigger.dev's deployment background worker attachment API. A valid API key for one project can attach an attacker-controlled background worker to any deployment in the system by supplying that deployment's friendlyId — no environmentId validation is performed.
The root cause isn't a forgotten predicate. It's a structural mismatch between what friendlyId was designed to do (provide human-readable, shareable identifiers) and what the authorization layer assumed about those identifiers. The developer who wrote workerDeployment.findFirst() likely treated friendlyId as an opaque but convenient reference and assumed API key scoping was sufficient authorization. This is a cognitive trap that emerges when security-critical checks are implicit rather than enforced as a structural requirement.
The versioning pattern — CreateDeploymentBackgroundWorkerService V4 — deserves scrutiny. Four iterations on the same code path without converging on an authorization model suggests this isn't accumulated technical debt; it's evidence that security invariants weren't formally tracked across refactors. Each V revision likely patched functional bugs while the authorization model remained implicit.
The critical question for your assessment: does Trigger.dev's service layer require tenant isolation checks, or does it assume callers are pre-authorized? If services treat authentication as the authorization boundary, then any direct service invocation — internal or external — becomes a potential vector. This determines whether CVE-2026-73656 is an isolated oversight or evidence of a systemic pattern.
On the CVSS 9.9: the attack requires a valid API key, which isn't trivial. The severity score treats friendlyId bypass as equivalent to unauthenticated access. The real question is whether API key issuance in your Trigger.dev deployment is scoped tightly enough that this represents realistic cross-tenant risk between unrelated organizations, or whether it's primarily a concern for multi-project environments under the same organizational control.
Immediate actions: audit your Trigger.dev deployment for other endpoints accepting friendlyId without explicit tenant scoping. Review internal service methods that accept identifier parameters and verify they enforce tenant isolation independently. Consider static analysis tooling that flags findFirst/findUnique calls missing tenant predicates. The friendlyId pattern means every endpoint taking a deployment identifier without explicit tenant validation is suspect — this CVE is likely the first instance found, not the only one.