CVE-2026-114080 in Trigger.dev
Summary
by MITRE • 10/21/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The identified vulnerability in Trigger.dev versions prior to 4.5.2 represents a critical blind server-side request forgery flaw that stems from insufficient validation of user-supplied input within the alert channel configuration mechanism. This security defect allows authenticated project members, who possess legitimate access privileges to manage workflows and alerts, to manipulate the application into making HTTP requests to arbitrary destinations. The core technical failure lies in the lack of rigorous sanitization or allow-listing for webhook URLs provided by users when creating new alert channels. By exploiting this oversight, an attacker can configure a malicious endpoint that forces the server-side infrastructure to initiate outbound network connections on their behalf. This capability effectively transforms authenticated user accounts into vectors for SSRF attacks, bypassing traditional perimeter defenses because the requests originate from trusted internal systems rather than external sources.
The operational impact of this vulnerability is significant due to its potential for reconnaissance and lateral movement within cloud environments. Attackers can leverage the forged requests to probe internal service reachability by targeting loopback addresses such as 127.0.0.1 or localhost, which often host administrative interfaces or debugging tools that are not exposed to the public internet but remain accessible from within the application server's network namespace. Furthermore, the vulnerability enables access to cloud metadata services, typically found at static IP addresses like 169.254.169.254 for AWS or similar endpoints in other cloud providers. Accessing these metadata endpoints can lead to the exfiltration of sensitive instance credentials, temporary security tokens, and configuration details that compromise the integrity of the entire infrastructure. The ability to send signed POST requests further amplifies the risk, as it allows attackers to interact with internal APIs using valid authentication signatures obtained through metadata theft or other means, potentially leading to unauthorized data manipulation or service disruption.
From a classification perspective, this vulnerability aligns closely with CWE-918, which defines Server-Side Request Forgery (SSRF), specifically involving the lack of validation for user-controlled URLs that dictate outbound network behavior. It also maps to MITRE ATT&CK technique T1557, Adversary-in-the-Middle, as the attacker uses the compromised server as a proxy to interact with internal resources undetected by external security monitoring tools. The blind nature of this SSRF variant means that direct response data is not returned to the user interface, requiring attackers to rely on out-of-band techniques or side-channel effects such as DNS lookups or HTTP request timing differences to confirm successful exploitation and extract information.
To mitigate this vulnerability, organizations must immediately upgrade Trigger.dev to version 4.5.2 or later where these input validation controls have been implemented. In the interim, defensive measures should include implementing strict allow-listing for webhook URLs that restricts destinations to known, trusted domains rather than accepting arbitrary hostnames and IP addresses. Network-level mitigations such as egress filtering can also be employed to block outbound connections from application servers to internal metadata endpoints and private network ranges unless explicitly required by business logic. Additionally, enforcing principle of least privilege ensures that only essential service accounts have the ability to configure external integrations, reducing the attack surface for authenticated users who might otherwise exploit this flaw. Regular security audits focusing on input validation in webhook configurations are recommended to prevent similar SSRF vectors from being introduced into other parts of the application ecosystem.