Vercel Workflow Allows Webhook Creation with Predictable User-Specified Tokens

Description

createWebhook() in Vercel Workflow DevKit accepts a user-specified token parameter that serves as the credential for the public webhook endpoint /.well-known/workflow/v1/webhook/{token}. Official documentation recommended predictable token patterns, making it possible for an unauthenticated remote attacker to guess the token and inject arbitrary payloads into the workflow execution context.

Impact

An attacker who guesses a webhook token can resume the associated workflow with an attacker-controlled HTTP request body, potentially triggering downstream side effects such as API calls, database writes, or deployments.

Fix

  • Upgrade to version 4.2.0-beta.64. The fix removes the token option from createWebhook() so that webhook tokens are always randomly generated by the SDK.
  • Runs created with versions prior to 4.2.0-beta.64, that are 1) still active (i.e. running), and 2) have open hooks, are still susceptible to this vulnerability. If users suspect the hook tokens are predictable or leaked - consider cancelling those runs and restarting them on the latest patch.

Workarounds

In case a version upgrade is not possible, avoid passing predictable or guessable values to the token parameter of createWebhook(). Instead, users can either

  • switch from createWebhook() to createHook() instead and programmatically resume hooks using resumeHook() instead of the public webhook endpoint, or
  • use createWebhook() without passing a user-provided token, which uses a non-guessable random nanoid by default.

Basic information

Type
reviewed
Severity
medium
Advisory on GitHub
Open advisory ↗
Repository advisory
Open repository advisory ↗
Source code
Browse source ↗
Published (advisory)
2026-03-06 18:45:02 UTC
Updated
2026-03-06 18:45:02 UTC
GitHub reviewed
2026-03-06 18:45:02 UTC

CVSS Scores

Base score Version Severity Vector
5.3 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network—not just someone sitting at the machine.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:N)
No account or special rights needed—anonymous or random user is enough.
User interaction (UI:N)
Nobody has to click “OK” or open a trap file; it can work without a victim helping.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:N)
Doesn’t really leak secrets in a meaningful way.
Integrity (I:L)
Attackers could change some data, but it’s limited—not everything goes.
Availability (A:N)
Service keeps running; no real outage angle.

Identifiers

Type Value
GHSA GHSA-9r75-g2cr-3h76 ↗

CWEs

CWE id Name
CWE-287 Improper Authentication

Credits

  • pranaygp (reporter)
  • andresriancho (analyst)
  • TooTallNate (remediation_reviewer)

Affected packages (2)

Vulnerable version ranges and first patched releases as published by GitHub.

Ecosystem Package Vulnerable range First patched Vulnerable functions
npm workflow <= 4.1.0-beta.63 4.2.0-beta.64
npm @workflow/core <= 4.1.0-beta.63 4.2.0-beta.64

References

cvelogic Threat Intelligence