CVE-2026-72849

Budibase before 3.40.0 contains a cross-site request forgery vulnerability in the chat-link handoff endpoint that allows attackers to bind an external chat identity to a victim's account. Attackers can craft a phishing page that auto-submits a POST request with a leaked confirmation token to bind their chat identity to a victim user's account, enabling impersonation within agent operations and inheritance of victim permissions.

Budibase before 3.40.0 contains a cross-site request forgery vulnerability in the chat-link handoff endpoint that allows attackers to bind an external chat identity to a victim's account. Attackers can craft a phishing page that auto-submits a POST request with a leaked confirmation token to bind their chat identity to a victim user's account, enabling impersonation within agent operations and inheritance of victim permissions.

Budibase before 3.40.0 contains a cross-site request forgery vulnerability in the chat-link handoff endpoint that allows attackers to bind an external chat identity to a victim's account. Attackers can craft a phishing page that auto-submits a POST request with a leaked confirmation token to bind their chat identity to a victim user's account, enabling impersonation within agent operations and inheritance of victim permissions.

Summary

The Budibase AI chat-link handoff flow (GET/POST /api/chat-links/:instance/:token/handoff) binds an external chat identity (Slack/Discord/MS Teams/Telegram) to a Budibase user account. The confirmation endpoint is on a public route (no CSRF middleware, no auth-group gate) and the only credential it checks is a confirmationToken that is already rendered in plaintext into the HTML confirmation page the victim views. There is no binding between the confirmation token and the requester's Budibase session at preparation time, and no CSRF token on the POST.

Consequently, an attacker who creates a chat-link session for their own external chat identity (or any identity they can mint in their chat platform) can induce a victim Budibase user (same tenant) to submit the confirmation POST -> for example by sending them a link that auto-submits, or by XSS/CSRF on a co-tenanted page -> and the victim's globalUserId becomes bound to the attacker's external identity. The attacker then sends messages to the AI agent from their chat platform and is acting as the victim user inside Budibase automations/agent operations, inheriting the victim's permissions on agent operations, knowledge sources, and any downstream automation steps keyed off the linked identity.

Affected

| Component | Path | Lines | |---|---|---| | Public handoff routes (no auth-group middleware) | packages/server/src/api/routes/chat.ts | 23 (GET /api/chat-links/:instance/:token/handoff), 27 (POST .../handoff) | | Confirmation controller | packages/server/src/api/controllers/ai/chatIdentityLinks.ts | 124-177 (confirmChatLinkSession); the binding at 153-173 | | Confirmation token rendered into HTML | packages/server/src/api/controllers/ai/chatIdentityLinks.ts | 40-60 (renderLinkConfirmationPage); the hidden input at 55 | | Session creation (attacker side) | packages/server/src/sdk/workspace/ai/chatIdentityLinks.ts | 138-171 (createChatIdentityLinkSession), 173-188 (prepareChatIdentityLinkSessionConfirmation) | | Upsert of identity link | packages/server/src/sdk/workspace/ai/chatIdentityLinks.ts | 201-250 (upsertChatIdentityLink) |

Affected versions: master at commit 3c8d1b4023.

Reachable over HTTP by: the GET and POST are on publicRoutes (no auth-group middleware). The POST requires ctx.isAuthenticated at runtime (controllers/ai/chatIdentityLinks.ts:142) -> so the victim must be logged into Budibase when the POST fires (achievable via standard CSRF if cookies are sent cross-origin, or via phishing that lures the victim to submit).

Root cause

Issue 1 -> The handoff routes are public and unauthenticated at the middleware layer.

// packages/server/src/api/routes/chat.ts:23, 27
publicRoutes.get("/api/chat-links/:instance/:token/handoff", ai.handoffChatLinkSession)
publicRoutes.post("/api/chat-links/:instance/:token/handoff", ai.confirmChatLinkSession)

publicRoutes has no group middleware (endpointGroups/standard.ts:24-25 calls endpointGroupList.group() with no middleware and then .lockMiddleware()). The routes do not have a per-route authorized(...). There is no CSRF middleware on these routes -> Budibase's CSRF synchroniser token is enforced only for state-changing verbs on authenticated routes that are not in NO_CSRF_ENDPOINTS; the public-routes path bypasses it.

Issue 2 -> The confirmation token is exposed to anyone who views the GET page.

// packages/server/src/api/controllers/ai/chatIdentityLinks.ts:40-60
const renderLinkConfirmationPage = (session, action) => {
  ...
  return `<!doctype html>...
    <form method="post" action="${helpers.escapeHtml(action)}">
      <input type="hidden" name="confirmationToken" value="${helpers.escapeHtml(session.confirmationToken)}">
      <button type="submit">Confirm</button>
    </form>
  ...`
}

