CVE-2026-104634: beam_mcp: JSON boolean and null tool arguments reach dispatch as strings
Incorrect Type Conversion or Cast vulnerability in BeamMCP.Server in ScriptKittyOS beammcp allows an MCP client's JSON true, false and null tool arguments to reach the host's dispatch function as the strings "true", "false" and "nil". After BeamMCP.Schema.validate/2 accepted a value as a boolean, normalizearguments/2 passed every argument through tojsonvalue/1, whose atom clause converts true, false and nil to strings. A string is truthy in Elixir, so a host that tests a boolean argument, for example if args.dryrun, takes the opposite branch for false, and a guard such as confirm: false reads as set.
The client controls the argument and could send true directly, so the practical impact is limited to hosts whose behaviour on false differs from their behaviour on true, and to any policy layer in front of the server that permits false but refuses true. The same normalisation applies to prompts/get arguments, which exist from 0.5.0.
This issue affects beammcp: from 0.1.0 before 0.10.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
beam_mcpto a version that resolves this vulnerability.Fixed in 0.10.1
Event History
Frequently Asked Questions
Which deployments are affected?
beam_mcp versions from 0.1.0 before 0.10.1 are affected. The prompts/get argument path is affected only where that functionality is present, which is from version 0.5.0.
When does this create a meaningful security impact?
Impact depends on host dispatch code treating a boolean argument differently when it is false versus true. For example, a false value can arrive as the truthy Elixir string "false", causing a conditional such as if args.dry_run to take the enabled branch.
Can an unauthenticated client exploit this behavior?
The CVSS vector specifies low privileges required. Exploitation also requires the attacker to control a tool or prompts/get argument and a vulnerable host behavior or policy distinction involving false and true.
Are policy controls affected as well as host handlers?
Yes. A policy layer in front of the server may be bypassed if it permits false but rejects true, because the server can subsequently dispatch false as the string "false".
What is the available remediation?
Upgrade beam_mcp to version 0.10.1 or later. Until upgrading, review handlers and any front-end policy layers that rely on boolean false, null, or truthiness checks for tool and prompts/get arguments.