Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as project member
-
ExploitCreate alert channel with internal webhook URL
-
ExecutionTrigger alert to send server-side request
-
ImpactProbe internal/metadata reachability via signed POST
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated project member account (PR:L) with permission to create or configure alert channels in Trigger.dev before 4.5.2, and the ability to set an arbitrary, unvalidated webhook URL for that alert channel. Exploitation depends on internal, loopback, or cloud-metadata endpoints (e.g. 169.254.169.254) being network-reachable from the Trigger.dev server. Limiting factors: valid authentication as a trusted project member is mandatory (not unauthenticated), the SSRF is blind so the attacker cannot read response bodies - only infer reachability and send signed POST requests - and instances with egress filtering or no sensitive internal/metadata services reachable from the server substantially reduce practical impact. |
| Impact | This is a medium-severity blind SSRF (CVSS 4.0 base 5.3, CWE-918) with a well-defined but limited risk profile. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L) is internally consistent with the description: a network-reachable, low-complexity attack requiring low privileges (PR:L = an authenticated project member) and no user interaction, yielding only low confidentiality impact to both the vulnerable and a subsequent system (SC:L), with no integrity or availability impact. The signals align rather than conflict: because this is a 'blind' SSRF, the attacker cannot directly read responses, which caps impact at reachability probing and issuing signed POST requests - explaining the low confidentiality rating and the absence of integrity/availability impact. No EPSS score was provided in the input, and there is no CISA KEV listing and no indication of public exploit code, so exploitation status is 'no public exploit identified at time of analysis.' The requirement for an authenticated, trusted project member meaningfully lowers real-world urgency; this is an insider/post-authentication privilege-boundary issue rather than a remote-unauthenticated internet-facing flaw. A vendor patch exists. Overall this is a legitimate but not high-priority issue - a medium-CVSS finding whose real risk is gated by authentication and the blind nature of the SSRF; prioritize patching for multi-tenant or self-hosted deployments where internal/cloud-metadata endpoints are reachable, but it is not an emergency. |
| Exploit ScenarioDerived | An authenticated project member in a self-hosted Trigger.dev instance creates an alert channel whose webhook URL points at a loopback, internal, or cloud metadata address (e.g. 169.254.169.254), then triggers an alert so the server issues a signed POST to that target. By observing timing or alert behavior they map internal service reachability and reach otherwise-firewalled endpoints. No public exploit code is identified at time of analysis, and because the SSRF is blind the attacker infers results indirectly rather than reading responses directly. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Trigger.dev before 4.5.2 allows authenticated project members to set unvalidated alert-channel webhook URLs, enabling blind server-side request forgery against loopback, internal, or cloud metadata endpoints. An attacker with a project account can create such an alert channel and trigger alerts to probe internal service reachability and cause signed POST requests to be sent to attacker-chosen destinations, although response bodies are not returned to the attacker. This is a medium-severity issue (CVSS 4.0 base 5.3; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) with a limited risk profile; no public exploit identified at time of analysis.
RemediationAI
Upgrade to Trigger.dev 4.5.2, the vendor-released patch, and review the vendor advisory at https://github.com/triggerdotdev/trigger.dev/security/advisories/GHSA-2wgf-7gx2-hcpw for upgrade details. If immediate upgrade is not possible, restrict alert-channel creation and webhook URL configuration to trusted administrators, and enforce URL validation or allowlisting that blocks loopback, RFC1918, link-local 169.254.0.0/16, and cloud metadata destinations before any server-side request is made. Apply egress filtering from Trigger.dev workers so outbound requests cannot reach internal services or metadata endpoints; this may break legitimate webhook integrations and requires an allowlist of approved destinations. As a last resort, disable alert-channel webhook delivery until the patch is applied, noting that this removes alerting functionality. These compensating controls reduce exposure but do not fully replace the 4.5.2 fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
CVE-2026-114080 is a CWE-918 server-side request forgery flaw in Trigger.dev's alert-channel webhook configuration. The application accepts an arbitrary webhook URL without validating the destination and later makes server-side requests, including signed POST requests, when alerts fire. Because the SSRF is blind, an attacker cannot read response bodies directly and must infer internal reachability through timing, errors, or alert behavior. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N, reflecting a network-reachable issue that requires an authenticated project member who can create or configure alert channels; scope is changed because requests originate from the Trigger.dev server context. Practical exposure depends on whether loopback, RFC1918, link-local metadata such as 169.254.169.254, or other internal services are reachable from the Trigger.dev server and whether egress filtering is in place.
Know when Trigger Dev gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Authenticated project member sets the webhook (PR:L), network vector with low complexity; blind SSRF crosses into internal systems (S:C) giving low confidentiality only, with no integrity or availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
Trigger.dev before 4.5.2 contains a blind server-side request forgery vulnerability that allows authenticated project members to make the server send requests by setting unvalidated alert-channel webhook URLs. Attackers can create alert channels pointing to loopback, internal, or cloud metadata addresses, then trigger alerts to probe internal service reachability and send signed POST requests.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
Related Vulnerabilities in Trigger.dev Authorization and Injection Flaws
View all 29More in Trigger Dev
View allPrototype pollution in Trigger.dev's run metadata API (versions 3.3.8 through 4.5.5) lets any authenticated tenant corru
Cross-tenant authorization bypass in Trigger.dev before 4.5.6 lets a caller holding a valid API key for one project act
Missing authorization on the run replay API endpoint in Trigger.dev before 4.5.2 allows authenticated attackers to injec
EUVD-2026-106883
GHSA-7vxq-646g-jm2r
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB