CVE-2026-47704 Overview
CVE-2026-47704 is an Insecure Direct Object Reference (IDOR) vulnerability in TypeBot, an open-source chatbot builder. Versions prior to 3.17.0 fail to correctly scope the result object during webhook resume operations. An authenticated user with read access to any typebot can resume a suspended webhook session belonging to a different typebot by combining an authorized typebotId and blockId with a foreign live resultId. This lets an attacker inject arbitrary webhook JSON into another typebot's suspended session and advance its execution without holding any access to the victim typebot. The issue is tracked as CWE-639: Authorization Bypass Through User-Controlled Key.
Critical Impact
Authenticated attackers can hijack in-progress webhook sessions belonging to other typebots and inject arbitrary JSON to manipulate execution flow, compromising the integrity of foreign chatbot workflows.
Affected Products
- TypeBot versions prior to 3.17.0
- TypeBot self-hosted and cloud deployments running affected versions
- Any TypeBot instance exposing multi-tenant workspaces with authenticated users
Discovery Timeline
- 2026-08-11 - CVE-2026-47704 published to NVD
- 2026-08-12 - Last updated in NVD database
Technical Details for CVE-2026-47704
Vulnerability Analysis
The vulnerability lives in the webhook resume handler in packages/blocks/webhook/src/api/handleExecuteWebhook.ts. TypeBot supports blocks that suspend execution while waiting for an external webhook callback. When that callback arrives, the handler resumes the paused session using three identifiers: typebotId, blockId, and resultId.
The handler authorizes the parent typebot correctly, verifying the caller can access the referenced typebotId. However, it then resolves the descendant result object using only the resultId, without confirming the result belongs to the authorized parent typebot. This scoping gap breaks the trust boundary between typebot tenants.
An attacker holding read access to any single typebot supplies their own valid typebotId and blockId alongside a resultId harvested from a victim's live session. The handler passes authorization, loads the victim's result, and advances the victim's suspended webhook session using attacker-supplied JSON payload data.
Root Cause
The root cause is a missing tenant-scoping predicate on the Prisma result lookup. The query keyed on resultId alone, treating the identifier as a capability token. Because resultId values are database records tied to specific typebots, the handler must join on typebotId to enforce ownership. The [CWE-639] pattern applies: authorization is enforced on the outer object but not on the inner user-controlled key.
Attack Vector
The attack requires network access to the TypeBot API and low-privilege authenticated credentials on any typebot within the deployment. No user interaction is needed on the victim side. The attacker obtains a live resultId from a monitored session, then submits a crafted resume request that mixes their authorized parent identifiers with the foreign resultId and arbitrary JSON. The victim typebot advances state under attacker control.
// Fix from packages/blocks/webhook/src/api/handleExecuteWebhook.ts
message: "Webhook block not found",
});
- const result = await prisma.result.findUnique({
+ const result = await prisma.result.findFirst({
where: {
id: resultId,
+ typebotId,
},
select: {
lastChatSessionId: true,
Source: GitHub commit 6f915c3. The patch replaces findUnique with findFirst and adds the typebotId predicate so the result must belong to the authorized parent typebot.
Detection Methods for CVE-2026-47704
Indicators of Compromise
- Webhook resume API requests where the submitted resultId does not correlate with prior activity by the requesting user or workspace.
- Unexpected state transitions or webhook advancement events on typebots whose owners took no corresponding action.
- Application logs showing handleExecuteWebhook invocations that resolve to a result owned by a different typebotId than the request specifies.
Detection Strategies
- Audit TypeBot application logs for webhook resume calls and cross-reference the typebotId, blockId, and resultId triplet against ownership records in the database.
- Enable request logging on API routes that invoke handleExecuteWebhook and alert when a single account resumes sessions across multiple parent typebots in a short window.
- Review Prisma query telemetry for result.findUnique calls on the webhook path prior to upgrading to 3.17.0.
Monitoring Recommendations
- Track authentication events and API request rates per user account for anomaly baselines against normal chatbot operator behavior.
- Alert on webhook resume payloads containing unusual JSON structures or unexpected field additions that could indicate injection attempts.
- Retain database audit logs long enough to reconstruct the ownership chain between Result and Typebot records during investigations.
How to Mitigate CVE-2026-47704
Immediate Actions Required
- Upgrade TypeBot to version 3.17.0 or later, which enforces typebotId scoping on the result lookup.
- Rotate any long-lived API tokens or session identifiers issued during the vulnerable window if abuse is suspected.
- Review the workspace membership model and remove read access for accounts that do not require it.
Patch Information
The fix is included in TypeBot v3.17.0 via pull request #2494. Full technical details are in GHSA-h67g-6q6g-58cj. The patch changes the Prisma query in handleExecuteWebhook.ts to require both id and typebotId to match before resolving a result record.
Workarounds
- Restrict authenticated access to the TypeBot instance to trusted operators only until the upgrade is applied.
- Place the TypeBot API behind a reverse proxy that enforces stricter request validation on webhook resume endpoints.
- Temporarily disable webhook blocks with waiting sessions if operational needs allow, to prevent the vulnerable code path from being reached.
# Upgrade self-hosted TypeBot to the patched release
git fetch --tags
git checkout v3.17.0
pnpm install
pnpm build
# Restart the TypeBot services
docker compose down && docker compose up -d
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

