## Summary The HTTP MCP JSON-RPC endpoint at `/mcp` requires only OAuth `read` scope for all requests, then dispatches `tools/call` directly to handlers that include mutating tools. A read-only OAuth client can call `store_memory` and `delete_memory` through MCP even though the corresponding REST endpoints require `write` scope. ## Technical Details `src/mcp_memory_service/web/api/mcp.py` declares `mcp_endpoint` with `user: AuthenticationResult = Depends(require_read_access)`. For `tools/call`, it extracts the requested tool name and arguments, then calls `handle_tool_call(storage, tool_name, arguments)` without passing the authenticated user or checking a per-tool required scope. The MCP tool registry includes both read tools and write tools. In the same handler file, `store_memory` creates a `Memory` object and calls `storage.store(...)`, while `delete_memory` calls `storage.delete(content_hash)`. These operations are reachable with only the `read` scope. The REST endpoint demonstrates the intended boundary: `POST /api/memories` uses `Depends(require_write_access)` and rejects a read-only token with 403 `insufficient_scope`. ## Reproduction 1. Enable OAuth and disable anonymous access. 2. Generate a valid OAuth JWT with only `scope: read`. 3. Confirm the REST write endpoint rejects it: ```http POST /api/memories Authorization: Bearer <read-only-token> Content-Type: application/json {"content":"rest denied control"} ``` Expected and observed: HTTP 403 with `Required scope 'write' not granted`. 4. Send the same read-only token to the MCP endpoint: ```http POST /mcp Authorization: Bearer <read-only-token> Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "store_memory", "arguments": { "content": "mcp read scope stored this", "tags": ["poc"] } } } ``` Observed: HTTP 200 JSON-RPC success and the storage `store` sink is reached. 5. A read-only token can also call `delete_memory` through MCP if it knows a content hash: ```http POST /mcp Authorization: Bearer <read-only-token> Content-Type: application/json { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "delete_memory", "arguments": {"content_hash": "<known_hash>"} } } ``` Observed: HTTP 200 JSON-RPC success and the storage `delete` sink is reached. ## Impact A client intended to be read-only can inject or delete memories through the MCP API. This can corrupt the memory database, influence future agent context, and destroy stored user memories without the OAuth `write` scope required by the REST API. ## Affected Versions Confirmed present on current main commit `c99a922477df41f75a44db11182ae48a57311910` and latest release tag `v10.65.0` (`4eb4a62665589f9dd9f8c393afa32de434b4098a`). ## Suggested Fix Enforce authorization per MCP tool at `tools/call` time. Require `write` for `store_memory` and `delete_memory`, keep `read` only for read-only tools, and add regression tests proving direct `tools/call` to mutating tools is rejected before the handler reaches storage when the caller has only `read` scope.
## Summary The HTTP MCP JSON-RPC endpoint at `/mcp` requires only OAuth `read` scope for all requests, then dispatches `tools/call` directly to handlers that include mutating tools. A read-only OAuth client can call `store_memory` and `delete_memory` through MCP even though the corresponding REST endpoints require `write` scope. ## Technical Details `src/mcp_memory_service/web/api/mcp.py` declares `mcp_endpoint` with `user: AuthenticationResult = Depends(require_read_access)`. For `tools/call`, it extracts the requested tool name and arguments, then calls `handle_tool_call(storage, tool_name, arguments)` without passing the authenticated user or checking a per-tool required scope. The MCP tool registry includes both read tools and write tools. In the same handler file, `store_memory` creates a `Memory` object and calls `storage.store(...)`, while `delete_memory` calls `storage.delete(content_hash)`. These operations are reachable with only the `read` scope. The REST endpoint demonstrates the intended boundary: `POST /api/memories` uses `Depends(require_write_access)` and rejects a read-only token with 403 `insufficient_scope`. ## Reproduction 1. Enable OAuth and disable anonymous access. 2. Generate a valid OAuth JWT with only `scope: read`. 3. Confirm the REST write endpoint rejects it: ```http POST /api/memories Authorization: Bearer <read-only-token> Content-Type: application/json {"content":"rest denied control"} ``` Expected and observed: HTTP 403 with `Required scope 'write' not granted`. 4. Send the same read-only token to the MCP endpoint: ```http POST /mcp Authorization: Bearer <read-only-token> Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "store_memory", "arguments": { "content": "mcp read scope stored this", "tags": ["poc"] } } } ``` Observed: HTTP 200 JSON-RPC success and the storage `store` sink is reached. 5. A read-only token can also call `delete_memory` through MCP if it knows a content hash: ```http POST /mcp Authorization: Bearer <read-only-token> Content-Type: application/json { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "delete_memory", "arguments": {"content_hash": "<known_hash>"} } } ``` Observed: HTTP 200 JSON-RPC success and the storage `delete` sink is reached. ## Impact A client intended to be read-only can inject or delete memories through the MCP API. This can corrupt the memory database, influence future agent context, and destroy stored user memories without the OAuth `write` scope required by the REST API. ## Affected Versions Confirmed present on current main commit `c99a922477df41f75a44db11182ae48a57311910` and latest release tag `v10.65.0` (`4eb4a62665589f9dd9f8c393afa32de434b4098a`). ## Suggested Fix Enforce authorization per MCP tool at `tools/call` time. Require `write` for `store_memory` and `delete_memory`, keep `read` only for read-only tools, and add regression tests proving direct `tools/call` to mutating tools is rejected before the handler reaches storage when the caller has only `read` scope.
Update mcp-memory-service to 10.65.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanmcp-memory-service: OAuth read-only clients can write and delete memories through MCP tools/call affects mcp-memory-service (pip). Severity is high. ## Summary The HTTP MCP JSON-RPC endpoint at `/mcp` requires only OAuth `read` scope for all requests, then dispatches `tools/call` directly to handlers that include mutating tools. A read-only OAuth client can call `store_memory` and `delete_memory` through MCP even though the corresponding REST endpoints require `write` scope. ## Technical Details `src/mcp_memory_service/web/api/mcp.py` declares `mcp_endpoint` with `user: AuthenticationResult = Depends(require_read_access)`. For `tools/call`, it extracts the requested tool name and arguments, then calls `handle_tool_call(storage, tool_name, arguments)` without passing the authenticated user or checking a per-tool required scope. The MCP tool registry includes both read tools and write tools. In the same handler file, `store_memory` creates a `Memory` object and calls `storage.store(...)`, while `delete_memory` calls `storage.delete(content_hash)`. These operations are reachable with only the `read` scope. The REST endpoint demonstrates the intended boundary: `POST /api/memories` uses `Depends(require_write_access)` and rejects a read-only token with 403 `insufficient_scope`. ## Reproduction 1. Enable OAuth and disable anonymous access. 2. Generate a valid OAuth JWT with only `scope: read`. 3. Confirm the REST write endpoint rejects it: ```http POST /api/memories Authorization: Bearer <read-only-token> Content-Type: application/json {"content":"rest denied control"} ``` Expected and observed: HTTP 403 with `Required scope 'write' not granted`. 4. Send the same read-only token to the MCP endpoint: ```http POST /mcp Authorization: Bearer <read-only-token> Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "store_memory", "arguments": { "content": "mcp read scope stored this", "tags": ["poc"] } } } ``` Observed: HTTP 200 JSON-RPC success and the storage `store` sink is reached. 5. A read-only token can also call `delete_memory` through MCP if it knows a content hash: ```http POST /mcp Authorization: Bearer <read-only-token> Content-Type: application/json { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "delete_memory", "arguments": {"content_hash": "<known_hash>"} } } ``` Observed: HTTP 200 JSON-RPC success and the storage `delete` sink is reached. ## Impact A client intended to be read-only can inject or delete memories through the MCP API. This can corrupt the memory database, influence future agent context, and destroy stored user memories without the OAuth `write` scope required by the REST API. ## Affected Versions Confirmed present on current main commit `c99a922477df41f75a44db11182ae48a57311910` and latest release tag `v10.65.0` (`4eb4a62665589f9dd9f8c393afa32de434b4098a`). ## Suggested Fix Enforce authorization per MCP tool at `tools/call` time. Require `write` for `store_memory` and `delete_memory`, keep `read` only for read-only tools, and add regression tests proving direct `tools/call` to mutating tools is rejected before the handler reaches storage when the caller has only `read` scope.
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| mcp-memory-servicepip | <=10.65.1 | 10.65.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate mcp-memory-service to 10.65.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanmcp-memory-service: OAuth read-only clients can write and delete memories through MCP tools/call affects mcp-memory-service (pip). Severity is high. ## Summary The HTTP MCP JSON-RPC endpoint at `/mcp` requires only OAuth `read` scope for all requests, then dispatches `tools/call` directly to handlers that include mutating tools. A read-only OAuth client can call `store_memory` and `delete_memory` through MCP even though the corresponding REST endpoints require `write` scope. ## Technical Details `src/mcp_memory_service/web/api/mcp.py` declares `mcp_endpoint` with `user: AuthenticationResult = Depends(require_read_access)`. For `tools/call`, it extracts the requested tool name and arguments, then calls `handle_tool_call(storage, tool_name, arguments)` without passing the authenticated user or checking a per-tool required scope. The MCP tool registry includes both read tools and write tools. In the same handler file, `store_memory` creates a `Memory` object and calls `storage.store(...)`, while `delete_memory` calls `storage.delete(content_hash)`. These operations are reachable with only the `read` scope. The REST endpoint demonstrates the intended boundary: `POST /api/memories` uses `Depends(require_write_access)` and rejects a read-only token with 403 `insufficient_scope`. ## Reproduction 1. Enable OAuth and disable anonymous access. 2. Generate a valid OAuth JWT with only `scope: read`. 3. Confirm the REST write endpoint rejects it: ```http POST /api/memories Authorization: Bearer <read-only-token> Content-Type: application/json {"content":"rest denied control"} ``` Expected and observed: HTTP 403 with `Required scope 'write' not granted`. 4. Send the same read-only token to the MCP endpoint: ```http POST /mcp Authorization: Bearer <read-only-token> Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "store_memory", "arguments": { "content": "mcp read scope stored this", "tags": ["poc"] } } } ``` Observed: HTTP 200 JSON-RPC success and the storage `store` sink is reached. 5. A read-only token can also call `delete_memory` through MCP if it knows a content hash: ```http POST /mcp Authorization: Bearer <read-only-token> Content-Type: application/json { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "delete_memory", "arguments": {"content_hash": "<known_hash>"} } } ``` Observed: HTTP 200 JSON-RPC success and the storage `delete` sink is reached. ## Impact A client intended to be read-only can inject or delete memories through the MCP API. This can corrupt the memory database, influence future agent context, and destroy stored user memories without the OAuth `write` scope required by the REST API. ## Affected Versions Confirmed present on current main commit `c99a922477df41f75a44db11182ae48a57311910` and latest release tag `v10.65.0` (`4eb4a62665589f9dd9f8c393afa32de434b4098a`). ## Suggested Fix Enforce authorization per MCP tool at `tools/call` time. Require `write` for `store_memory` and `delete_memory`, keep `read` only for read-only tools, and add regression tests proving direct `tools/call` to mutating tools is rejected before the handler reaches storage when the caller has only `read` scope.
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| mcp-memory-servicepip | <=10.65.1 | 10.65.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard