The core issue with CVE-2026-73654 isn't a missing sanitization call—it's that Trigger.dev's permission model for 'normal environment API keys' includes the capability to manipulate arbitrary object paths in the first place. The JSONHeroPath library exists to make nested property assignment ergonomic: it parses strings like 'a.b.c' into recursive object mutations. That's useful functionality for legitimate metadata handling, but in a shared-tenant webapp process, granting API keys the power to define arbitrary paths is architecturally equivalent to granting them write access to Object.prototype. One tenant with a compromised normal key can pollute shared Prometheus metrics, corrupt Prisma query contexts, and degrade infrastructure for everyone on the same process.
The vulnerability exists because Trigger.dev never modeled the security distinction between modifying data values and manipulating object structure. 'Normal' API keys were implicitly allowed to pass arbitrary path segments to the metadata endpoint—not because someone made a conscious decision to grant structural access, but because nobody decided they shouldn't. This is an authorization model failure by omission, which is harder to detect and harder to remediate than a direct misconfiguration.
The 4.5.6 patch presumably sanitizes path segments or restricts what the metadata endpoint can touch. That's the correct immediate response. But it doesn't address the underlying condition: does your permission model distinguish between keys that modify data shape versus keys that only populate pre-defined schemas? Other endpoints may be operating under the same implicit assumptions, granting structural manipulation capabilities under 'normal' key permissions without any threat model to surface the risk.
The cross-tenant denial-of-service potential makes this more than a contained vulnerability. If your multi-tenant deployment shares a process model for operational simplicity, any tenant's key compromise becomes an infrastructure attack against all tenants. The architectural question isn't whether to patch this endpoint—it's whether the operational convenience of shared processes justifies the blast radius when every tenant API key has implicit structural write access to the shared runtime.