Skip to content
RESEARCH INDEX BREACHROAD / INTELLIGENCE NOTE

Typebot 3.18.0: account takeover and server file read in a chatbot platform

CVE-2026-62862 and CVE-2026-62865 combine weak login codes with file exfiltration through Nodemailer. A technical review and Typebot 3.18.0 response plan.

PUBLIC RESEARCH
AUTHOR
/ CEO Breachroad · OSCP · PNPT
PUBLISHED
26 August 2026
READING TIME
18 min read
TOPIC
AI Security
Typebot 3.18.0: account takeover and server file read in a chatbot platform

The Typebot 3.18.0 update closes two serious flaw classes in the self-hosted chatbot builder. CVE-2026-62862 allowed an anonymous attacker to guess a six-digit magic-link code and take over a user’s account. CVE-2026-62865 allowed a bot author to turn a Send Email attachment into a read primitive for files available to the server process and deliver the content to a controlled mailbox. The CVE records entered public catalogues late on 25 August UTC, making them part of the 26 August news cycle in Central Europe.

This is not a vulnerability in a language model. Typebot supplies the conversation, integration and data orchestration layer around chatbots, while the flaws sit in authentication and server-side email handling. That is precisely why they matter to AI security: compromise of the control plane can expose conversation results, modify flows and use stored integration credentials without attacking the underlying model.

Two flaws and one dangerous chain of consequences

The first issue has a CVSS 4.0 score of 9.1 (Critical). It affects self-hosted releases through 3.17.1 when the default passwordless email login is enabled. The authentication provider replaced NextAuth’s secure token with a six-digit value generated by Math.random(). The resulting space contained 900,000 codes and each code remained valid for ten minutes.

A short value does not necessarily mean account takeover if a server limits attempts, consumes a token on use, binds verification to an initiated session and applies a limiter that cannot be bypassed. In this case, the verification callback had no guess limit or lockout, while a wrong attempt did not consume the legitimate token. The send path was rate-limited, but its key relied on the client-influenced X-Forwarded-For header. According to the advisory, multiple codes remained valid together, increasing the chance that a guess matched any live value.

The second issue has a CVSS 4.0 score of 8.7 (High). The Send Email block obtained an attachment value from a Typebot variable and passed it to Nodemailer as path. When the value did not start with the application’s own base URL, the helper neither rejected it nor required an HTTP or HTTPS scheme; it returned the path unchanged. The Nodemailer transport did not set disableFileAccess or disableUrlAccess, whose defaults permit access.

A bot author could therefore select a local path as the attachment and a controlled email address as the recipient. The viewer or chat-api process read the content with its own privileges and sent it by email. This does not automatically expose every host file: operating-system permissions and container isolation remain boundaries. A typical process can nevertheless see application configuration, mounted secrets or process environment data represented through the filesystem.

A login token is a credential. Its security depends on entropy and the complete protocol, not on whether the stored value is later hashed. Hashing protects a database representation from direct reading, but the server can still compare every correctly formatted code submitted over the network. A 900,000-element space becomes testable when no dependable online-attempt limit exists.

Math.random() is not a cryptographically secure pseudorandom number generator. More important in this issue, however, is the combination of a small space and an unrestricted callback. Even a perfectly uniform six-digit code would be weak if the system accepted unlimited attempts during its lifetime. Defence in depth should include a CSPRNG, adequate length, one live token, atomic consumption, account- and context-aware limits, and risk signals.

An IP-based limiter must also understand the proxy architecture. An application should not blindly trust the first header value supplied by a client. A trusted proxy can replace forwarding headers with a verified address, but that requires an explicit proxy trust list and correct framework configuration. Otherwise, the attacker selects the key intended to constrain their requests.

How an attachment became a server-side read channel

Mail libraries deliberately support file paths: a server may attach a generated report without first buffering the entire file. This is safe only when trusted code chooses the path. In Typebot, the value originated in a variable used while executing a flow, and a fallback treated any string as a location Nodemailer could access.

Checking whether a string begins with the application’s base URL is not an allowlist of protocols or directories. The question “is this not our URL?” does not answer “what is this value?”. A safe parser should recognise only approved types: an identifier for a previously uploaded file, a signed URL from controlled storage, or perhaps HTTPS to an approved domain. Respondent-controlled data should never become a local path.

