Trigger.dev before 4.5.2 Server-Side Request Forgery via webhook alert-channel

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

Trigger.dev before 4.5.2 contains a server-side request forgery vulnerability in webhook alert channel delivery URLs that are fetched without validation or SSRF protection. Authenticated users with organization membership can create alert channels with URLs targeting internal services and metadata endpoints, allowing the server to issue POST requests to restricted resources.

Source published

4 Sep 2026 14:32:16 UTC

Source modified

4 Sep 2026 15:33:11 UTC

Saved here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

CVSS 3.1 · 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

Trigger.dev before 4.5.2 contains a server-side request forgery vulnerability in webhook alert channel delivery URLs that are fetched without validation or SSRF protection. Authenticated users with organization membership can create alert channels with URLs targeting internal services and metadata endpoints, allowing the server to issue POST requests to restricted resources.

Source published

Sep 4, 2026, 2:32:16 PM (timezone not stated)

Source modified

Sep 4, 2026, 3:33:11 PM (timezone not stated)

Saved here

11 Nov 2026 17:01:53 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

EUVD CVSS 4.0 · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Trigger.dev before 4.5.2 contains a server-side request forgery vulnerability in webhook alert channel delivery URLs that are fetched without validation or SSRF protection. Authenticated users with organization membership can create alert channels with URLs targeting internal services and metadata endpoints, allowing the server to issue POST requests to restricted resources.

Source published

4 Sep 2026 15:17:43 UTC

Source modified

23 Sep 2026 17:17:43 UTC

Saved here

25 Oct 2026 16:19:16 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · [email protected] · Secondary · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · [email protected] · Secondary · 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

### 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 redirect filtering exists anywhere in the webapp. ### Details The delivery sink performs a raw fetch to the stored URL, apps/webapp/app/v3/services/alerts/deliverAlert.server.ts:949 (#deliverWebhook): ```js const response = await fetch(webhook.url, { method: "POST", headers: { "content-type": "application/json", "x-trigger-signature-hmacsha256": signatureHex, }, body: rawPayload, signal: AbortSignal.timeout(5000), }); ``` The same pattern is in apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:245. The URL is never validated. The stored shape is a bare string, apps/webapp/app/models/projectAlert.server.ts:6: ```js url: z.string(), // not even .url() ``` The public API that creates alert channels accepts it with no constraint, apps/webapp/app/presenters/v3/ApiAlertChannelPresenter.server.ts:35: ```js url: z.string().optional(), ``` and stores it (line 139-142). The dashboard create route applies only `z.string().url()`, which still accepts http://169.254.169.254/... and http://127.0.0.1/.... A repository-wide search for any SSRF guard (private-IP/link-local/loopback/metadata blocklist, DNS-rebinding re-check, request-filtering agent) in apps/webapp returns nothing, so no protection exists at any layer. Creating the alert channel only requires organization membership (the API path resolves the project via findProjectByRef, which requires `organization.members.some.userId`); no admin role is needed. ### PoC As any member of an organization (using a personal access token or API key for a project they legitimately belong to): ```http POST /api/v1/projects/<projectRef>/alertChannels Authorization: Bearer <token> Content-Type: application/json { "name": "x", "alertTypes": ["task_run_failure"], "channel": "webhook", "channelData": { "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" } } ``` Then cause a task run failure in the attacker's own (legitimately owned) environment. DeliverAlert/DeliverErrorGroupAlert fires and the webapp issues a POST to the internal URL, with a valid HMAC signature computed from the channel secret. Live-validated: a local HTTP server was stood up on 127.0.0.1 to stand in for an internal/metadata endpoint, and the verbatim #deliverWebhook sink (HMAC-sign then raw fetch(webhook.url, POST, body) with no SSRF guard) was executed against it with webhook.url set to that internal address. Captured (what the internal server received): ``` [001 SSRF webhook alert] internal server received: {"url":"/latest/meta-data/","sigHeader":"a1d8dce41bda6c80df5a179cdc9f25320729b991ec3eb5f07df7ab9531149f65","body":"{\"alert\":\"task_run_failure\"}"} SSRF: CONFIRMED (control-plane POSTed signed payload to internal/metadata URL, no guard) ``` The control plane delivered the signed payload to the internal URL. That a low-privilege org member can create the alert channel (findProjectByRef requires only org membership) is verified at source. This is a blind/semi-blind SSRF: the response body is not returned to the attacker, but the request reaches the internal service (its POST body is delivered), and status, latency, and error differences are observable through the alert delivery logs/state. ### Impact A low-privilege authenticated organization member can use the trigger.dev control plane as an SSRF proxy into the internal network and the cloud metadata service. On cloud deployments this can reach the instance metadata endpoint (IMDS) and internal-only admin services. Because the request is server-originated and validly signed, it is indistinguishable from a legitimate trigger.dev callback to the receiving service. ### Remediation Validate the webhook URL on input (require https, reject hostnames that resolve to private, loopback, link-local, or metadata ranges) in ProjectAlertWebhookProperties and the API alert-channel schema, and enforce the same check at the fetch sinks in deliverAlert.server.ts and deliverErrorGroupAlert.server.ts, including re-checking after redirects (resolve the host and pin the connection, or use an SSRF-safe fetch agent).

Source published

2 Oct 2026 19:31:33 UTC

Source modified

2 Oct 2026 19:45:03 UTC

Saved here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Publisher rating · HIGH