Trigger.dev EUVD-2026-107025

Requires an authenticated project member with permission to configure alert-channel webhooks (PR:L), plus an internally routed target service addressed within the non-global 198.18.0.0/15 benchmarking range that isUnsafeIPv4 fails to treat as unsafe. Exploitation is limited to blind probing and state-changing POST requests (no response data is returned to the attacker), and applies only to Trigger.dev deployments before 4.5.10 that host reachable internal services in that range; it does not work for unauthenticated users or environments without internal services exposed on that CIDR.

This is a genuine but bounded issue, best treated as medium priority. The provided 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 PR:L (an authenticated project member), no user interaction, and only Low confidentiality and integrity impact with no availability impact. There is no EPSS score, no CISA KEV listing, and no indication of public exploit code in the supplied data, so exploitation status is 'no public exploit identified at time of analysis.' The Low confidentiality/integrity ratings are appropriate because the flaw yields only blind internal probing and limited state-changing POST requests, not full response exfiltration or RCE. The signals agree rather than conflict: this is a legitimate SSRF filter-bypass gated behind authentication with limited impact, making it a patch-in-normal-cycle item rather than an emergency. No conflicting signals were observed; the chief gap is the absence of EPSS and exploitation telemetry.

An authenticated project member creates an alert-channel webhook pointing at an internal service addressed in the 198.18.0.0/15 benchmarking range, which the isUnsafeIPv4 check fails to block. When the webhook fires, the Trigger.dev server issues the request to that internal host, letting the attacker blindly probe internal services and send limited state-changing POST requests from the server's trusted network position. No public proof-of-concept is identified in the available data.