Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
5.3
Vercel Workflow: Easily Guessable Tokens Leave Workflows Open to Attack
GHSA-9r75-g2cr-3h76
Summary
Vercel Workflow's webhook tokens can be easily guessed by attackers, allowing them to control workflows and trigger unwanted actions. To fix this, upgrade to version 4.2.0-beta.64 or change how you create webhooks to prevent predictable token use. If you can't upgrade, limit the use of easily guessable tokens or switch to a different method of resuming workflows.
What to do
- Update workflow to version 4.2.0-beta.64.
- Update workflow core to version 4.2.0-beta.64.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| – | workflow | <= 4.1.0-beta.63 | 4.2.0-beta.64 |
| workflow | core | <= 4.1.0-beta.63 | 4.2.0-beta.64 |
Original title
Vercel Workflow Allows Webhook Creation with Predictable User-Specified Tokens
Original 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.
#### 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.
ghsa CVSS3.1
5.3
Vulnerability type
CWE-287
Improper Authentication
Published: 6 Mar 2026 · Updated: 7 Mar 2026 · First seen: 6 Mar 2026