GHSA-j32h-2r6x-wmf3
Fix: baptisteArno/typebot.io@9c81300GHSA-j32h-2r6x-wmf3 is a CWE-73 vulnerability. O3 Security confirms whether GHSA-j32h-2r6x-wmf3 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
TypeBot: Arbitrary server file read via Send Email block attachment path
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-j32h-2r6x-wmf3.
Description
Typebot is an open-source chatbot builder. In self-hosted versions prior to 3.18.0, the server-side Send Email integration block allows arbitrary reading of local files on the server. The block builds Nodemailer attachments from a typebot variable, and its parseAttachments helper returns the supplied value as a filesystem path whenever it does not start with the application's own base URL, instead of requiring an http or https URL. The Nodemailer transport is created without disableFileAccess or disableUrlAccess, both of which default to false, so an attachment specified as an absolute server path is read from the local filesystem and delivered. Because both the attachment value and the recipient list are attacker-controllable typebot variables, any registered user can publish a bot whose Send Email block attaches an absolute path such as /etc/passwd or /proc/self/environ and mails it to an address they control. This enables reading any file the server process can access, including process environment secrets such as the credential encryption key and database connection string, without administrative privileges or victim interaction. Open signup is enabled by default and the system SMTP credential is already configured, so no non-default configuration is required. This issue is fixed in version 3.18.0.
Detection & mitigation playbook
VulnerabilityDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for the affected component. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of the affected component has shipped for GHSA-j32h-2r6x-wmf3 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-j32h-2r6x-wmf3 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-j32h-2r6x-wmf3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-j32h-2r6x-wmf3 in your dependencies?
O3 detects GHSA-j32h-2r6x-wmf3 across dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.