CVE-2026-85650: Server-Side Request Forgery in Trigger.dev Webhook Alert Channel Delivery

The Trigger.dev control plane web application provides a developer-focused platform to orchestrate background jobs and long-running tasks. To notify administrators of runtime anomalies or task failures, the platform implements alert channels, including HTTP webhooks. When an alert condition is met, the backend system invokes an asynchronous worker to dispatch a notification payload to the configured endpoint.

The vulnerability identified as CVE-2026-85650 (GHSA-xxv7-2vv3-h682) is a Server-Side Request Forgery (SSRF) flaw in this notification delivery mechanism. Versions of the platform prior to 4.5.2 fail to validate or sanitize user-supplied URLs before invoking outbound HTTP requests. Any authenticated user with organization access can register an alert channel pointing to internal resources, exposing the internal environment to unauthorized interaction.

Because the system initiates connections from its own network context, an attacker can leverage the platform as an SSRF proxy. This permits reconnaissance of internal networks, interrogation of local loopback services, and unauthorized access to cloud Instance Metadata Services (IMDS).

The root cause of CVE-2026-85650 is a multi-layered validation failure within the application database schemas and HTTP client implementation. During alert channel registration, the system does not enforce strict syntactic or structural validation on the destination URL. The Zod schemas responsible for parsing user input only verify that the provided string matches a basic string pattern without imposing domain restrictions or address constraints.

At the database level, the ProjectAlert and associated tables store the unchecked string as a legitimate webhook target. The application relies on global Node.js fetch engines to perform the request execution inside background workers. These worker components execute the HTTP POST requests directly without performing pre-resolution domain checks, address family checks, or private IP filtering.

Additionally, the application lacks connection-bound socket validation, exposing it to DNS rebinding attacks. An attacker can configure a domain that resolves to a public IP during initial inspection but shifts to an internal loopback address during connection initiation. The absence of strict redirection policies further compounds the risk, allowing the client to follow server-instructed redirects to internal subnets.

In vulnerable versions of Trigger.dev, the database validation schema accepts arbitrary strings for the webhook URL. The model schema apps/webapp/app/models/projectAlert.server.ts uses the z.string() validator rather than enforcing network-safe constraints. This permits loopback and non-routable IP addresses to be successfully stored in the database.

The outbound delivery logic is managed by apps/webapp/app/v3/services/alerts/deliverAlert.server.ts. The worker fetches the URL string directly from the database record and invokes the global fetch API without an isolated agent.

// Vulnerable Implementation
const response = await fetch(webhook.url, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "x-trigger-signature-hmacsha256": signatureHex,
  },
  body: rawPayload,
  signal: AbortSignal.timeout(5000),
});

To remediate this, the patch introduced in commit 34b1a181c2a1d33a53ebab88f84b05f81fea4254 adds multiple protection layers. The custom safeWebhookFetch service replaces standard fetch, enforcing a socket-level DNS lookup check to reject private IP ranges prior to connection.

// Patched Implementation: Socket-level lookup validation
const safeLookup: LookupFunction = (hostname, options, callback) => {
  dnsPromises
    .lookup(hostname, {
      all: true,
      family: options.family,
      hints: options.hints,
      verbatim: options.verbatim,
    })
    .then((addresses) => {
      try {
        for (const { address, family } of addresses) {
          assertAddressAllowed(address, family);
        } 
      } catch (err) {
        callback(err as NodeJS.ErrnoException, []);
        return;
      }
      if (options.all) {
        callback(null, addresses);
      } else {
        callback(null, addresses[0].address, addresses[0].family);
      }
    })
    .catch((err) => callback(err as NodeJS.ErrnoException, []));
};

Exploitation of this vulnerability requires authenticated access to a Trigger.dev organization. An attacker with standard membership privileges can register a new alert channel pointing to a protected internal IP or a cloud metadata service endpoint. Because organization registration is open in self-hosted deployments and accessible via compromised tokens in cloud environments, the barrier to entry is minimal.

The attacker sends an HTTP POST request to the alert channels API endpoint, specifying the target internal host within the payload. The user then forces a background task run failure, prompting the backend task orchestrator to generate an alert event. The system identifies the webhook channel, generates a signature, and transmits the payload to the internal server.

Although the response payload is not fully returned to the attacker, the behavior is classified as semi-blind. The attacker can extract system state information by reviewing connection latency, HTTP status codes, and network error logs rendered in the web dashboard. This allows for rapid host discovery and service mapping across the hosting environment.

The primary consequence of this vulnerability is the exposure of internal-only network infrastructure to unauthorized authenticated actors. By proxying requests through the Trigger.dev backend, attackers can reach services running on the loopback interface (127.0.0.1) that are not exposed to the public internet. This includes local administration portals, database management ports, and internal microservice APIs.

In cloud-hosted deployments, the threat extends to the Instance Metadata Service (IMDS). An attacker targeting http://169.254.169.254/latest/meta-data/ can obtain cloud credentials, IAM roles, and configuration parameters assigned to the webapp container. This can lead to lateral movement and full cloud account compromise depending on the permissions granted to the application host.

The CVSS v3.1 base score is rated at 7.7 (High) reflecting the scope change (S:C) associated with traversing the security boundary from the public application web server to internal cloud infrastructure. The vulnerability is categorized under CWE-918 (Server-Side Request Forgery) and maps to MITRE ATT&CK techniques T1190 (Exploit Public-Facing Application) and T1005 (Data from Local System).

Remediation of CVE-2026-85650 requires upgrading self-hosted instances of Trigger.dev to version 4.5.2 or above. The official patch implements a comprehensive defensive framework that blocks private IP ranges and addresses DNS rebinding. This is achieved by binding IP validation directly to the connection lookup phase rather than relying on pre-resolve hooks.

// IP verification logic implemented in safeWebhookUrl.server.ts
function isUnsafeIPv4(host: string): boolean {
  const parts = host.split(".");
  if (parts.length !== 4) return false;
  const nums = parts.map((p) => Number(p));
  if (nums.some((n) => !Number.isInteger(n) || n < 0 || n > 255)) return false;
  const [a, b] = nums;
  if (a === 0) return true; // unspecified
  if (a === 127) return true; // loopback
  if (a === 10) return true; // RFC 1918 Private
  if (a === 172 && b >= 16 && b <= 31) return true; // RFC 1918 Private
  if (a === 192 && b === 168) return true; // RFC 1918 Private
  if (a === 169 && b === 254) return true; // link-local (IMDS)
  if (a === 100 && b >= 64 && b <= 127) return true; // carrier-grade NAT
  if (a >= 224 && a <= 239) return true; // multicast
  if (a >= 240) return true; // reserved
  return false;
}

For environments where immediate patching is not possible, network-level egress filtering must be enforced. Administrators should apply firewall rules or security groups restricting outbound traffic from the application web workers to internal subnets. Cloud environments must enforce IMDSv2 and restrict hop limits to mitigate the risk of metadata extraction.

Regular security audits should include querying the database for existing non-public webhook registrations. Organizations running self-hosted deployments can run automated scripts to inspect active webhook targets and confirm compliance with internal security policies.