EUVD-2026-94981
GHSA-rcm8-2hxq-3q25
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as MCP client
-
ExploitSend tool argument false or null
-
ExecutionServer casts value to truthy string 'false'
-
ImpactHost takes inverted boolean branch
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Correct type conversion
|
| Exploitation Conditions | Exploitation requires an MCP client (PR:L) able to invoke tools/call, or prompts/get on versions 0.5.0+, and sending a JSON boolean false or null argument. The vulnerability only has effect when the host application tests a boolean argument whose false branch differs from its true branch (e.g. 'if args.dry_run' or a 'confirm: false' guard), or when a policy layer in front of the server permits false but refuses true. Key limiting factors: the attacker must already be an authorized MCP client; the client could instead send true directly, so impact is confined to false-specific divergent behavior; and the prompts/get vector does not exist before 0.5.0. Hosts that never branch on a false boolean are unaffected. |
| Impact | All signals converge on LOW real-world risk. The CVSS 4.0 base score of 2.3 reflects a vulnerability requiring an authenticated MCP client (PR:L) and a specific attack requirement (AT:P) - namely a host whose logic branches differently on a false versus a true boolean. CISA SSVC reinforces this: Exploitation=none, Automatable=no, Technical Impact=partial. No CISA KEV listing and no public exploit identified at time of analysis. EPSS was not provided. The CVSS vector shows VI:L (low integrity impact) with VC:N and VA:N, which conflicts with the input 'Information Disclosure' tag - there is no confidentiality impact, so the tag appears mislabeled; this is a type-confusion logic-bypass, not a disclosure. The vendor's own description explicitly caps impact: because the client controls the argument and could simply send true directly, the only practical exposure is hosts that behave differently on false (e.g. 'if args.dry_run', 'confirm: false') or a policy layer that permits false but refuses true. This is a genuine correctness defect worth patching but not an urgent priority. |
| Exploit ScenarioDerived | An authenticated MCP client sends a tools/call (or prompts/get) argument with a JSON boolean set to false - for example dry_run:false or confirm:false. beam_mcp normalizes it to the string "false", which is truthy in Elixir, so a host testing 'if args.dry_run' takes the opposite branch and performs the real (non-dry-run) action, or treats a confirmation guard as satisfied. No public exploit code has been identified. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 08, 2026
Incorrect type conversion in the BeamMCP (beam_mcp) Elixir library from 0.1.0 before 0.10.1 causes an authenticated MCP client's JSON boolean and null tool arguments to arrive at the host's dispatch function as the Elixir strings "true", "false" and "nil"; because a string is truthy in Elixir, a host that branches on truthiness - for example if args.dry_run or a confirm: false guard - evaluates a client-supplied false as though it were set. The same normalization applies to prompts/get arguments on versions 0.5.0 and later, while the practical impact is bounded: the client could have sent true directly, so only hosts or policy layers whose false branch diverges from their true branch are meaningfully affected, and an attacker must already be an authorized MCP client (CVSS 4.0 base 2.3; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N). No public exploit has been identified at time of analysis and CISA SSVC records no exploitation; a vendor-released patch (0.10.1) is available.
RemediationAI
Upgrade BeamMCP to version 0.10.1, the first release that removes the atom clause in to_json_value/1 that stringified true, false and nil; the upstream fix is commit 289dbdbad641943b29a3b8d1eb36506cc8cec10a and the vendor advisory is https://github.com/ScriptKittyOS/beam_mcp/security/advisories/GHSA-wv7p-j6qh-3hj4 (vendor-released patch: 0.10.1). If upgrading must be deferred, the compensating control is to stop relying on Elixir truthiness for MCP-sourced boolean arguments - compare with strict equality (args.dry_run == true, or pattern-match with is_boolean/1 guard) and explicitly coerce the strings "true", "false" and "nil" back to their boolean values before dispatch; the trade-off is that this must be replicated in every host and does not help third-party code that already consumes the normalized map. Alternatively, a policy layer placed in front of the server can reject any argument whose JSON type is boolean or null for fields the host treats as flags, which prevents the stringified-false case entirely but will also reject legitimate true values for those same fields once the library is upgraded. Note that hosts whose logic never branches on a false boolean argument are not exposed and require no change.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability is CWE-704 (Incorrect Type Conversion or Cast) in the Elixir MCP (Model Context Protocol) server library ScriptKittyOS beam_mcp, identified by CPE cpe:2.3:a:scriptkittyos:beam_mcp. When an MCP client issues tools/call (or prompts/get on 0.5.0+), BeamMCP.Schema.validate/2 correctly accepts a JSON true, false or null argument as a boolean, but normalize_arguments/2 then passes every accepted argument through to_json_value/1, whose atom clause converts the Elixir atoms true, false and nil into the strings "true", "false" and "nil". The type is silently widened from boolean to string across the MCP/JSON boundary, and since Elixir treats any non-empty string as truthy, downstream dispatch logic that tests the argument by truthiness rather than by strict type comparison receives the opposite semantic from what the client sent (or, for confirm: false, receives what reads as an affirmative value). The flaw is a serialization/semantic-mismatch class issue rather than a memory-safety problem, so confidentiality and availability are unaffected; the integrity of host-side decisions that depend on boolean arguments is what can be subverted, and only where the false branch differs from the true branch or where a fronting policy layer permits false but refuses true.
Know when Elixir gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Reachable over the MCP channel (AV:N) but only an authenticated client (PR:L); AC:H because impact depends on a host that branches differently on false; integrity-only (I:L), no confidentiality or availability effect.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
DescriptionCVE.org
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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Unbounded recursion in the Elixir `protobuf` Hex package (versions >= 0.8.0, < 0.16.1) lets unauthenticated remote attac
Improper JWT signature verification in Dashbit's nimble_zta (0.1.2 up to but not including 0.1.3) lets an unauthenticate
Session-swapping authentication bypass in the Elixir library AshAuthentication (versions 4.10.0 before 4.15.0 and 5.0.0-
Authentication bypass in the Elixir library ash_authentication lets an attacker who operates one federated identity-prov
Account takeover in AshAuthentication (Elixir/Ash) 4.14.0 through 4.14.x and 5.0.0-rc.10 through 5.0.0-rc.13 lets unauth
Server-Side Request Forgery protection bypass in the Elixir safeurl library (versions 0.1.0 and later) allows unauthenti
Unauthenticated remote CPU exhaustion in mtrudel Bandit's HTTP/2 server (versions before 1.14.0) is achievable by holdin
Unbounded per-connection memory and CPU growth in the Elixir Bandit HTTP/2 server (0.3.6 up to 1.14.0) lets an unauthent
Unauthenticated remote denial of service in the Elixir HTTP server Bandit (mtrudel/bandit) from 0.1.0 before 1.14.0 lets
Unauthenticated remote attackers can consume disproportionate server CPU on Bandit (mtrudel/bandit, Elixir/Erlang) by se
Memory-exhaustion denial of service in the elixir-protobuf library (protobuf) from 0.8.0 onward allows an unauthenticate
Atom table exhaustion in the Ash framework (Elixir) allows an unauthenticated remote attacker to crash a BEAM node by su
Exploit-DB