GHSA-9r75-g2cr-3h76: Predictable Webhook Tokens in Vercel Workflow

The Vercel Workflow DevKit provides a framework for building durable, long-running workflows in TypeScript. A core feature of this library is the ability to pause a workflow and wait for an external event via a webhook. This is implemented using the createWebhook() function, which generates a unique URL that external services (like Stripe or GitHub) can call to resume execution.

Prior to version 4.2.0, createWebhook() accepted an optional token parameter. This allowed developers to manually define the identifier used in the webhook URL (e.g., https://api.app/.well-known/workflow/v1/webhook/{token}). Because developers often prioritize readability or determinism, they frequently used predictable identifiers derived from public data, such as Repository IDs, Tenant IDs, or Slack Channel IDs.

This design flaw creates a significant attack surface. By predicting these tokens, an unauthenticated attacker can construct valid webhook URLs and trigger workflow resumption. This effectively bypasses the implicit authentication of the 'secret' URL, allowing unauthorized actors to inject payloads into the workflow context.

The root cause is a design vulnerability classified as CWE-639: Authorization Bypass Through User-Controlled Key (specifically, an Insecure Direct Object Reference). The SDK relied on the secrecy of the webhook URL as the sole mechanism for authentication but simultaneously allowed users to make that URL predictable.

The vulnerability manifests in the WebhookOptions interface. By exposing the token property to the developer, the library delegated security responsibility to the user without enforcing entropy requirements. Common integration patterns encouraged the use of semantic identifiers (e.g., github_webhook:${repo.id}) rather than random strings. Since the URL format is standardized (/.well-known/workflow/v1/webhook/...), the token was the only variable component protecting the workflow endpoint.

Furthermore, the system did not implement secondary authentication (such as signature verification) by default on these endpoints, meaning knowledge of the URL was sufficient to successfully execute the webhook logic.

The vulnerability exists in the createWebhook function in @workflow/core. The patch resolves the issue by explicitly forbidding the token property in the options object and forcing the use of internal random generation.

Vulnerable Implementation (Conceptual):

// Pre-patch: Token is accepted and used directly
export function createWebhook(options) {
  // If user provides a token, use it; otherwise generate one
  const token = options.token || generateRandomId();
  return { 
    url: `https://.../webhook/${token}`,
    ...
  };
}

Patched Implementation: In the fixed version, the library actively validates the input options to ensure no token is provided. If a developer attempts to pass a token, the SDK throws a runtime error, preventing the application from starting or the webhook from being created with a weak identifier.

// packages/core/src/workflow/create-hook.ts
export function createWebhook(
  options?: WebhookOptions
): Webhook<Request> | Webhook<RequestWithResponse> {
  // Destructure token to check for its existence
  const { respondWith, token, ...rest } = (options ?? {}) as WebhookOptions & {
    token?: string;
  };
 
  // CRITICAL FIX: Explicitly reject user-defined tokens
  if (token !== undefined) {
    throw new Error(
      '`createWebhook()` does not accept a `token` option. Webhook tokens are always randomly generated. Use `createHook()` with `resumeHook()` for deterministic token patterns.'
    );
  }
  
  // ... subsequent logic uses internal secure ID generation
}

This change enforces a secure-by-default posture. By removing the token option from the public API surface, the library guarantees that all generated webhooks utilize high-entropy identifiers that are infeasible to guess.

An attacker can exploit this vulnerability by conducting reconnaissance on Vercel-hosted applications to identify workflow endpoints and then guessing the tokens based on the application's context.

1. Reconnaissance: The attacker scans for the standard Vercel Workflow path: /.well-known/workflow/v1/webhook/. A 404 or 405 response indicates the path exists but the specific token is missing, confirming the usage of the SDK.

2. Token Prediction: If the target application integrates with GitHub, an attacker might hypothesize the token format github_webhook:{repo_name}. For a repository named company/hiring-bot, the predicted token would be github_webhook:company:hiring-bot (or similar URL-safe variations).

3. Payload Injection: The attacker sends a POST request to the constructed URL:

curl -X POST https://target-app.vercel.app/.well-known/workflow/v1/webhook/github_webhook:company:hiring-bot \
  -H "Content-Type: application/json" \
  -d '{"action": "approve_candidate", "candidate_id": "attacker-id", "bypass_checks": true}'

4. Execution: If a workflow instance is currently awaiting this webhook, it consumes the JSON payload. The workflow proceeds using the attacker's data, effectively allowing unauthenticated remote execution of subsequent workflow steps.

The impact of this vulnerability is high, specifically affecting the Integrity of the application logic. While it does not directly expose the underlying server file system (Confidentiality), it allows for significant manipulation of business logic.

• Unauthorized State Transitions: Attackers can force workflows to advance prematurely or skip validation steps by supplying fabricated success signals.
• Data Injection: Malicious payloads injected via the webhook are treated as trusted input by the workflow. This can lead to database corruption, unauthorized API calls to third-party services (e.g., sending emails, processing payments), or logic flaws.
• Resource Exhaustion: An attacker could trigger a large number of 'zombie' workflow resumptions, potentially incurring costs on the serverless platform or hitting API rate limits.

CVSS v3.1 Estimate: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L (Score: 8.2 - High). The attack vector is Network, requires no privileges, and has High Integrity impact.