CVE-2026-33010: mcp-memory-service Cross-Origin Memory Theft - What It Means for Your Business and How to Respond

Introduction

CVE-2026-33010 matters because it can expose sensitive business data through a web browser, even when users do not intend to share it. If your organization uses mcp-memory-service in production, or if it supports AI workflows that depend on shared memory storage, this issue can put confidential information, workflow integrity, and trust at risk. This post explains why the vulnerability matters to your organization, what it means operationally, and how to respond with urgency and discipline. It is written for business leaders first, with technical guidance in the appendix for security and IT teams.

S1 — Background & History

CVE-2026-33010 was disclosed in March 2026 and affects doobidoo mcp-memory-service, an open-source memory backend used in multi-agent and AI-adjacent environments. The weakness is a permissive cross-domain policy, commonly called a CORS issue, which allows untrusted websites to interact with the service in ways that should not be permitted. Public summaries identify the flaw as critical or high severity, with a CVSS score reported around 9.1 in one source and a very high impact profile in others. The key remediation milestone is version 10.25.1, which is identified as the fixed release.

Early reporting indicates that the issue becomes especially dangerous when the HTTP server is enabled and anonymous access is allowed. In that configuration, a malicious website can potentially read, modify, or delete stored memory data after a user visits the site while using the service. The timeline is straightforward: the issue was publicly described in mid to late March 2026, the affected versions were identified as anything before 10.25.1, and the recommended response was immediate upgrade or temporary shutdown of the exposed HTTP feature.

S2 — What This Means for Your Business

For your business, this is not just a software defect. It is a pathway for unauthorized access to sensitive records, corrupted data, broken workflows, and downstream business decisions based on unreliable information. If your teams use stored memory for AI assistants, customer support workflows, internal automation, or task continuity, an attacker may be able to interfere with the knowledge those systems rely on.

The operational risk is broad. A compromised memory store can disrupt service delivery, force manual review, and create expensive recovery work for IT and security teams. The reputational risk is also real, because customers and partners expect your organization to control how data moves through modern AI tools and browser-based interfaces.

Compliance exposure can follow quickly if the affected memory store contains personal information, client data, employee records, or regulated business content. Even if the data is not directly exfiltrated in a classic breach, unauthorized modification or deletion can still trigger legal, contractual, and audit issues. For U.S. and Canadian organizations, the business question is simple: can you prove that untrusted websites cannot influence sensitive internal systems? If the answer is uncertain, the risk deserves immediate attention.

S3 — Real-World Examples

Regional bank: A regional bank uses mcp-memory-service to retain context for internal AI assistants that help staff answer operational questions. If a staff member visits a malicious website while the service is active, stored instructions or references could be altered, causing misinformation, poor internal decisions, or a need to rebuild trusted memory data.

Healthcare provider: A healthcare provider uses shared memory to support scheduling, intake, or administrative automation. If that memory store is modified or wiped, staff may lose reliable context for patient-facing workflows, leading to delays, manual work, and possible privacy review obligations.

Mid-sized SaaS company: A SaaS company uses the service to preserve context across customer support automation. A cross-origin attack could corrupt ticket-handling memory, causing repetitive errors, incorrect responses, and a drop in customer confidence during a sensitive support interaction.

Small professional services firm: A smaller firm may assume it is too small to matter, but browser-based exploitation does not require a large target footprint. If the service is exposed through a dashboard and anonymous access is enabled, a single compromised endpoint can still create costly cleanup and client trust issues.

S4 — Am I Affected?

• You are affected if you run doobidoo mcp-memory-service version 10.25.0 or earlier.

• You are affected if the HTTP server is enabled through MCP_HTTP_ENABLED=true.

• You are affected if anonymous access is enabled through MCP_ALLOW_ANONYMOUS_ACCESS=true.

• You are affected if you rely on wildcard cross-origin settings for trusted browser access.

• You are at higher risk if users access the service from normal browsers rather than isolated admin tooling.

• You are especially exposed if stored memories contain sensitive business, customer, or regulated data.

Key Takeaways

• CVE-2026-33010 can let an untrusted website interact with mcp-memory-service in ways that threaten data confidentiality and integrity.

• The main business risks are operational disruption, loss of trust, and possible compliance exposure.

• Organizations running affected versions should treat version 10.25.1 as the priority fix.

• Temporary safeguards matter when patching is not immediate, especially disabling the HTTP server and anonymous access.

• If your AI or automation stack depends on shared memory, this issue can affect more than one application at once.

Call to Action

If your organization uses mcp-memory-service or any browser-accessible AI support layer, now is the time to validate exposure and harden the path into production. IntegSec can help you identify where the weakness exists, test how far an attacker could reach, and reduce cyber risk before it becomes an operational problem. Contact IntegSec for a pentest and deeper cybersecurity risk reduction at 

https://integsec.com

A — Technical Analysis

The root cause is permissive CORS configuration in mcp-memory-service before 10.25.1. Public descriptions indicate FastAPI CORSMiddleware was configured with wildcard origins alongside credentials support, which is unsafe because it can allow untrusted websites to read authenticated responses cross-origin. The attack vector is network-based through a browser, with low complexity, no elevated privileges, and user interaction required because the victim must visit a malicious site while the service is reachable. Public references map the issue to CWE-942, permissive cross-domain policy with untrusted domains, and one source notes the NVD as the original reference point.

B — Detection & Verification

1. Confirm installed version with package or container metadata, then compare it to 10.25.1.

2. Review runtime configuration for MCP_HTTP_ENABLED=true and MCP_ALLOW_ANONYMOUS_ACCESS=true.

3. Inspect API logs for cross-origin requests from unfamiliar browser origins or unusual repeated reads and writes.

4. Look for user-agent patterns associated with normal browser traffic making administrative or memory-modifying requests.

5. Watch for suspicious spikes in memory retrieval, update, or deletion activity that does not match user behavior.

6. Network indicators include browser-origin requests reaching the service from domains that should not have access.

C — Mitigation & Remediation

• Immediate (0–24h): Upgrade mcp-memory-service to 10.25.1 or later as the first action.

• Short-term (1–7d): If patching cannot happen immediately, disable the HTTP server with MCP_HTTP_ENABLED=false, disable anonymous access with MCP_ALLOW_ANONYMOUS_ACCESS=false, and restrict CORS to trusted domains only.

• Long-term (ongoing): Enforce authenticated access, remove wildcard CORS patterns, review logs regularly, and test browser-exposed admin paths as part of routine security validation.

• If the environment cannot patch right away, isolate the service from public access, place it behind strong authentication, and limit which internal systems can reach it. Review stored memory for unauthorized changes, then restore from trusted backups if integrity is in doubt.

D — Best Practices

• Treat wildcard CORS as a design flaw, not a convenience feature, when credentials are involved.

• Keep browser-accessible admin and data services behind authentication and network restrictions.

• Segment AI memory stores from general user browsing environments.

• Monitor for unexpected cross-origin activity and abnormal write operations.

• Test your configuration after every upgrade so a secure setting does not regress into an exposed one.