CVE-2026-114076 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 tenants to make the webapp server send POST requests to internal hosts by setting an unvalidated webhook alert channel URL. Attackers can point the webhook at internal services or cloud metadata addresses and trigger alerts to scan internal hosts, send state-changing POSTs, or reach IMDSv1 via redirects.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
Trigger.dev versions prior to 4.5.2 are susceptible to a blind server-side request forgery vulnerability that stems from insufficient validation of webhook alert channel URLs configured by authenticated tenants. This flaw allows an attacker who has obtained valid credentials for any tenant account within the application to manipulate the backend webapp server into initiating HTTP POST requests toward arbitrary destinations. The core technical deficiency lies in the lack of input sanitization and destination verification when processing user-supplied URL values designated as webhook endpoints, effectively turning a legitimate notification feature into a vector for internal network reconnaissance and exploitation.
The operational impact of this vulnerability is significant because it enables authenticated users to bypass perimeter security controls by leveraging the server's own outbound connectivity. Attackers can configure malicious webhook URLs that point toward internal services not exposed to the public internet or cloud metadata endpoints such as IMDSv1, which provides access to instance-specific data including credentials and configuration details. By exploiting redirect chains or direct POST requests, an adversary can perform port scanning of internal hosts, exfiltrate sensitive information from local APIs, or trigger state-changing actions on backend services that trust the server's identity but do not verify the originator of the request within the application context.
This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving unvalidated user input leading to unauthorized internal network access. In terms of adversarial tactics, this behavior corresponds to ATT&CK technique T1560.002 Archive Collected Data via Cloud Infrastructure Scripts or potentially T1497.003 Virtualization/Sandbox Evasion if used for environment fingerprinting, though the primary classification remains SSRF due to the mechanism of forcing the server to make requests on behalf of the attacker. The ability to reach IMDSv1 through redirects highlights a critical failure in implementing strict allowlists or blocking private IP ranges at the application layer before making outbound connections.
To mitigate this risk, organizations running Trigger.dev must upgrade immediately to version 4.5.2 or later where these validation checks have been implemented. In the interim, administrators should enforce network-level controls such as egress filtering on the webapp servers to block access to internal subnets and cloud metadata endpoints like 169.254.169.254. Additionally, implementing strict URL parsing that rejects private IP addresses, loopback interfaces, and non-HTTP schemes can provide a defensive layer against SSRF attempts until patching is complete. Security teams should also audit existing webhook configurations for any suspicious or externally hosted URLs that may have been injected by compromised tenant accounts prior to the upgrade.