Trigger.dev: Blind SSRF via alert-channel webhook
Trigger.dev contains a blind Server-Side Request Forgery (SSRF) vulnerability in its webhook alert channel implementation. Authenticated tenants can configure webhook URLs without validation, allowing the server to POST alert payloads to internal or metadata service IP addresses. This can lead to internal host scanning, state-changing POST requests to internal services, and potential access to IMDSv1 via redirects. The vulnerability affects versions prior to 4.5.2. A fix is available that includes validating webhook URLs against private, link-local, loopback, and metadata IP ranges and re-checking URLs at fetch time.
AI Analysis
Technical Summary
Trigger.dev's webhook alert channel stores user-supplied URLs without validating them against private IP ranges or metadata service addresses. When alerts trigger, the server fetches these URLs via POST with a signed payload, following redirects without egress restrictions. This allows an authenticated tenant to cause the server to send POST requests to internal infrastructure or the AWS metadata IP (169.254.169.254), enabling blind SSRF attacks. The vulnerability is confirmed on self-hosted instances and affects versions before 4.5.2. The CVSS 3.1 score is 5.4 (medium severity) with low attack complexity but requires tenant authentication.
Potential Impact
An authenticated tenant can exploit this vulnerability to perform blind SSRF by causing the server to send POST requests to internal IP addresses or metadata services. This can enable internal port and host scanning, trigger state-changing POST requests on internal services, and potentially access IMDSv1 via redirects. The vulnerability does not allow arbitrary GET request exfiltration and is limited to authenticated users. There are no known exploits in the wild.
Mitigation Recommendations
A patch is available for this vulnerability. The recommended remediation is to validate webhook URLs upon creation by enforcing HTTP(S) schemes and rejecting private, link-local, loopback, and metadata IP ranges. Additionally, the URL should be re-validated at fetch time, including after redirects, or redirects should be disabled/pinned to resolved public IPs. Implementing a shared assertion function (e.g., assertPublicUrl) for URL validation in both creation and delivery code paths is advised.
Trigger.dev: Blind SSRF via alert-channel webhook
Description
Trigger.dev contains a blind Server-Side Request Forgery (SSRF) vulnerability in its webhook alert channel implementation. Authenticated tenants can configure webhook URLs without validation, allowing the server to POST alert payloads to internal or metadata service IP addresses. This can lead to internal host scanning, state-changing POST requests to internal services, and potential access to IMDSv1 via redirects. The vulnerability affects versions prior to 4.5.2. A fix is available that includes validating webhook URLs against private, link-local, loopback, and metadata IP ranges and re-checking URLs at fetch time.
CVSS v3.1
Score 5.4medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Trigger.dev's webhook alert channel stores user-supplied URLs without validating them against private IP ranges or metadata service addresses. When alerts trigger, the server fetches these URLs via POST with a signed payload, following redirects without egress restrictions. This allows an authenticated tenant to cause the server to send POST requests to internal infrastructure or the AWS metadata IP (169.254.169.254), enabling blind SSRF attacks. The vulnerability is confirmed on self-hosted instances and affects versions before 4.5.2. The CVSS 3.1 score is 5.4 (medium severity) with low attack complexity but requires tenant authentication.
Potential Impact
An authenticated tenant can exploit this vulnerability to perform blind SSRF by causing the server to send POST requests to internal IP addresses or metadata services. This can enable internal port and host scanning, trigger state-changing POST requests on internal services, and potentially access IMDSv1 via redirects. The vulnerability does not allow arbitrary GET request exfiltration and is limited to authenticated users. There are no known exploits in the wild.
Mitigation Recommendations
A patch is available for this vulnerability. The recommended remediation is to validate webhook URLs upon creation by enforcing HTTP(S) schemes and rejecting private, link-local, loopback, and metadata IP ranges. Additionally, the URL should be re-validated at fetch time, including after redirects, or redirects should be disabled/pinned to resolved public IPs. Implementing a shared assertion function (e.g., assertPublicUrl) for URL validation in both creation and delivery code paths is advised.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-q567-cr4x-96w4
- Osv Schema Version
- 1.4.0
- Ecosystems
- ["npm"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6ac139b5a43b0b3b89d69d14
Added to database: 10/03/2026, 17:21:57 UTC
Last enriched: 10/03/2026, 17:41:26 UTC
Last updated: 10/04/2026, 02:51:09 UTC
Views: 8
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.