fix(security): GHSA-gvpp-v77h-5w8g — untrusted dev-source ACE

[cdeust]

Summary

Closes the local arbitrary code execution vulnerability GHSA-gvpp-v77h-5w8g reported by EQSTLab on 2026-05-27. CVSS v3.1 base 7.8 (High). Vulnerable range: neuro-cortex-memory ≤ 3.17.0.

Threat model (verbatim from advisory)

_find_dev_source() in mcp_server/handlers/open_visualization.py accepted CLAUDE_PROJECT_DIR (set automatically by Claude Code to whatever project the user has open) as a candidate Cortex dev-source root. A candidate qualified iff it contained a trivial two-marker pair — mcp_server/ subdirectory + ui/unified-viz.html file — that any attacker can replicate.

The handler then subprocess.run([sys.executable, str(bootstrap_path)]) against <dev_src>/mcp_server/server/visualize_bootstrap.py inside the qualifying directory, yielding local arbitrary code execution with the privileges of the victim's user process.

Two secondary surfaces:

• mcp_server/server/http_launcher.py::_detect_dev_source mirrored the same env-var ordering and rsyncs the returned dev source over the package path before respawning the server from the synced copy.
• mcp_server/server/visualize_bootstrap.py::_find_dev_source (invoked as a subprocess of the handler) inherited the parent process env and re-resolved CLAUDE_PROJECT_DIR → same rsync-overwrite path → persistent ACE.

Hardening

Three functions (open_visualization._find_dev_source, http_launcher._detect_dev_source, visualize_bootstrap._find_dev_source) now apply the same gate:

• CLAUDE_PROJECT_DIR is no longer consulted in any of them.
• CORTEX_DEV_ROOT is consulted only when CORTEX_DEV_SOURCE_SYNC=1 is set as an explicit opt-in — exact string "1" required (so an accidental "true"/"yes" in a shell rc file cannot silently re-open the hole).
• Launcher's filesystem-position auto-detect ("walk up from the launcher module's own location") is preserved — an attacker would need write access to the user's site-packages to abuse it, which is a strictly higher-privilege precondition than the exploit it would yield.
• The conventional ~/Documents/Developments/Cortex fallback remains (user-controlled filesystem).

Verification

• EQSTLab PoC re-run against the patched code: bootstrap='no_dev_source', sentinel file never created, no rsync, no subprocess against the attacker path.
• Legitimate dev workflow (CORTEX_DEV_SOURCE_SYNC=1 + CORTEX_DEV_ROOT pointing at a real checkout): still works, bootstrap fires as expected.
• 10 falsification tests added across two files:
  • tests_py/handlers/test_open_visualization.py::TestDevSourceSecurityHardening (4 tests — handler)
  • tests_py/server/test_http_launcher_security.py::TestDetectDevSourceSecurityHardening (3 tests — launcher)
  • tests_py/server/test_http_launcher_security.py::TestBootstrapFindDevSourceSecurityHardening (3 tests — bootstrap subprocess)
• Full open_visualization suite: 17/17 passing (4 pre-existing + 13 new).
• Audit of sibling repos (automatised-pipeline, ai-prd-generator, ai-prd-generator-plugin, zetetic-team-subagents): clean of the same class of vulnerability (no CLAUDE_PROJECT_DIR consumption, no env-derived subprocess.run/Command::new, no marker-file validation followed by exec).

Release plan

After merge:

1. Tag v3.17.1 on main
2. Build wheel + sdist, publish to PyPI
3. Yank 3.17.0 from PyPI with reason citing GHSA-gvpp-v77h-5w8g
4. Publish the GHSA advisory crediting EQSTLab as reporter

Credit

Reported by @EQSTLab (Experts, Qualified Security Team — SK Shieldus). Coordinated disclosure via private GHSA draft, complete with structured PoC and a precise remediation diff. Thanks for the careful, rigorous report.

source: GHSA-gvpp-v77h-5w8g

🤖 Generated with Claude Code