Trigger.dev: Server-side request forgery via unvalidated webhook alert-channel URL

What happened?

Summary A project member can create a webhook alert channel whose delivery URL points at an internal address, and trigger.dev's control plane will send the alert there with no SSRF protection. The webhook URL is stored as an unvalidated string and is fetched directly from the webapp server, so a low-privilege authenticated user can make the server issue POST requests to internal-only services and cloud metadata endpoints (for example http://169.254.169.254/). No private-IP, scheme, or redire

Key details

• A low-privilege organization member can create a webhook alert channel pointing to internal addresses, causing the control plane to send signed POST requests without SSRF protection.
• No private-IP, scheme, or redirect filtering exists anywhere in the webapp, and the URL schema only uses z.string() without .url() validation.
• Creating the alert channel only requires organization membership via findProjectByRef, with no admin role needed.
• The vulnerability allows a blind or semi-blind SSRF where the request reaches internal services and metadata endpoints, with status and latency observable through alert delivery logs.
• On cloud deployments, the SSRF can reach instance metadata endpoints and internal admin services, with requests appearing as legitimate trigger.dev callbacks.

Summarised by SecOraLens from GitHub Security Advisories. Always read the original source before acting. How SecOraLens verifies advisories.