beam_mcp: JSON boolean and null tool arguments reach dispatch as strings
## 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 wi
- Products
- beam_mcp
- Affected versions
- 0.1.0, 0.10.0, 0.2.0, 0.3.0, 0.3.1, 0.4.0, 0.5.0, 0.6.0, 0.7.0, 0.8.0, 0.9.0
- Fixed versions
- 0.10.1
- CVEs
- CVE-2026-104634
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 28 Oct 2026, 09:09 UTC · Revision 1
Source evidence
beam_mcp: JSON boolean and null tool arguments reach dispatch as strings
core-osv · Original sourcePublished 8 Oct 2026, 13:41 UTC
## 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 wi
osv:EEF-CVE-2026-104634
beam_mcp
Fixed versions: 0.10.1
Complete source record
{
"id": "2a3423becdc93d7feab3612ca1cc976fa39b64722edbb18fa6d98d3c8fe0fc5a",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-104634",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "beam_mcp: JSON boolean and null tool arguments reach dispatch as strings",
"summary": "## 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 wi",
"evidence": "osv:EEF-CVE-2026-104634",
"products": [
{
"name": {
"value": "beam_mcp",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "0.10.1",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": [
{
"value": "0.1.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.10.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.2.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.3.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.3.1",
"evidence": "/affected/0/versions"
},
{
"value": "0.4.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.5.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.6.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.7.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.8.0",
"evidence": "/affected/0/versions"
},
{
"value": "0.9.0",
"evidence": "/affected/0/versions"
}
]
}
],
"severity": "low",
"structured": {
"id": "EEF-CVE-2026-104634",
"aliases": [
"CVE-2026-104634",
"EEF-CVE-2026-104634",
"GHSA-wv7p-j6qh-3hj4"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N"
}
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "0.10.1"
}
]
}
],
"package": {
"name": "beam_mcp",
"purl": "pkg:hex/beam_mcp",
"ecosystem": "Hex"
},
"versions": [
"0.1.0",
"0.10.0",
"0.2.0",
"0.3.0",
"0.3.1",
"0.4.0",
"0.5.0",
"0.6.0",
"0.7.0",
"0.8.0",
"0.9.0"
],
"database_specific": {
"source": "https://cna.erlef.org/osv/EEF-CVE-2026-104634.json"
}
},
{
"ranges": [
{
"repo": "https://github.com/ScriptKittyOS/beam_mcp",
"type": "GIT",
"events": [
{
"introduced": "083838eb8e17fe5f6fcaf761bdbe203110288b0b"
},
{
"fixed": "289dbdbad641943b29a3b8d1eb36506cc8cec10a"
}
]
}
],
"versions": [
"v0.10.0",
"v0.9.0",
"v0.8.0",
"v0.7.0",
"v0.6.0",
"v0.5.0",
"v0.4.0",
"v0.3.1",
"v0.3.0",
"v0.2.0",
"v0.1.0"
],
"database_specific": {
"source": "https://cna.erlef.org/osv/EEF-CVE-2026-104634.json"
}
}
],
"modified": "2026-10-08T13:56:03.266254685Z",
"provider": "osv",
"references": [
"https://github.com/ScriptKittyOS/beam_mcp/security/advisories/GHSA-wv7p-j6qh-3hj4",
"https://cna.erlef.org/cves/CVE-2026-104634.html",
"https://github.com/ScriptKittyOS/beam_mcp/commit/083838eb8e17fe5f6fcaf761bdbe203110288b0b",
"https://github.com/ScriptKittyOS/beam_mcp/commit/289dbdbad641943b29a3b8d1eb36506cc8cec10a",
"https://hex.pm/packages/beam_mcp"
],
"provider_metadata": {
"cpe_ids": [
"cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:*"
],
"cwe_ids": [
"CWE-704"
],
"capec_ids": [
"CAPEC-153"
]
}
},
"related_cves": [
{
"value": "CVE-2026-104634",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 99681,
"published_at": "2026-10-08T13:41:05.745+00:00"
}