CVE-2026-104634 in beam_mcp
Summary
by MITRE • 10/08/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in BeamMCP.Server within ScriptKittyOS represents a critical logic error stemming from incorrect type conversion during the processing of Model Context Protocol arguments. This flaw allows an MCP client to transmit JSON boolean values, specifically true and false, as well as null, which are subsequently interpreted by the host application not as their native data types but as string literals "true", "false", and "nil". The root cause lies in the normalization process within the beam_mcp library. After initial schema validation accepts a value as a boolean via BeamMCP.Schema.validate/2, the normalize_arguments/2 function passes all arguments through to_json_value/1. This internal helper contains an atom clause that explicitly converts Elixir atoms true, false, and nil into their string representations. Consequently, when these values are passed to the host's dispatch function, they arrive as strings rather than booleans or nulls.
The operational impact of this vulnerability is significant for any server-side logic that relies on strict type checking or boolean evaluation of tool arguments. In Elixir, a non-empty string such as "false" evaluates to true in conditional contexts because it is truthy. This leads to inverted logic execution where a host expecting a false value receives a string that triggers the positive branch of an if statement. For example, if a server checks for a dry_run flag using a condition like if args.dry_run, passing the argument as "false" will cause the system to execute the run operation instead of skipping it, effectively ignoring user intent or security constraints. Similarly, guard clauses that expect false, such as confirm: false, may incorrectly evaluate as set because the string literal is present and truthy, potentially bypassing confirmation prompts or safety checks designed to prevent destructive actions.
This issue affects beam_mcp versions from 0.1.0 up to but not including 0.10.1. The vulnerability extends beyond tool arguments to include prompt/get arguments, which have been subject to this normalization behavior since version 0.5.0 of the library. While the client controls the input and could theoretically send true directly, the practical exploitation scope is largely confined to scenarios where the host's behavior differs distinctly between boolean false and string "false", or when intermediate policy layers permit false but refuse true based on type expectations. This creates a subtle bypass mechanism for access control policies that rely on strict type matching rather than semantic value interpretation.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to correctly interpret and validate the data types of incoming arguments against their expected schema definitions. It also relates to CWE-841 Improper Enforcement of Type Constraints during type conversion processes. In terms of attack vectors, this falls under ATT&CK technique T1602 Data from Configuration Repositories or more broadly T1530 Data from Cloud Storage if the configuration is remote, but primarily it represents a logic flaw in data handling that could facilitate unauthorized actions by manipulating argument types to bypass security controls.
Mitigation strategies must focus on updating the beam_mcp library to version 0.10.1 or later, where this normalization behavior has been corrected to preserve native JSON types during dispatch. For systems unable to update immediately, developers should implement explicit type casting and validation layers within their host applications before processing arguments from MCP clients. This includes verifying that boolean fields are indeed booleans using strict equality checks rather than truthy/falsy evaluations in Elixir conditionals. Additionally, input sanitization routines should be employed to detect and reject string representations of boolean values when native types are expected, ensuring that the semantic intent of the client matches the technical expectations of the server logic.