CVE-2026-50027

MCP Memory Service Unauthenticated Document API Access (CVE-2026-50027)

Initial Access Collection Impact Last updated:

Detects exploitation of CVE-2026-50027, a missing authentication vulnerability (CWE-306) in mcp-memory-service versions prior to 10.67.1 that allows unauthenticated attackers to read, write, and delete stored memory documents via exposed API endpoints. Successful exploitation grants full unauthenticated access to sensitive memory/document contents, enabling data exfiltration, tampering, or destruction of stored AI agent memory state.

Vulnerability Intelligence

Public PoC

Affected Software

Vendor
pip
Product
mcp-memory-service
Versions
< 10.67.1

Weakness (CWE)

Timeline

Disclosed
July 2, 2026

CVSS

9.8
Critical (9.0–10)
CVSS vector not yet published
Read the write-up →

What is CVE-2026-50027 MCP Memory Service Unauthenticated Document API Access (CVE-2026-50027)?

MCP Memory Service Unauthenticated Document API Access (CVE-2026-50027) (CVE-2026-50027) maps to the Initial Access and Collection and Impact tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for MCP Memory Service Unauthenticated Document API Access (CVE-2026-50027), covering the data sources and telemetry it touches: CommonSecurityLog, W3CIISLog, AzureDiagnostics. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Collection Impact
Microsoft Sentinel / Defender
kusto
let TargetPaths = dynamic(["/api/documents", "/api/memory", "/mcp/documents", "/documents"]);
CommonSecurityLog
| union (W3CIISLog)
| union (AzureDiagnostics | where Category == "ApplicationGatewayAccessLog")
| extend RequestUrl = coalesce(RequestURL, requestUri_s, cs_uri_stem_s)
| where RequestUrl has_any (TargetPaths)
| where HTTPMethod in ("GET", "POST", "PUT", "DELETE") or csMethod_s in ("GET", "POST", "PUT", "DELETE")
| where isempty(Authorization) or Authorization == "-" or isempty(User) or User == "-"
| summarize RequestCount = count(), Methods = make_set(HTTPMethod), Paths = make_set(RequestUrl) by SourceIP = coalesce(SourceIP, cIP_s), bin(TimeGenerated, 5m)
| where RequestCount > 5
| project TimeGenerated, SourceIP, RequestCount, Methods, Paths

Detects unauthenticated HTTP requests to mcp-memory-service document/memory API endpoints from reverse proxy or web server logs ingested into Sentinel, flagging bursts of unauthenticated read/write/delete activity.

critical severity medium confidence

Data Sources

CommonSecurityLog W3CIISLog AzureDiagnostics

Required Tables

CommonSecurityLog W3CIISLog AzureDiagnostics

False Positives

  • Internal health check or monitoring probes hitting the same endpoints without auth headers
  • Load balancer or reverse proxy logs that strip Authorization headers before logging
  • Legitimate service-to-service calls using an authentication mechanism not captured in the logged fields

Sigma rule & cross-platform mapping

The detection logic for MCP Memory Service Unauthenticated Document API Access (CVE-2026-50027) (CVE-2026-50027) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Unauthenticated GET to document API

    Expected signal: HTTP GET request to /api/documents recorded in web/proxy access logs with no Authorization header present.

  2. Test 2Unauthenticated write to memory endpoint

    Expected signal: HTTP POST request to /api/memory recorded in application logs with the injected content and no Authorization header.

  3. Test 3Unauthenticated delete of stored document

    Expected signal: HTTP DELETE request to /api/documents/<id> recorded in access and application logs with no Authorization header, followed by removal of the document from the data store.


Response Playbook

Triage

  1. Identify all source IPs making requests to /api/documents, /api/memory, or equivalent mcp-memory-service endpoints without a valid Authorization header, and correlate against known internal service IPs to rule out benign automation.
  2. Determine the mcp-memory-service version in use via the running container image tag or package manifest; confirm whether the deployed version is < 10.67.1 and therefore vulnerable.
  3. Review the observed HTTP methods (GET/POST/PUT/DELETE) per source IP to distinguish reconnaissance (read-only GET) from active tampering (PUT/DELETE), prioritizing investigation of any DELETE or bulk-write activity.
  4. Check whether the mcp-memory-service instance is internet-facing or reachable from untrusted network segments, as exposure significantly raises exploitation likelihood.

Containment

  1. Immediately restrict network access to the mcp-memory-service API (e.g., firewall rule, security group, or reverse-proxy ACL) to only trusted internal hosts pending patching.
  2. Upgrade mcp-memory-service to version 10.67.1 or later, which enforces authentication on document API endpoints, and redeploy affected instances.
  3. If upgrading is not immediately possible, place an authenticating reverse proxy (requiring API keys or mTLS) in front of the service to compensate for the missing authentication.

