EEF-CVE-2026-104634

Summary

Incorrect Type Conversion or Cast vulnerability in BeamMCP.Server in ScriptKittyOS beam_mcp 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, normalize_arguments/2 passed every argument through to_json_value/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.dry_run, 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 beam_mcp: from 0.1.0 before 0.10.1.

Details

1. Validation. BeamMCP.Schema.check_type/3 accepts a JSON false for a boolean property because the decoded value is the atom false.

2. Normalisation. BeamMCP.Server.normalize_arguments/2 in lib/beam_mcp/server.ex maps each declared key to an atom and passes each value through to_json_value/1. That function was written to encode host results for the wire, and its clause when is_atom(value) converts the value with Atom.to_string/1. true, false and nil are atoms, so they become the strings "true", "false" and "nil", at any depth of the argument map.

3. Dispatch. The host receives %{dry_run: "false"}. Any string is truthy in Elixir, so if args.dry_run takes the true branch. A host result carrying booleans was stringified the same way on the way out. The fix in 0.10.1 adds a clause that passes booleans and nil through unchanged.

Proof of concept

1. Declare a tool whose input_schema has "dry_run": {"type": "boolean"}.
2. Send tools/call with "arguments": {"dry_run": false}.
3. On beam_mcp 0.10.0 the dispatch function receives %{dry_run: "false"} and if args.dry_run evaluates the true branch. On 0.10.1 it receives %{dry_run: false}.

Impact

A host that branches on a boolean argument takes the opposite branch for false, so a safety guard such as confirm: false or dry_run: false is read as set. The client already controls the argument, so the gain over sending true is limited to hosts and intermediaries that treat the two values differently.

Workarounds

In the host's dispatch function, compare boolean arguments against both forms, for example args.flag in [true, "true"] and args.flag in [false, "false"], and treat the string "nil" as null where the schema admits null.