Trigger.dev webhook alerts can be aimed at internal servers

Two GitHub security advisories published on 2 October 2026 describe a server-side request forgery flaw in Trigger.dev, the open-source background job and workflow platform. According to both advisories, a logged-in member of an organisation can create a webhook alert channel pointing at an internal address, and the Trigger.dev web application will send the alert there with no filtering. The advisories list the affected package as npm/trigger.dev and give the status as reported.

Server-side request forgery, or SSRF, is when an attacker persuades a server to make network requests on their behalf, reaching places the attacker cannot reach directly. In this case, the advisories say the webhook delivery URL is stored as a plain string and then passed straight to a fetch call in the alert delivery service, with the same pattern repeated in the error group alert delivery service. One advisory states that the public API field accepting the URL is declared simply as an optional string, with no syntax check at all, while the dashboard route applies only a generic URL check that still accepts addresses such as the cloud metadata address 169.254.169.254 or the loopback address 127.0.0.1.

Both advisories report that a repository-wide search for any SSRF protection in the web application returns nothing. The second advisory says searches for terms including "169.254", "isPrivate", "isLoopback" and "ssrf" return zero hits, and that no egress guard exists anywhere. It also notes that fetch follows redirects, which it says allows version one of the instance metadata service to be reached via a redirect.

The privilege required is low. According to the first advisory, creating an alert channel only requires organisation membership, because the API path resolves the project through a lookup that checks only whether the user is a member of the organisation. No administrator role is needed.

Both advisories include proof-of-concept work. The first says a local HTTP server was stood up on the loopback address to stand in for an internal endpoint, and the delivery code was run against it, confirming that the control plane posted a signed payload to the internal URL with no guard. The second says the issue was proven on a self-hosted install by seeding a project, a staging environment, a webhook channel pointing at an internal Docker host address, and a deployment, then failing the deployment through the public API. The internal listener received a POST from the web application process.

The advisories describe the flaw as blind or semi-blind: the response body is not returned to the attacker, and only a fixed, signed alert payload is sent. The second advisory scores it as medium, with a CVSS 3.1 vector of AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. It says the practical uses are internal port and host scanning using delivery success and timing as an oracle, state-changing POSTs to internal services, and reaching the metadata service via redirect, rather than arbitrary data exfiltration. The first advisory adds that because the request comes from the server and carries a valid HMAC signature, the receiving service cannot distinguish it from a legitimate Trigger.dev callback.

Both advisories recommend the same fix: validate the URL when the channel is created, requiring http or https and rejecting hostnames that resolve to private, loopback, link-local or metadata ranges, and re-check at the point the request is made, including after redirects. The second advisory suggests a shared assertion function used by the channel creation code and both delivery sinks.