Vulnerability Database

326,895

Total vulnerabilities in the database

CVE-2026-29787

Summary

The /api/health/detailed endpoint returns detailed system information including OS version, Python version, CPU count, memory totals, disk usage, and the full database filesystem path. When MCP_ALLOW_ANONYMOUS_ACCESS=true is set (required for the HTTP server to function without OAuth/API key), this endpoint is accessible without authentication. Combined with the default 0.0.0.0 binding, this exposes sensitive reconnaissance data to the entire network.

Details

Vulnerable Code

health.py:90-101 - System information collection

system_info = { "platform": platform.system(), # e.g., "Linux", "Darwin" "platform_version": platform.version(), # Full OS kernel version string "python_version": platform.python_version(),# e.g., "3.12.1" "cpu_count": psutil.cpu_count(), # CPU core count "memory_total_gb": round(memory_info.total / (1024**3), 2), "memory_available_gb": round(memory_info.available / (1024**3), 2), "memory_percent": memory_info.percent, "disk_total_gb": round(disk_info.total / (1024**3), 2), "disk_free_gb": round(disk_info.free / (1024**3), 2), "disk_percent": round((disk_info.used / disk_info.total) * 100, 2) }

health.py:131-132 - Database path disclosure

if hasattr(storage, 'db_path'): storage_info["database_path"] = storage.db_path # Full filesystem path

Authentication Bypass Path

The /api/health/detailed endpoint uses require_read_access which calls get_current_user. When MCP_ALLOW_ANONYMOUS_ACCESS=true, the auth middleware grants access:

# middleware.py:372-379 if ALLOW_ANONYMOUS_ACCESS: logger.debug("Anonymous access explicitly enabled, granting read-only access") return AuthenticationResult( authenticated=True, client_id="anonymous", scope="read", auth_method="none" )

Note: The basic /health endpoint (line 68) has no auth dependency at all and returns version and uptime information unconditionally.

Information Exposed

| Field | Example Value | Reconnaissance Value | |-------|--------------|---------------------| | platform | "Linux" | OS fingerprinting | | platform_version | "#1 SMP PREEMPT_DYNAMIC..." | Kernel version → CVE targeting | | python_version | "3.12.1" | Python CVE targeting | | cpu_count | 8 | Resource enumeration | | memory_total_gb | 32.0 | Infrastructure profiling | | database_path | "/home/user/.mcp-memory/memories.db" | Username + file path disclosure | | database_size_mb | 45.2 | Data volume estimation |

Attack Scenario

  1. Attacker scans the local network for services on port 8000
  2. Finds mcp-memory-service with HTTP enabled and anonymous access
  3. Calls GET /api/health/detailed (no credentials needed)
  4. Receives OS version, Python version, full database path (revealing username), system resources
  5. Uses this information to:
    • Target known CVEs for the specific OS/Python version
    • Identify the database file location for potential direct access
    • Profile the system for further attacks

PoC

# Show the system info that would be exposed import platform, psutil system_info = { "platform": platform.system(), "platform_version": platform.version(), "python_version": platform.python_version(), "cpu_count": psutil.cpu_count(), "memory_total_gb": round(psutil.virtual_memory().total / (1024**3), 2), } print(system_info) # All of this is returned to unauthenticated users

Impact

  • OS fingerprinting: Exact OS and kernel version enables targeted exploit selection
  • Path disclosure: Database path reveals username, home directory structure, and file locations
  • Resource enumeration: CPU, memory, and disk info reveal infrastructure scale
  • Reconnaissance enablement: Combined information significantly reduces attacker effort for follow-up attacks

Remediation

  1. Remove system details from default health endpoint - return only status, version, uptime:
@router.get("/health/detailed") async def detailed_health_check( storage: MemoryStorage = Depends(get_storage), user: AuthenticationResult = Depends(require_write_access) # Require admin/write access ): # Only return storage stats, not system info ...
  1. Do not expose database_path - this leaks the filesystem structure:
# Remove or redact # storage_info["database_path"] = storage.db_path # REMOVE THIS
  1. Add auth to basic /health or limit it to status-only (no version):
@router.get("/health") async def health_check(): return {"status": "healthy"} # No version, no uptime

Alternatively, Bind to 127.0.0.1 by default instead of 0.0.0.0, preventing network-based reconnaissance entirely:

# In config.py — change default from '0.0.0.0' to '127.0.0.1' HTTP_HOST = os.getenv('MCP_HTTP_HOST', '127.0.0.1')

Users who need network access can explicitly set MCP_HTTP_HOST=0.0.0.0, making the exposure a conscious opt-in rather than a default.

CVSS v3:

  • Severity: Unknown
  • Score:
  • AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

CWEs:

Software From Fixed in
Python icon mcp-memory-service - 10.21.0

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.