The mail transport provides a second boundary. Even if an earlier helper makes a mistake, disableFileAccess: true and, where URL retrieval is unnecessary, disableUrlAccess: true reduce impact. Further barriers include a system account unable to read other services’ secrets, a read-only filesystem, minimal mounts and a separate mail worker.

Who is actually exposed

CVE-2026-62862 affects self-hosted Typebot before 3.18.0 with the email or magic-link provider enabled. Deployments that use OAuth or SSO exclusively and have no email provider are outside the mechanism described in the advisory. Do not assess configuration only from the button visible on the login screen; inspect effective environment variables and available callbacks.

CVE-2026-62865 affects the self-hosted builder and viewer before 3.18.0 where a Send Email block can run with a variable-controlled attachment. The advisory notes that open registration was the default and that SMTP configured for magic-link login provided a ready delivery channel. Disabling registration means the attacker needs an existing bot-author account, but the flaw still does not require an administrator.

The same release also fixed CVE-2026-62861. A member of one workspace could provide a domain belonging to another tenant and remove it from a shared Vercel project because authorisation of the supplied workspaceId was not bound to the domain object before the external operation. It is a separate BOLA/IDOR issue, but reinforces the need to review all tenant boundaries in integrations managing shared infrastructure.

Upgrade plan and temporary controls

The preferred action is to upgrade every Typebot component to 3.18.0 or a later supported release. Builder, viewer and chat-api should use the same verified image version. Recreate workloads after deployment and confirm the version inside the running container, not merely the tag in a Compose or Helm declaration.

If an immediate upgrade is impossible, disabling the email provider removes the CVE-2026-62862 path when reliable SSO or OAuth is available. Restricting registration, disabling the Send Email block or separating its worker can reduce exposure to the second issue. These are temporary barriers: a reverse proxy does not repair callback semantics unless it applies identity-aware limits and prevents forwarding-header spoofing.

After upgrading, invalidate active sessions, verification codes and API tokens as far as the platform supports. If a secret file or process environment may have been read, rotate the encryption secret, database credentials, SMTP credentials and integration keys according to a controlled procedure. Changing an encryption key requires a migration plan for stored credentials; do not discard old key material before confirming how existing records will be decrypted or re-encrypted.

Detection: what to look for retrospectively

For account takeover, review bursts of magic-link callbacks containing many different codes, numerous redirect responses, sudden changes in X-Forwarded-For, and repeated sends for one email address. Correlate proxy and application logs because only a trusted ingress layer can establish the source address. A session created after a long error series without the normal email-client navigation pattern deserves investigation.

For file read, identify Send Email executions whose attachment value was neither an approved URL nor an upload identifier. SMTP logs, bot-edit history and process file-access telemetry are useful. Alert on reads of configuration directories and process pseudo-files by a mail worker, as well as attachments sent to a newly observed recipient domain.

Absence of this telemetry is not evidence of safety. If an installation was public, allowed open signup and ran an affected release for a long time, perform a secret-exposure assessment. Monitor old credentials after rotation: attempted reuse is a valuable indicator and may reveal actual exploitation.

The lesson for AI and chatbot platforms

A chatbot system processes much more than a prompt. It includes an authoring panel, authentication, webhooks, email, storage, domains, model credentials and conversation data. Every integration expands the trust graph. AI security therefore has to include conventional application controls: strong sessions, object-level authorisation, tenant isolation, safe file handling and least-privilege processes.

Teams should model data flow from a public bot variable to every server-side sink. If a value reaches a path, URL, template, query or cloud resource name, it needs positive validation and a secondary restriction in the executing library. Security tests should exercise the lowest role, default settings and chains of otherwise separate features.

Source facts and Breachroad conclusions

Affected versions, the six-digit-code mechanism, callback behaviour, the attachment-to-Nodemailer flow, CVSS scores and the 3.18.0 fix come from Typebot’s advisories and CVE records. The sources do not report confirmed active exploitation. Rotation, log-correlation and defence-in-depth architecture recommendations are Breachroad conclusions.

AI security and secure application training helps teams recognise these data and identity boundaries, while web application and API penetration testing can assess chatbot configuration, tenant isolation and server-side integrations.

Sources

SHARE / COPY