GHSA-9r75-g2cr-3h76

`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.