Trigger.dev CVE-2026-114076

Requires a valid authenticated tenant account (or project PAT) with the ability to create or edit a WEBHOOK alert channel, since the vulnerable field is the user-supplied webhook url (validated only as z.string().optional() with no host allowlist or private-IP/metadata blocklist). The attacker must also be able to fire an alert - i.e. trigger a deployment failure, run failure, or error-group event (demonstrated via POST /api/v1/deployments/{id}/fail) - so an alert-eligible project/environment must exist. Exploitation is inherently BLIND and POST-only: the response body is not reflected, the request body is a fixed HMAC-signed alert payload, so it enables internal port/host scanning via a success/timing oracle, state-changing POSTs, and IMDSv1-via-redirect, but NOT arbitrary GET-based data exfiltration. Impact is meaningfully higher when the server runs in a cloud environment with IMDSv1 reachable and no egress filtering; deployments with network egress controls or private-IP blocking substantially limit it. Limiting factors: authentication required (PR:L), no availability impact, and blind POST-only semantics.

This is a genuine but moderate-severity issue, not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N, 5.3) is internally consistent with the description: network-reachable, low complexity, but requiring an authenticated tenant (PR:L), with limited confidentiality and integrity impact and no availability impact. The vendor's own CVSS 3.1 mapping (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, ~5.4 Medium) agrees. No EPSS score, no CISA KEV listing, and no indication of active exploitation were provided, so this should be treated as 'no public exploit identified at time of analysis' for weaponized/in-the-wild purposes - however, the GHSA advisory includes a detailed, researcher-proven runtime proof-of-concept (self-hosted), so the exploitation technique is publicly documented and reproducible. The main limiting factors keeping real-world risk at Medium rather than High are the authentication requirement (a valid tenant/PAT) and the blind, POST-only nature of the flaw: there is no arbitrary GET exfiltration, only a timing/success oracle plus state-changing POSTs and IMDSv1-via-redirect reach. The most serious signal is the explicit cloud-metadata (169.254.169.254) reach in multi-tenant SaaS deployments, where a low-privileged tenant could pivot toward internal infrastructure. Patch availability (4.5.2) is confirmed, which should drive prioritization: patch is straightforward and should be applied, especially for internet-facing multi-tenant or self-hosted deployments running in cloud environments with IMDSv1 enabled.

An authenticated tenant on a shared Trigger.dev instance creates a WEBHOOK alert channel whose URL points at an internal service or the cloud metadata endpoint (e.g. http://169.254.169.254), then deliberately fails a deployment or run (via the public API) to fire the alert. The webapp server (alertsWorker → DeliverAlertService) issues an HMAC-signed POST to that URL and follows redirects, letting the attacker port-scan internal hosts via timing, send state-changing POSTs, or reach IMDSv1 through a redirect. A working runtime PoC is documented in the GHSA advisory and was proven on a self-hosted instance.