Security Audit: 1 finding(s) in @modelcontextprotocol/server-memory

[starbuck100]

AgentAudit Security Audit Report

Metric	Value
Package	@modelcontextprotocol/server-memory
Version	2026.1.26
Risk Score	5/100
Result	safe
Findings	2 total (0 critical, 0 high, 1 medium, 1 low)

Findings Summary

Medium Severity:

• PATH_TRAV_001: Potential path traversal in custom memory file path (dist/index.js:16)

Low Severity (by-design):

• INFO_LEAK_001: Verbose error messages to stderr (dist/index.js:31) - marked as by-design

Details

Medium: Potential path traversal in custom memory file path

Location: dist/index.js:16
Description: The MEMORY_FILE_PATH environment variable accepts relative paths that are resolved relative to the script directory. While this is user-configured and not externally exploitable, relative paths with '../' sequences could potentially write outside the intended directory. However, this is a configuration-time setting controlled by the user, not runtime input from external sources.

Affected Code:

: path.join(path.dirname(fileURLToPath(import.meta.url)), process.env.MEMORY_FILE_PATH);

Remediation: Consider validating that resolved paths don't escape the intended directory, or require absolute paths only. Alternatively, document that users should use absolute paths for MEMORY_FILE_PATH.

Full Report

View the complete audit report with details, evidence, and remediation guidance:
AgentAudit Report

---

This audit was performed automatically by AgentAudit, the security registry for AI agent packages. If you believe any finding is incorrect, you can dispute it on the platform.

[lucamorettibuilds]

Thanks for the audit! The memory server's path traversal finding is interesting because it highlights a common configuration vs. security trade-off.

On the MEMORY_FILE_PATH path traversal

While this is marked as Medium severity, I'd argue it's closer to Low/Info because:

1. It's a deployment-time configuration (env var), not runtime user input
2. The person setting MEMORY_FILE_PATH typically has filesystem access anyway
3. If an attacker can modify env vars, they have bigger problems (arbitrary code execution)

However, there's a subtle security issue here: What if the memory file is stored in a directory the AI agent has filesystem access to?

Consider this scenario:

• User runs @modelcontextprotocol/server-filesystem with access to /home/user/documents
• User runs @modelcontextprotocol/server-memory with MEMORY_FILE_PATH=/home/user/documents/.memory.json
• Agent now has read/write access to its own memory store via filesystem server
• Agent could manipulate its own memories, delete audit trails, or inject false information

Recommendations

1. Document the separation principle: Memory files should NOT be in directories accessible to other MCP servers, especially filesystem servers
2. Default to a protected location: Use ~/.mcp/memory/ or similar by default, not relative to script location
3. Validate paths at startup: Warn if MEMORY_FILE_PATH resolves to a potentially dangerous location (like /tmp or user home)
4. Consider file permissions: Memory files should be 0600 (owner read/write only)

For users deploying memory servers

Best practices:

• Store memory in a dedicated directory (e.g., ~/.mcp/memory/agent-sessions/)
• Use absolute paths only in MEMORY_FILE_PATH
• Don't give other MCP servers access to the memory directory
• Consider encryption at rest for sensitive memories (PII, credentials, etc.)
• Regularly audit memory files for leaked secrets

That last point is critical: If an agent stores an API key in memory (even temporarily), that's now persisted to disk. Make sure you're not accidentally creating a new attack surface!

For production deployments: Consider using purpose-built memory services with access controls rather than flat files. The memory MCP server is great for development, but production agent workloads should have proper audit trails and access control.

[starbuck100]

Fair point on the severity — the distinction between a local-only server and a networked service matters here. In a purely local context, the risk is indeed closer to Low/Info since the attacker would already need local access. We'll take this feedback into account for future audits of local-only MCP servers.

[olaservo]

The one medium finding is that MEMORY_FILE_PATH is user-configurable, which is by design: it is a deployment-time setting for a local stdio server, and the thread already agreed the severity is closer to informational. Nothing to change. Closing.