CVE-2026-50027 Elastic Security · Elastic

Detect MCP Memory Service Unauthenticated Document API Access (CVE-2026-50027) in Elastic Security

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.

MITRE ATT&CK

Tactic
Initial Access Collection Impact

Elastic Detection Query

Elastic Security (Elastic)
eql 
sequence by source.ip with maxspan=5m
  [network where url.path : ("/api/documents", "/api/memory", "/documents") and http.request.method : ("GET","POST","PUT","DELETE") and (http.request.headers.authorization == null or http.request.headers.authorization : "")]
  [network where url.path : ("/api/documents", "/api/memory", "/documents") and http.request.method : ("DELETE","PUT")]
critical severity medium confidence

Sequences unauthenticated requests to mcp-memory-service document endpoints followed by a mutating (PUT/DELETE) call from the same source, indicating likely exploitation of the missing authentication flaw.

Data Sources

httpnetwork

Required Tables

logs-*filebeat-*

False Positives & Tuning

  • Internal automation scripts that legitimately call the API without forwarding auth headers due to network-level trust zones
  • Proxy re-writes that strip Authorization headers before events reach Elastic
  • Duplicate log shipping causing repeated benign hits within the sequence window

Other platforms for CVE-2026-50027

Microsoft Sentinel (KQL) Splunk (SPL) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: 2026-08-01 Research depth: standard
References (2)

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

Related Techniques

[object Object][object Object][object Object]

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

Tactic Hubs

TA0001Initial AccessTA0009CollectionTA0040Impact

Related Techniques

T1190Exploit Public-Facing ApplicationT1213Data from Information RepositoriesT1485Data Destruction

Same Tactic: Initial Access

Popular Detections