Mar 6, 2026·5 min read·30 visits
The Vercel Workflow SDK allowed developers to set predictable tokens for public webhooks. Attackers can guess these tokens to manipulate running workflows without authentication. Fixed in version 4.2.0 by enforcing random token generation.
A high-severity vulnerability exists in the Vercel Workflow DevKit (`@workflow/core`) affecting the `createWebhook()` function. The vulnerability allows developers to manually specify predictable tokens for public webhook endpoints, leading to an Insecure Direct Object Reference (IDOR) flaw. Unauthenticated attackers can guess these tokens (e.g., `github_webhook:repo_name`) and send malicious POST requests to resume paused workflows, inject data, or trigger unauthorized state transitions. The vendor has patched this by removing the ability to specify custom tokens in favor of mandatory cryptographically secure identifiers.
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.
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.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L| Product | Affected Versions | Fixed Version |
|---|---|---|
@workflow/core Vercel | < 4.2.0-beta.64 | 4.2.0-beta.64 |
| Attribute | Detail |
|---|---|
| Attack Vector | Network (Public Internet) |
| CVSS | 7.5 (High) |
| CWE | CWE-639 (IDOR) |
| Impact | Workflow Manipulation / Data Injection |
| Affected Component | createWebhook() API |
| Remediation | Upgrade to @workflow/core@4.2.0+ |
Authorization Bypass Through User-Controlled Key
The Netty-based HTTP Client in the Micronaut framework fails to enforce a maximum redirect ceiling by default when processing HTTP responses. This permits remote, attacker-controlled servers to trigger continuous, infinite redirect loops. The resulting recursion causes high CPU utilization, thread starvation, and potential memory exhaustion, inducing a Denial of Service (DoS) state in client-side applications.
An information disclosure vulnerability exists in the Micronaut Framework's HTTP client components. The client fails to clear sensitive authorization headers and cookies when following redirects across different origins. If an application using the vulnerable client communicates with an endpoint that issues a redirect to an external host, the client will forward the original credentials, leading to potential token theft and session hijacking.
GHSA-52vm-mxx8-f227 is a dual-vector security flaw in phantom-audio (<= 1.3.0). The vulnerability allows arbitrary file writes due to unconfined Model Context Protocol (MCP) tool paths when the PHANTOM_OUTPUT_DIR environment variable is not defined. Concurrently, the platform lacks validation controls during the decompression of highly compressed audio files, resulting in resource-exhaustion denial of service and downstream parsing vulnerability exposure.
An authenticated path traversal and arbitrary local file read vulnerability exists in Craft CMS versions 4.x up to 4.17.6 within the assets/icon endpoint and Assets helper classes. By exploiting this vulnerability, an authenticated user can traverse directories and read arbitrary .svg files on the server's filesystem, or execute Stored Cross-Site Scripting (XSS) if they can upload a malicious SVG.
CVE-2026-56382 is a high-severity remote code execution vulnerability in Craft CMS versions 5.5.0 through 5.9.13. The vulnerability exists within the FieldsController::actionRenderCardPreview() method due to a lack of sanitization of the user-supplied fieldLayoutConfig configuration array, permitting authenticated administrators to register arbitrary PHP callbacks using Yii2 event handler injection mechanisms. This issue has been fully remediated in version 5.9.14.
An insecure direct object reference (IDOR) and missing authorization validation check in the Gittensory REST API and Model Context Protocol (MCP) server allowed authenticated users to query arbitrary miner profiles, exposing sensitive cryptographic hotkeys and daily financial/economic yields.