GHSA-G9RG-8VQ5-MPWM: Cross-Origin Memory Theft and Information Disclosure in mcp-memory-service

The mcp-memory-service package provides persistent memory storage for AI agent pipelines, such as those utilized by Claude Code, LangGraph, and AutoGen. The service is typically executed as a local background process bound to a loopback interface port. It exposes an HTTP API that allows AI agents to store, search, and retrieve conversational context or project data.

The vulnerability, identified as GHSA-G9RG-8VQ5-MPWM, encompasses two distinct security flaws that compound to create a severe risk profile. The primary flaw is a permissive Cross-Origin Resource Sharing (CORS) policy (CWE-942). The application initializes its web server with the Access-Control-Allow-Origin header set to a wildcard value, effectively removing origin restrictions for cross-origin requests.

The secondary flaw involves information disclosure (CWE-200) within the data retrieval logic. The search_by_tag_chronological() function implements a database query that fails to account for the application's soft-delete mechanism. Consequently, records marked for deletion remain accessible through this specific endpoint.

When chained, these vulnerabilities allow a remote attacker to execute JavaScript in a victim's browser, query the local mcp-memory-service instance, and exfiltrate sensitive AI memory context. This data often includes proprietary source code, internal architecture details, and hardcoded API keys submitted during AI interactions.

The fundamental cause of the cross-origin exposure lies in the application's initialization parameters for its web framework. By explicitly configuring the CORS middleware to accept * as an allowed origin, the developer bypassed the browser's Same-Origin Policy (SOP). The SOP normally prevents an arbitrary website from reading responses generated by a local service.

In the context of local development services, developers frequently misconfigure CORS policies under the assumption that binding to localhost provides sufficient network isolation. However, modern web browsers executing malicious JavaScript on an external website can route HTTP requests to localhost interfaces. The presence of the wildcard CORS header instructs the browser to release the response payload to the requesting malicious origin.

The logic flaw in the search_by_tag_chronological() function stems from incomplete implementation of the data lifecycle. The application uses a soft-delete pattern, setting a boolean flag in the database rather than executing a DROP or DELETE statement. This preserves data integrity for potential recovery but requires all subsequent read operations to actively filter out inactive records.

The vulnerable search function constructs a database query filtering solely by the user-supplied tag and temporal constraints. It omits the critical deleted=False conditional clause present in other application queries. This oversight directly exposes records that the user believes are permanently removed from the system.

The mcp-memory-service codebase relies on a Python-based web framework to expose its API. In versions prior to 10.25.1, the CORS middleware explicitly defined a wildcard string for the allowed origins configuration. This configuration applied globally to all registered endpoints, including those handling sensitive data retrieval.

# Vulnerable CORS Configuration (Conceptual)
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"], # Flaw: Wildcard allows any origin
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

The fix applied in version 10.25.1 replaces the wildcard with strict loopback bindings. By explicitly defining http://localhost and http://127.0.0.1, the service instructs the browser to reject cross-origin requests originating from any external domain.

# Patched CORS Configuration (Conceptual)
app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost", "http://127.0.0.1"], # Fix: Strict origin binding
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

Additionally, the patch rectifies the database query construction in the search_by_tag_chronological() function. The vulnerable implementation executed queries without checking the internal deletion state. The patch injects the missing boolean filter, ensuring the endpoint only returns active memory records.

# Vulnerable Query logic
results = db.query(MemoryItem).filter(MemoryItem.tag == requested_tag).all()
 
# Patched Query logic
results = db.query(MemoryItem).filter(
    MemoryItem.tag == requested_tag,
    MemoryItem.deleted == False # Fix: Soft-delete enforcement
).all()

Exploitation requires the victim to run the vulnerable mcp-memory-service locally while concurrently browsing the internet. The attacker must entice the victim to visit a malicious website or compromise a legitimate site to host the exploitation payload. No specialized network positioning is required, as the attack leverages the victim's own browser as a proxy.

Upon navigating to the malicious page, embedded JavaScript executes a standard HTTP GET request targeting the predictable local port used by the MCP service. The payload specifically targets the search_by_tag_chronological endpoint, passing common tags (e.g., "auth", "keys", "context") via URL parameters.

The browser dispatches the request to the local service. The service processes the query, retrieves the matching database records (including soft-deleted data), and returns the JSON response paired with the Access-Control-Allow-Origin: * header. The browser evaluates the CORS header, determines the cross-origin read is permitted, and passes the JSON payload to the attacker's script.

The final exploitation phase involves the malicious JavaScript transmitting the retrieved data back to an attacker-controlled command and control (C2) server. This operation occurs silently in the background, typically without triggering any visible indicators to the victim.

The vulnerability carries a CVSS score of 8.1, reflecting the high impact on data confidentiality combined with the low complexity of the attack vector. While the attack requires user interaction, visiting a web page is a normal user behavior, making the prerequisite trivial for a motivated adversary.

The primary consequence is severe information disclosure. The mcp-memory-service functions as the persistent brain for AI agents processing proprietary tasks. Exposed memory contexts frequently contain highly sensitive artifacts, including application source code, infrastructure configurations, and session tokens that developers inadvertently copy into AI chat prompts.

The soft-delete logic flaw significantly amplifies the exposure risk. Developers who actively managed their security posture by deleting sensitive interactions from the AI agent interface remain vulnerable. The backend database retains the underlying records, and the vulnerable search endpoint happily returns them to the attacker.

This vulnerability introduces a direct path for initial access into corporate environments. By extracting valid API keys or cloud infrastructure credentials from the local AI memory, an attacker can bypass perimeter defenses and pivot directly into the victim's organizational network.

The authoritative resolution for this vulnerability is upgrading the mcp-memory-service package to version 10.25.1 or later. The update introduces strict origin binding for the web framework and patches the data retrieval logic to respect soft-delete database flags. Administrators should deploy this patch immediately using the standard Python package manager.

For environments where immediate patching is not feasible, operators must manually configure the CORS origin policy. This requires modifying the application source code to replace the wildcard array with ["http://localhost", "http://127.0.0.1"]. Operators should also ensure AllowCredentials is disabled if the specific workflow does not demand it.

Local network isolation provides an additional layer of defense. Developers can utilize host-based firewalls (such as iptables, UFW, or Windows Defender Firewall) to ensure the service port rejects connections originating from non-loopback interfaces. While this does not prevent browser-based cross-origin attacks, it hardens the service against direct external network sweeps.

Security monitoring strategies should focus on anomalous endpoint behavior. Endpoint Detection and Response (EDR) solutions can be configured to alert on sustained or unusual HTTP connections originating from web browser executables (chrome.exe, firefox.exe) and terminating at local development ports typically associated with AI service pipelines.