CVE-2026-85650 in Trigger.dev
Summary
by MITRE • 09/04/2026
Trigger.dev before 4.5.2 contains a server-side request forgery vulnerability in webhook alert channel delivery URLs that are fetched without validation or SSRF protection. Authenticated users with organization membership can create alert channels with URLs targeting internal services and metadata endpoints, allowing the server to issue POST requests to restricted resources.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The security flaw identified in Trigger.dev versions prior to 4.5.2 constitutes a critical Server-Side Request Forgery vulnerability within its webhook alert channel delivery mechanism. This weakness arises from an insufficient validation of user-supplied input when configuring alert channels, specifically regarding the destination URLs provided by authenticated users who possess organization membership privileges. The system fails to implement adequate safeguards or SSRF protection measures before fetching these URLs, thereby allowing malicious actors to manipulate the server into making HTTP requests on their behalf. This lack of restriction enables attackers to target internal services and cloud metadata endpoints that are typically inaccessible from external networks, effectively bypassing network-level security controls designed to isolate sensitive infrastructure components.
From a technical perspective, the vulnerability stems directly from CWE-918, which classifies Server-Side Request Forgery as a failure in server-side input validation where user-controllable data is used to construct URLs for internal requests without proper sanitization or allow-listing mechanisms. In this specific context, an authenticated attacker can create alert channels configured with maliciously crafted webhook URLs pointing towards private IP addresses, localhost endpoints, or cloud provider metadata services such as AWS EC2 Instance Metadata Service version 1. By leveraging the server's elevated privileges and network access to these internal resources, the attacker forces the application to issue POST requests to restricted areas of the infrastructure. This capability transforms a standard configuration feature into a potent attack vector for data exfiltration or further lateral movement within the compromised environment.
The operational impact of this vulnerability is severe, as it allows authenticated users with organization membership to potentially access sensitive internal APIs, retrieve confidential metadata containing cloud credentials, or interact with backend services that are not intended to be exposed publicly. If an attacker successfully exploits this flaw against a cloud metadata endpoint, they may obtain temporary security tokens and API keys associated with the underlying infrastructure, leading to full compromise of the affected account or organization's resources. Furthermore, by targeting internal microservices or databases via POST requests, attackers could trigger unintended actions, manipulate data integrity, or probe for additional vulnerabilities within the private network segment. This represents a significant breach of confidentiality and potentially availability depending on the nature of the targeted internal services.
To mitigate this risk, organizations running Trigger.dev versions earlier than 4.5.2 must upgrade to the latest patched release immediately where these validation checks have been implemented. In addition to upgrading, administrators should enforce strict network segmentation policies using firewalls or security groups to restrict outbound traffic from application servers to only necessary external domains and internal services required for business logic. Implementing egress filtering rules that block access to private IP ranges such as 10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x at the network perimeter can provide a critical layer of defense against SSRF attacks even if application-level controls are bypassed. Security teams should also monitor outbound connection logs for unusual patterns targeting internal endpoints or cloud metadata services to detect potential exploitation attempts in real-time.
This vulnerability aligns with MITRE ATT&CK technique T1598, specifically Phishing for Information within Cloud Environments when used against metadata services, and generally falls under the broader category of Server-Side Request Forgery which is often leveraged as a precursor step to achieve deeper access into restricted networks. The exploitation path described involves an authenticated user abusing their privileges to redirect server-side traffic, highlighting the importance of principle of least privilege in application design. Ensuring that webhook delivery mechanisms validate and sanitize all URL inputs against a strict allow-list of approved domains is essential for preventing similar incidents in future versions or other applications with comparable architectures.