Evidence Collection

  1. Preserve web/proxy access logs, application logs, and any available request/response bodies for the affected mcp-memory-service endpoints covering the suspected exploitation window.
  2. Export the current contents and change history (if versioned) of the memory/document store to determine what data was read, modified, or deleted by unauthenticated requests.
  3. Capture container/host configuration, environment variables, and deployment manifests to confirm the exact vulnerable version and exposure configuration at the time of the incident.

Escalation Criteria

  • ! Escalate to incident response if evidence shows successful DELETE or PUT operations against production memory/document data, indicating confirmed data tampering or loss.
  • ! Escalate if the mcp-memory-service instance was internet-facing and processed sensitive data (credentials, PII, proprietary AI agent context), as this constitutes a likely data breach requiring legal/compliance notification.
  • ! Escalate if the same unauthenticated source IP is observed targeting multiple internal services, suggesting broader reconnaissance or lateral movement beyond this single vulnerability.

Investigation Guide

Forensic Artifacts

  • > Web server / reverse proxy access logs showing HTTP requests to document/memory API paths lacking Authorization headers
  • > mcp-memory-service application logs and audit trail entries (if enabled) recording document create/read/update/delete operations
  • > Snapshot or backup diffs of the underlying memory/document data store showing unexpected content changes or deletions

Tuning Guidance

Baseline known internal service accounts, health-check probes, and monitoring tools that legitimately call these endpoints, and add explicit allow-lists or exclusions for their source IPs to reduce noise. If the environment terminates TLS or strips Authorization headers upstream of logging (common with some load balancers), consider tuning detections to instead alert on absence of an internal service identity claim or mTLS certificate rather than relying solely on the Authorization header field. Increase the request-count threshold in high-traffic environments to avoid false positives from legitimate high-volume internal automation.


Hunting Queries

Broad hunt across the last 7-30 days for any unauthenticated traffic to mcp-memory-service document/memory endpoints, to identify historical exploitation attempts predating detection deployment.

Hunting — KQL
kql
CommonSecurityLog
| where RequestURL has_any ("/api/documents", "/api/memory")
| where isempty(Authorization)
| summarize count() by SourceIP, bin(TimeGenerated, 1h)
| order by count_ desc
Hunting — SPL
spl
index=web_proxy uri_path="*documents*" OR uri_path="*memory*" NOT Authorization=*
| stats count by src_ip, _time span=1h
| sort -count

Atomic Red Team Tests

Test 1 Unauthenticated GET to document API
linux

Simulates an attacker performing unauthenticated reconnaissance by reading stored documents from a vulnerable mcp-memory-service instance without providing any Authorization header.

Command

bash
curl -s -X GET http://TARGET_HOST:8000/api/documents

Cleanup

bash
No cleanup required; this is a read-only request against a lab instance.

Expected Telemetry

HTTP GET request to /api/documents recorded in web/proxy access logs with no Authorization header present.

Expected Detection

KQL/SPL/Elastic rules should flag the unauthenticated GET request if it exceeds the volumetric threshold (>5 requests in 5 minutes) or is combined with a subsequent write/delete call.

Test 2 Unauthenticated write to memory endpoint
linux

Simulates an attacker injecting malicious or false memory content into the vulnerable service via an unauthenticated POST request.

Command

bash
curl -s -X POST http://TARGET_HOST:8000/api/memory -H 'Content-Type: application/json' -d '{"content":"atomic-test-injected-memory"}'

Cleanup

bash
curl -s -X DELETE http://TARGET_HOST:8000/api/memory/<returned_id> (remove the injected test memory entry using the ID returned by the POST response, if the lab instance is later patched to require auth for cleanup use an authenticated admin session).

Expected Telemetry

HTTP POST request to /api/memory recorded in application logs with the injected content and no Authorization header.

Expected Detection

Sequence-based Elastic EQL and QRadar AQL rules should flag the unauthenticated write, especially when correlated with a prior unauthenticated GET from the same source IP.

Test 3 Unauthenticated delete of stored document
linux

Simulates an attacker destroying stored memory/document data by issuing an unauthenticated DELETE request against the vulnerable endpoint.

Command

bash
curl -s -X DELETE http://TARGET_HOST:8000/api/documents/<test_doc_id>

Cleanup

bash
Restore the deleted test document from a pre-test backup snapshot of the lab instance's data store.

Expected Telemetry

HTTP DELETE request to /api/documents/<id> recorded in access and application logs with no Authorization header, followed by removal of the document from the data store.

Expected Detection

All seven SIEM rules should flag the unauthenticated DELETE call as high-severity given the destructive HTTP method combined with missing authentication.

Related Detections