CVE-2026-44717: MCP Calculate Server RCE
Critical CVSS (9.8) reachable over network.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HTL;DR - CVE-2026-44717 is a critical unauthenticated remote-code-execution flaw caused by unsafe Python
eval()use. - MCP Calculate Server versions before 0.1.1 are affected; upgrade to 0.1.1 or later. - A public working PoC exists, but confirmed in-the-wild exploitation has not been established.
CVE-2026-44717 is a critical MCP Calculate Server vulnerability that can enable unauthenticated remote code execution through unsafe Python eval() usage. Administrators should identify affected deployments, restrict exposure, investigate suspicious activity, and upgrade to version 0.1.1 or later.
For broader context, review our cybersecurity framework glossary and guidance on securing service accounts in Active Directory.
What Happened, in Brief
CVE-2026-44717 affects MCP Calculate Server, a mathematical calculation service built around the Model Context Protocol and SymPy. Before version 0.1.1, externally influenced mathematical expressions could reach Python’s eval() function without adequate sanitization or restriction. An attacker who can submit or influence an expression may therefore execute arbitrary Python code with the privileges of the MCP server process or its associated application.
The issue is relevant to deployments connected to large language model workflows. Prompt injection or jailbreaking may cause an LLM-integrated application to pass attacker-controlled content into the calculation tool. Model-level filtering is not a sufficient security boundary because the vulnerable server evaluates the resulting expression in Python.
| Field | Details |
|---|---|
| CVE ID | CVE-2026-44717 |
| CVSS | 9.8 Critical |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Attack vector | Network |
| Authentication or privileges required | None |
| User interaction | None |
| Affected component | MCP Calculate Server / server.py |
| Affected versions | Versions before 0.1.1 |
| Fixed version | 0.1.1 |
| Patch available | Yes |
| CISA KEV status | Not listed |
The practical impact is arbitrary Python-code execution. Depending on deployment permissions, an attacker could read credentials, access files, make network connections, alter data, or establish persistence. The vulnerability does not automatically grant host administrator or root privileges. Its effective impact is bounded by the account, container, VM, and network controls surrounding the service.
Analyst’s Take: Treat this as a code-execution issue first and an LLM security issue second. The LLM workflow can provide an attacker-controlled path, but any untrusted caller that influences the evaluated expression presents the same underlying risk.
What’s the Root Cause?
The root cause is improper control of code generation and execution. The vulnerable implementation evaluates user-influenced mathematical expressions using Python’s eval() rather than a constrained expression parser. Mathematical input is therefore treated as executable Python syntax, allowing expressions to reference modules and invoke functionality outside the intended calculation feature.
The vendor advisory documents examples such as:
expression:"0 + float(__import__('sympy').__version__[:4])"
and:
expression:"0 + float(__import__('os').getuid())"
The first expression demonstrates that Python import functionality can be reached through the calculation interface. The second can disclose the operating-system user ID running the service. These examples are not merely malformed arithmetic; they show that attacker-controlled input can execute Python operations beyond the intended mathematical use case.
The issue is associated with CWE-94, Improper Control of Generation of Code, and CWE-1427, Improper Neutralization of Input Used for LLM Prompting. The LLM-related classification matters when the calculation server is exposed through an agent or model workflow, but the underlying unsafe evaluation remains dangerous even without an LLM. Any untrusted caller able to influence the expression should be treated as a potential code-execution source.
Who Needs to Act
Organizations running MCP Calculate Server or the affected server.py component must identify every deployment running a version below 0.1.1. The documented affected range is:
| Product or component | Vulnerable versions | Fixed version |
|---|---|---|
MCP Calculate Server / server.py |
< 0.1.1 |
0.1.1 |
The available advisory and NVD information do not identify additional affected branches, alternate product names, or backported fixes. Administrators should verify the installed package or repository revision rather than assuming that a vendor-specific wrapper is patched. In containerized deployments, check the image contents and build provenance, not only the host’s package inventory.
Prioritize systems that expose the MCP server to the internet, permit untrusted users to submit calculations, or connect the service to an LLM, agent, automation platform, or external tool gateway. Also prioritize instances running with access to cloud credentials, source repositories, internal APIs, writable application directories, or sensitive host-mounted paths.
Where the service is managed through a dependency file, lockfile, container image, or custom checkout, record the exact deployed version. A deployment described only as “latest” is not sufficient evidence of remediation. If the version cannot be established, treat it as potentially vulnerable until it is upgraded or removed.
Why This CVSS Score?
CVE-2026-44717 has a CVSS v3.1 score of 9.8 Critical with this vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
The score reflects a highly reachable attack path:
| Metric | Value | Operational meaning |
|---|---|---|
| Attack Vector | Network | The vulnerable service can be reached over a network connection. |
| Attack Complexity | Low | Exploitation does not require unusual conditions or sophisticated timing. |
| Privileges Required | None | The attacker does not need an authenticated account or existing permissions. |
| User Interaction | None | Exploitation does not require a legitimate user to approve an action. |
| Scope | Unchanged | The impact remains within the vulnerable security authority. |
| Confidentiality | High | Successful execution may permit access to readable files, secrets, or service data. |
| Integrity | High | The attacker may modify files, data, or application behavior available to the process. |
| Availability | High | The attacker may disrupt the service or consume or destroy accessible resources. |
The score describes the vulnerability’s technical severity, not the guaranteed outcome in every deployment. Network segmentation, authentication imposed by a reverse proxy, container isolation, read-only filesystems, and least-privilege service accounts may reduce practical exposure. They do not remove the need to patch because the vulnerable code remains reachable wherever an attacker can influence an evaluated expression.
Has It Been Exploited?
A public proof of concept exists. The GitHub security advisory includes functional examples demonstrating arbitrary Python-code execution through crafted mathematical expressions, including module access and operating-system information disclosure. That evidence establishes exploitability and should move this issue ahead of routine, low-impact dependency updates.
Confirmed exploitation in the wild has not been established in the available sources. CVE-2026-44717 is not listed in the CISA Known Exploited Vulnerabilities catalog, and the reviewed material does not identify a named threat actor, active campaign, ransomware operation, or confirmed victim. The advisory notes that the repository is publicly used and mentioned by other companies and users, which increases the potential exposure but is not evidence of exploitation.
The current assessment is therefore:
| Question | Assessment |
|---|---|
| Is a public PoC available? | Yes. The vendor advisory contains working demonstration expressions. |
| Is arbitrary code execution demonstrated? | Yes. |
| Is exploitation confirmed in the wild? | Not established from the reviewed sources. |
| Is the CVE in CISA KEV? | No, based on the supplied assessment. |
| Should defenders wait for confirmed exploitation? | No. The issue is unauthenticated, network-reachable, and critical. |
Detection Guidance
Start with asset discovery. Search source repositories, Python environments, dependency manifests, container build files, orchestration definitions, and MCP client configurations for MCP Calculate Server or server.py. Establish the deployed version and exposure path, including direct network listeners, reverse proxies, local stdio integrations, and LLM agent tool registrations.
A vulnerable service may be exposed indirectly. For example, an internet-facing application may accept prompts, pass tool calls to an internal MCP server, and return the result. In that design, the MCP server may not have a public IP address but remains reachable through an attacker-controlled application workflow. Review tool routing and authorization, not only firewall rules.
Technical Notes
If HTTP request logging is enabled, search for calculation requests containing Python metacharacters or known execution indicators. Adapt the field names to the deployed API format:
jq -r '
select(
tostring
| test("__import__|importlib|os\\.|subprocess|Popen|system\\(|getuid|socket|/bin/sh|/bin/bash";
"i")
)
| [.timestamp, .client_ip, .path, .request_body]
| @tsv
' /var/log/mcp/*.json 2>/dev/null
For reverse-proxy logs that record raw request lines, use:
grep -Ei \
'(__import__|importlib|os%2e|subprocess|Popen|getuid|/bin/(ba)?sh|socket)' \
/var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null
Network monitoring should also look for unexpected outbound connections from the MCP process, particularly soon after a suspicious calculation request. A process-level rule can be more reliable than a payload signature:
Alert when:
process.name in ("python", "python3")
AND process.parent.name matches ("mcp", "server", "uvicorn", "gunicorn")
AND child_process.name in ("sh", "bash", "curl", "wget", "nc", "ncat", "socat")
These indicators are generic and may produce false positives. Investigators should compare the event time with MCP requests, inspect the service account’s file and network access, and preserve the process command line and environment before restarting a potentially compromised instance.
Remediation and Patching
The primary remediation is to upgrade MCP Calculate Server to 0.1.1 or later. Because the supplied research does not specify a universal package name or installation method, use the project’s documented installation workflow and confirm that the deployed artifact resolves to the fixed version. For a source checkout, verify the checked-out release or commit; for a Python package, verify the installed distribution metadata.
A generic verification workflow is:
python -m pip show mcp-calculate-server
python -m pip install --upgrade "mcp-calculate-server>=0.1.1"
python -m pip check
The exact package name may differ in a local or repository-based deployment. Do not run the command blindly if the service is installed from a Git checkout, a private package index, or a container image. In those cases, rebuild from the patched 0.1.1 release or later, redeploy, and verify the running image or source tree.
After upgrading, restart the service and validate the actual runtime version:
python -c 'import importlib.metadata as m; print(m.version("mcp-calculate-server"))'
If the distribution name is different, inspect the project metadata or image contents. Confirm that no old worker processes remain and that health checks are reaching the newly deployed instance.
Temporary Mitigations
If immediate patching is impossible, the safest workaround is to disable or remove the vulnerable MCP Calculate Server. If it must remain operational temporarily, apply layered controls:
- Block untrusted network access with firewall or security-group rules.
- Require authentication at a trusted gateway where feasible.
- Prevent untrusted prompts and tool arguments from reaching the calculation endpoint.
- Replace unrestricted
eval()with a safe mathematical-expression parser. - Enforce an allowlist of operators, functions, symbols, and input formats.
- Run the service under a dedicated, unprivileged account.
- Remove cloud credentials and unnecessary filesystem access.
- Use container or VM isolation, read-only filesystems, and restricted egress.
- Monitor process creation and outbound network activity.
A temporary network restriction might look like this on a Linux host using ufw, although the correct rule depends on the deployment’s interface and source ranges:
sudo ufw deny to any port 8000 proto tcp
sudo systemctl stop mcp-calculate-server
sudo systemctl disable mcp-calculate-server
Do not treat network blocking as a code fix. Any trusted application or LLM workflow that can still submit attacker-influenced expressions remains a risk. If a workaround relies on input filtering, block Python-specific constructs such as __import__, attribute traversal, builtins access, and process or filesystem APIs, but prefer replacing eval() entirely because blacklist filtering is fragile.
For organizations reviewing broader security controls, a security architecture review FAQ can help structure assessment of trust boundaries, service exposure, and compensating controls.
For potentially exposed instances, investigate before redeployment. Review authentication and proxy logs, MCP request histories, child processes spawned by the service account, shell history where available, unexpected files, modified application code, cloud audit logs, and outbound DNS or network connections. Rotate credentials accessible to the service if compromise cannot be ruled out.
References
The following sources provide the vulnerability record, advisory details, exploitation examples, and remediation context:
- NVD: CVE-2026-44717
- GitHub Security Advisory: GHSA-2mgq-7rfg-rwpj
- GitHub Advisory API record
- CISA Known Exploited Vulnerabilities Catalog
The first response should be version verification and upgrade. MCP Calculate Server versions before 0.1.1 should be considered vulnerable, and deployments should be upgraded to 0.1.1 or later or removed from service. The public PoC supports prompt action even though confirmed in-the-wild exploitation has not been established.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.