CVE-2026-55546 in QWED-MCP
Summary
by MITRE • 08/25/2026
QWED-MCP is a deterministic verification gateway for MCP. Prior to 0.2.1, verify_math_expression() in src/qwed_mcp/engines/math_engine.py passes attacker-controlled expression and claimed_result strings directly to SymPy's parse_expr() after only normalizing caret syntax to Python exponent syntax, without restricting global_dict, removing Python built-ins, or validating the expression AST. Because parse_expr() calls Python's eval() with built-ins available, an attacker who can cause a downstream caller to pass untrusted input to this public library function can use Python import functionality to execute arbitrary operating-system commands as the qwed-mcp process user, read or modify accessible data, exfiltrate process secrets, or reach internal services. The default MCP tool registry does not expose verify_math_expression(), so exploitation requires a downstream integration that invokes the library API with attacker-controlled input. This issue is fixed in version 0.2.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in QWED-MCP prior to version 0.2.1 represents a critical server-side code injection flaw rooted in improper neutralization of special elements used by an interpreter, specifically categorized under CWE-94 as Improper Control of Generation of Code or Script. The core technical defect resides within the verify_math_expression function located in src/qwed_mcp/engines/math_engine.py. This function is designed to validate mathematical expressions but fails to implement sufficient security controls when processing user-supplied input. Specifically, while the implementation normalizes caret syntax for exponentiation into Python-compatible format, it neglects to restrict the global dictionary passed to SymPy's parse_expr method and does not remove dangerous Python built-in functions from the execution environment. Furthermore, there is no validation of the resulting Abstract Syntax Tree against a whitelist of allowed operations or structures.
This architectural oversight allows an attacker who can supply untrusted input to this public library function to achieve arbitrary code execution on the host system. Because SymPy's parse_expr method internally invokes Python's eval function with access to built-ins, malicious actors can craft expressions that leverage standard Python modules such as os or subprocess to execute operating-system commands under the context of the qwed-mcp process user. The impact extends beyond simple command execution; it enables unauthorized reading and modification of accessible data files, exfiltration of sensitive secrets stored in memory or configuration files, and potential lateral movement by reaching internal services that are otherwise isolated from external networks. This aligns with ATT&CK technique T1059 Command and Scripting Interpreter, where the attacker utilizes a system's native scripting capabilities to perform malicious actions without deploying additional malware binaries.
The exploitation of this vulnerability is contingent upon specific integration patterns within the broader MCP ecosystem. The default Model Context Protocol tool registry does not expose the verify_math_expression function directly to end-users or external clients. Consequently, successful exploitation requires a downstream integration layer that explicitly invokes this library API with attacker-controlled input. This means that while the flaw exists in the core library, its practical risk is mediated by how third-party developers or system integrators configure their use of QWED-MCP. Systems that have wrapped this function and exposed it via an unauthenticated or poorly authenticated interface are at immediate risk, whereas those using default configurations remain unaffected unless they implement custom tooling that bypasses these safeguards.
Mitigation strategies must prioritize upgrading to version 0.2.1 where the issue has been resolved through stricter input validation and sandboxed execution environments. For systems unable to upgrade immediately, defensive coding practices should be implemented to sanitize inputs before passing them to mathematical parsing libraries. This includes implementing a strict whitelist of allowed operators and functions rather than relying on blacklist approaches which are prone to bypasses. Additionally, developers should ensure that any wrapper around SymPy or similar parsers explicitly clears the global namespace and restricts built-in access using mechanisms such as restricting globals to an empty dictionary or a curated set of safe mathematical constants and functions. Regular security audits of third-party library usage within MCP integrations are essential to identify other potential instances where untrusted data might be passed directly into interpreters without adequate sanitization.