The confirmationToken (a newid() UUIDv4 generated by…

Budibase before 3.40.0 contains a cross-site request forgery vulnerability in the chat-link handoff endpoint that allows attackers to bind an external chat identity to a victim's account. Attackers can craft a phishing page that auto-submits a POST request with a leaked confirmation token to bind their chat identity to a victim user's account, enabling impersonation within agent operations and inheritance of victim permissions.

Budibase before 3.40.0 contains a cross-site request forgery vulnerability in the chat-link handoff endpoint that allows attackers to bind an external chat identity to a victim's account. Attackers can craft a phishing page that auto-submits a POST request with a leaked confirmation token to bind their chat identity to a victim user's account, enabling impersonation within agent operations and inheritance of victim permissions.

Summary

The Budibase AI chat-link handoff flow (GET/POST /api/chat-links/:instance/:token/handoff) binds an external chat identity (Slack/Discord/MS Teams/Telegram) to a Budibase user account. The confirmation endpoint is on a public route (no CSRF middleware, no auth-group gate) and the only credential it checks is a confirmationToken that is already rendered in plaintext into the HTML confirmation page the victim views. There is no binding between the confirmation token and the requester's Budibase session at preparation time, and no CSRF token on the POST.

Consequently, an attacker who creates a chat-link session for their own external chat identity (or any identity they can mint in their chat platform) can induce a victim Budibase user (same tenant) to submit the confirmation POST -> for example by sending them a link that auto-submits, or by XSS/CSRF on a co-tenanted page -> and the victim's globalUserId becomes bound to the attacker's external identity. The attacker then sends messages to the AI agent from their chat platform and is acting as the victim user inside Budibase automations/agent operations, inheriting the victim's permissions on agent operations, knowledge sources, and any downstream automation steps keyed off the linked identity.

Affected

| Component | Path | Lines | |---|---|---| | Public handoff routes (no auth-group middleware) | packages/server/src/api/routes/chat.ts | 23 (GET /api/chat-links/:instance/:token/handoff), 27 (POST .../handoff) | | Confirmation controller | packages/server/src/api/controllers/ai/chatIdentityLinks.ts | 124-177 (confirmChatLinkSession); the binding at 153-173 | | Confirmation token rendered into HTML | packages/server/src/api/controllers/ai/chatIdentityLinks.ts | 40-60 (renderLinkConfirmationPage); the hidden input at 55 | | Session creation (attacker side) | packages/server/src/sdk/workspace/ai/chatIdentityLinks.ts | 138-171 (createChatIdentityLinkSession), 173-188 (prepareChatIdentityLinkSessionConfirmation) | | Upsert of identity link | packages/server/src/sdk/workspace/ai/chatIdentityLinks.ts | 201-250 (upsertChatIdentityLink) |

Affected versions: master at commit 3c8d1b4023.

Reachable over HTTP by: the GET and POST are on publicRoutes (no auth-group middleware). The POST requires ctx.isAuthenticated at runtime (controllers/ai/chatIdentityLinks.ts:142) -> so the victim must be logged into Budibase when the POST fires (achievable via standard CSRF if cookies are sent cross-origin, or via phishing that lures the victim to submit).

Root cause

Issue 1 -> The handoff routes are public and unauthenticated at the middleware layer.

// packages/server/src/api/routes/chat.ts:23, 27
publicRoutes.get("/api/chat-links/:instance/:token/handoff", ai.handoffChatLinkSession)
publicRoutes.post("/api/chat-links/:instance/:token/handoff", ai.confirmChatLinkSession)

publicRoutes has no group middleware (endpointGroups/standard.ts:24-25 calls endpointGroupList.group() with no middleware and then .lockMiddleware()). The routes do not have a per-route authorized(...). There is no CSRF middleware on these routes -> Budibase's CSRF synchroniser token is enforced only for state-changing verbs on authenticated routes that are not in NO_CSRF_ENDPOINTS; the public-routes path bypasses it.

Issue 2 -> The confirmation token is exposed to anyone who views the GET page.

// packages/server/src/api/controllers/ai/chatIdentityLinks.ts:40-60
const renderLinkConfirmationPage = (session, action) => {
  ...
  return `<!doctype html>...
    <form method="post" action="${helpers.escapeHtml(action)}">
      <input type="hidden" name="confirmationToken" value="${helpers.escapeHtml(session.confirmationToken)}">
      <button type="submit">Confirm</button>
    </form>
  ...`
}

The confirmationToken (a newid() UUIDv4 generated by…