Security brief: tenant isolation in agent stacks keeps failing on caller-supplied strings, the MCP git server can be walked out of its repository, and a sanitizer library for MCP trusts home directories

Executive summary

The level stays elevated: nothing here is exploited, but one design error appears in four unrelated products inside a day and deserves a decision, not four tickets. In each of Mem0, LangGraph, an AI gateway component and Coder, the platform decides whose data or credentials to use from a string the caller supplies (a run id, a namespace, a model name, a token audience) and does not check that the string is something the caller is entitled to. Agent platforms are multi-tenant by default, because one memory service, one gateway and one orchestration server usually sit behind many agents and many teams, so these are the bugs that turn a single compromised agent or user into a cross-team data and credential exposure. The second theme is the MCP project’s own fences: the git server’s repository confinement is bypassed by a file the confinement check does not inspect, three days after the filesystem and fetch servers’ path and address checks were reworked.

Vulnerabilities

Item	Severity	Fixed in	Exploited	Notes
MCP git server, nested gitdir confinement bypass (GHSA-w766-5x43-whvw)	Moderate 5.3	mcp-server-git 2026.10.28	No evidence	No CVE yet; needs a way to write a .git file
Mem0 session-scope key collision (CVE-2026-116575)	Moderate 6.3	pip 2.0.18, npm 3.1.6	No evidence	Cross-tenant read and write of recent messages
LangGraph API, JS auth Store bypass (CVE-2026-118668)	High 8.6 (v4)	langgraph-api 0.15.0	No evidence	Only handlers that rewrite namespaces
ai-gateway-payload-processing (CVE-2026-117574)	Critical 9.1	Not stated	No evidence	Other tenant’s API keys injected; unreviewed record
Coder, GCE identity token audience (CVE-2026-118687)	High 8.3 (v4)	2.29.21 to 2.37.4 (by range)	No evidence	Agent session token replay; unreviewed record
n8n Chat Hub restricted tools (CVE-2026-118640)	Moderate 5.3 (v4)	1.123.85, 2.43.5, 2.44.1 (by range)	No evidence	Chat-only role reaches code and workflows
Tabularis describe_table SQL injection (CVE-2026-118378)	High 8.5 (v4)	0.28.0	No evidence	Bypasses read-only mode
mcp-sanitizer URL and path validators (GHSA-4mfg-r38w-w8fg, GHSA-7w82-6f9j-v9jp)	High 8.2 and 7.5	1.4.0	No evidence	No CVE; the control itself is the bug
chrome-devtools-mcp policy enforcement (CVE-2026-106484)	Moderate 4.4	1.5.0 by description	No evidence	Local; unreviewed, versions unclear
LangGraph CLI token in verbose output (CVE-2026-115885)	Moderate 4.1 (v4)	0.4.32	No evidence	Token valid at most 12 hours
LangGraph SDK path injection (CVE-2026-118667)	Moderate 4.3	sdk 0.4.6, langgraph 1.2.14	No evidence	Read-only
vLLM DeepSeek-OCR crash (CVE-2026-115914)	Moderate 6.5	0.32.0	No evidence	One image, default config

MCP and protocol security

The MCP git server: a fence that checks the directory, and a .git file that moves the repository

OfficialCVSS 5.328 Oct

What happened. The modelcontextprotocol/servers repository published GHSA-w766-5x43-whvw on 28 Oct (reporter ShieldPi1, published by maintainer cliffhall): when mcp-server-git runs with --repository <allowed>, a caller can point a tool at a nested directory inside that path whose .git is a file containing a gitdir: line that names a repository outside the allowed root. The version before 2026.10.28 is affected, the release that fixes it is mcp-server-git 2026.10.28 (part of the servers 2.2.0 release the same day), and there is no CVE yet; the reporter asked for one. The reporter demonstrated reading committed files from the outside repository with git_show and creating branches there with git_create_branch, and does not claim arbitrary host-file writes or code execution.

Analysis. The confinement check validates where the working directory is, not what git will do with it. A .git file is git’s own indirection mechanism (it is how linked worktrees and submodules work), so GitPython follows it, and every later tool call operates on a repository the check never saw. That is a time-of-check to time-of-use gap of the same family as the filesystem server’s symlink and parent-directory issues fixed on 25 Oct in the servers 2.1.0 release, which I covered on 27 Oct: the check looks at a path string, the operation follows a pointer. Preconditions are the reporter’s own: the caller must be able to invoke tools on a confined instance, must be able to create a nested directory and a .git file inside the allowed repository, and must know a path to an outside repository the server process can read. The advisory notes that the filesystem server’s write_file is enough for the second condition. That makes the realistic attacker an agent steered by injected content, running with both servers attached, which is the default arrangement in many coding-agent configurations. Blast radius is every repository the server’s user can read: committed history, which often includes secrets that were removed from the working tree but not from history, and branch creation as a foothold for later pushes if credentials are configured. OWASP LLM06 (excessive agency) and Agentic ASI02 (tool misuse) apply; the data at risk is the developer’s source history.

Why it matters. The git server is the reference implementation people copy. The fix is small; the lesson is that “this server is limited to one repository” was a property of the path argument, not of the server. Combined with a writable filesystem server, two individually modest tools compose into a read primitive outside the stated boundary. I read the advisory and the servers release notes; I did not reproduce the chain, and the suggested remediation in the advisory (reject .git file indirection in confined mode, re-validate the resolved repository before each operation, keep legitimate linked worktrees working) is the reporter’s, not a description of the shipped fix, which the release page does not detail.

Mitigation and detection. Upgrade as in the act-now item. Run the git server in a container that mounts only the allowed repository, so a gitdir: pointer to anything else fails with a missing path rather than depending on application checks. Do not attach write-capable file tools and a confined git server to the same agent. Detect: .git entries that are regular files inside a repository you did not expect to contain submodules or worktrees (find <repo> -name .git -type f), and git-server tool calls that report a repository root different from the configured one.

Recommendation (opinion): act this week. Treat path-based confinement in any MCP server as advisory and enforce the boundary with the container or the operating system. Pair the upgrade with a review of which MCP servers each agent is allowed to combine; the risk is in the combinations.

Sources: GHSA-w766-5x43-whvw · modelcontextprotocol/servers releases · PADAWAN 27 Oct brief

mcp-sanitizer: a security filter whose allow-list contains the home directory

OfficialCVSS 8.2 and 7.5Indexed 28 Oct · fix 25 Jun

What happened. Two advisories on the npm package mcp-sanitizer, which presents itself as an input validation layer for MCP servers (maintained by an individual, repository starman69/mcp-sanitizer), were indexed on 28 Oct, both credited to EQSTLab. GHSA-4mfg-r38w-w8fg (High 8.2, CWE-918): the URL validator in validation-utils.js fails to block a localhost URL that has an explicit port, because the check only throws when no port is present, and bracketed IPv6 hosts such as [::1] and [fe80::1] pass because the string comparisons do not match the bracketed form. GHSA-7w82-6f9j-v9jp (High 7.5, CWE-22): validateFilePath allow-lists /home/ and /Users/ as safe absolute prefixes, so /home/alice/.ssh/id_rsa returns blocked=false. Both say versions before 1.4.0 are affected and 1.4.0 fixes them; the npm registry shows 1.4.0 published on 25 Jun and 1.4.1 on 30 Aug, so the advisories arrived four months after the fix. Neither has a CVE.

Analysis. This is a different failure from the usual one. The bug is not in an MCP server; it is in the control a server author adds to protect it. A developer who reads “use mcp-sanitizer to validate URLs and paths” and passes user-controlled values through it gets a blocked=false verdict and treats the result as trusted, and the reporter confirmed exfiltration of simulated SSH keys, cloud credentials and .env files in a container reproduction. The SSRF half is the same protocol-pivoting class I tracked in five MCP servers on 24 Oct, where a deny-list of addresses is incomplete (the official fetch server’s IDNA and NAT64 bypasses on 25 Oct are the same shape). The path half is an allow-list that names a whole class of sensitive locations as safe, a design mistake rather than a parser bug. Preconditions: an application that uses the library as its boundary and passes the sanitized value to a fetch or file operation. Exposure is unknown: I cannot see download counts from the registry endpoint, and the package is not an official MCP project.

Why it matters. Security libraries built around deny-lists of strings fail the way these do, and the failure is silent because the application reports “validated”. The pattern also shows how unreviewed ecosystem tooling gets copied into agent servers because it names the problem.

Mitigation and detection. If npm ls mcp-sanitizer shows anything below 1.4.0, upgrade, and then do not rely on it alone: resolve URLs to addresses at connect time and refuse private, loopback and link-local ranges after DNS resolution (the check belongs at connection, not on the string), and confine file access with a real path canonicalisation against a single root plus an operating-system boundary. Detect: outbound requests from the MCP server process to loopback or metadata addresses, and file reads under home directories that are not your configured data directory.

Recommendation (opinion): replace string filters with boundaries. Use sanitizers for hygiene, never as the only control between a model-supplied value and a fetch or file call.

Sources: GHSA-4mfg-r38w-w8fg · GHSA-7w82-6f9j-v9jp · npm registry entry

Tabularis: a stacked statement beats read-only mode

OfficialCVSS 8.5 (v4)28 Oct

What happened. CVE-2026-118378 (GHSA-v867-6qx2-gwmg, unreviewed GitHub record): Tabularis, a database client that exposes tools to MCP clients, has an SQL injection in its SQLite driver. The describe_table tool places table_name inside a quoted PRAGMA argument; a crafted value closes the quote and appends statements, so an MCP client can read, modify or drop SQLite data, and the record says this bypasses read-only mode and write approval. Fixed in Tabularis 0.28.0 (commit fd1bdbb); upstream advisory GHSA-xrx3-j98v-67x9.

Analysis. The control that fails is the one the product advertises to make agents safe around a database: read-only mode and per-write approval are enforced on the statements the tool intends to run, and the injected statements are not among them. This is the database-tool counterpart to the obsidian-tc refusal bug of 24 Oct, where a declined confirmation still approved. EPSS is low (0.151%) and I have no evidence of exploitation. The vector is rated local with passive user interaction because the client sits on the user’s machine; in practice the attacker is text the agent read.

Why it matters and what to do. A database MCP tool is an agent with a SQL console. Upgrade to 0.28.0; for any database tool, enforce read-only at the database (a read-only role or PRAGMA query_only, an open-read-only connection flag), because a mode implemented in the tool is a mode the tool’s bugs can switch off. Opinion: default to the database’s own permissions for read-only guarantees. Source: GHSA-v867-6qx2-gwmg

Vulnerabilities in agent infrastructure

Identifiers as authority: four cases where the caller’s string chooses the tenant

OfficialCVSS 6.3 to 9.1Update · indexed 28 Oct

What happened. On 28 Oct GitHub indexed advisories for four agent platforms with the same shape, plus two close relatives. Mem0 (CVE-2026-116575, 6.3): _build_session_scope() joins user_id, agent_id and run_id with & and = without escaping, and validation only rejects empty strings, so a caller who controls its own run_id can craft one that yields the same scope key as another tenant, then read that tenant’s recent raw messages and write into or evict their history. It is reachable through Memory.add(), AsyncMemory.add() and the REST POST /memories; the Python package is affected through 2.0.0 (fixed 2.0.18) and the npm package through 3.0.0 (fixed 3.1.6), and the reporter says 2.0.14 and ts-v3.1.2 still contain the join, so check the installed version, not the range. LangGraph API (CVE-2026-118668, 8.6 v4, fixed in langgraph-api 0.15.0, upstream date 28 Sep, reporter coinspect-audits): when JavaScript or TypeScript custom auth changes the requested Store namespace, the server did not apply the change before the Store operation, so a deployment that restricts users by rewriting namespaces enforced nothing; any signed-in user could read, overwrite, search or delete another user’s Store data. Python auth and handlers that reject instead of rewriting are not affected. ai-gateway-payload-processing (CVE-2026-117574, 9.1, unreviewed record, no package, versions or fix listed): an authenticated attacker names another tenant’s model identifier in the request body or a header, the service does not check authorization before fetching credentials from a shared store, and it injects the other tenant’s API keys into the request, so the attacker spends that tenant’s LLM quota and resources. Coder (CVE-2026-118687, 8.3 v4, unreviewed record, fixed by range in 2.29.21, 2.34.12, 2.35.9, 2.36.7 and 2.37.4): the endpoint for Google Compute Engine instance identity does not validate the token’s audience, so an unexpired full-format token minted for a different relying party can be replayed to obtain a workspace agent’s session token, valid until the workspace’s next build.

n8n (CVE-2026-118640, 5.3 v4, unreviewed, fixed by range in 1.123.85, 2.43.5 and 2.44.1) is the same family one level up: users with the global:chatUser role could register restricted tool types through Chat Hub, which per the advisory lets them execute sandboxed code, reach permitted files and use the instance’s workflows, Data Tables and agents. LangGraph SDK (CVE-2026-118667, 4.3, fixed in langgraph-sdk 0.4.6 and langgraph 1.2.14) adds the client-side mirror: the v3 streaming module put thread_id and assistant_id unencoded into request URLs, so attacker-controlled text redirects the authenticated GET to another readable path on the same server (read-only; LangGraph Platform is stated not to be exposed). The Google ADK artifact service (CVE-2026-115522) left app_name out of storage paths in the same way and was in the 28 Oct brief.

Analysis. The root cause in all of them is that an identifier is used as a capability. A scope key, a namespace, a model name and a token audience each answer “whose is this?”, and each was accepted from the party asking. In Mem0 the weakness is delimiter injection: a composite key made by string concatenation, where one tenant’s field can contain the separator and rewrite the meaning of the whole key (the same bug as an unescaped SQL or path join). In LangGraph it is a policy applied in the wrong place: the authorization handler computed the right namespace in the JavaScript runtime and the Python server never received it, an enforcement gap at a language boundary. In the gateway record the credential store is shared and the check is on the caller’s login, not on the right to the named credentials. In Coder it is the classic confused deputy: a valid token presented to a service that is not its audience. Preconditions in every case are a legitimate low-privilege account or, for the memory case, one that can set its own run identifier. That is exactly what an agent platform hands to every team and every embedded agent, and also what a prompt-injected agent effectively holds. Compare the 24 Oct Strands A2A and LangGraph store findings, covered in the 24 Oct brief: the pattern has moved from “agent state shared across tenants” to “tenant chosen by caller string”, which is a design-level problem rather than a few unlucky bugs. OWASP LLM02 (sensitive information disclosure), LLM06 and Agentic ASI03 (identity and privilege abuse) map; MITRE ATLAS credential-access techniques apply to the gateway case.

Why it matters. Agent memory, workflow state and gateway credentials are the data an attacker wants most: raw conversation history that can hold secrets and customer data, and provider API keys with a spending limit. These flaws also defeat the standard assumption in agent platforms that isolation is configured once at the user-and-project level. For the gateway record I cannot say which product or versions are affected: the record names only the component, and a search extract suggests it is an image in Red Hat OpenShift AI, which I could not confirm. Treat the 9.1 as unverified until the vendor says.

Mitigation and detection. Upgrade the fixed versions listed in the table. Structural controls that remove the whole class: derive tenant scope from the authenticated principal on the server and never from request fields; encode composite keys with a collision-free scheme (length prefixes or percent-encoding) and reject separator characters in identifiers; store credentials under the principal that owns them and resolve by (principal, name), not by name; validate token audience at every service that accepts tokens. Test it: create two test tenants and, as one, request the other’s identifiers, model names and namespaces, and assert a denial; add the test to CI for every agent service. Detect: in memory and Store logs, requests whose run_id or namespace contains &, =, . or .. segments; gateway requests that name a model owned by a different tenant than the caller; workspace-agent session tokens issued to instances that did not request them.

Recommendation (opinion): treat tenant isolation as a testable property, this week. Pick the one shared memory, state or gateway service your agents use, write the two-tenant test above, and run it before the vendor patch cycle does it for you. If you cannot enforce isolation in the service, partition by deployment (one instance per tenant) for anything holding credentials or customer conversations.

Sources: GHSA-5324-3w58-qpp2 (Mem0) · GHSA-4hm6-w6qq-w73v (LangGraph API) · GHSA-4c29-j43w-vg8g (gateway component) · GHSA-j9wc-wg7r-6rm3 (Coder) · GHSA-9w9c-v85p-45fq (n8n) · GHSA-3fx2-cqw9-xr3c (LangGraph SDK)

Small items

LangGraph CLI prints a registry push token (CVE-2026-115885, 4.1 v4, fixed in 0.4.32). In langgraph-cli 0.4.15 to 0.4.31, langgraph deploy --verbose echoed the LangSmith-issued registry push token right after the docker login line, because the subprocess helper echoed stdin and the login step inherited --verbose. The token lasts at most 12 hours and is limited to the deployment’s image repository; a holder could pull and push images, but a pushed image runs only if the deployment is updated to its digest, which needs a LangSmith key with access. Upgrade to 0.4.32 (0.4.37 also stops --verbose echoing any command’s input), and if you ran verbose deploys in CI in the last 12 hours, treat that log as holding a live token and restrict who can read it. Source: GHSA-8prr-f582-jqq3

vLLM DeepSeek-OCR crash (CVE-2026-115914, 6.5, fixed in 0.32.0) (Update). An image whose processed pixel tensor sums to exactly zero (the advisory’s example is half black, half white) makes input validation return None, violating an engine assertion that crashes EngineCore and shuts down the API server until restart; DeepSeek-OCR, DeepSeek-OCR-2 and Unlimited-OCR are affected from 0.11.1. The advisory says no authentication is needed although its vector says low privileges; I note the mismatch. This is one more of the crash-on-one-request flaws in the series I tracked on 23, 26 and 27 Oct; 0.32.0 contains it and the earlier fixes, so one upgrade closes the lot. Put request validation and a restart supervisor in front of model servers regardless. Source: GHSA-gq5q-89c7-vhvx

chrome-devtools-mcp (CVE-2026-106484, 4.4). An unreviewed record with Chromium’s own Medium rating: insufficient policy enforcement allows a local attacker to read and write through a malicious file, with user interaction. The description says “prior to 1.5.0” but the advisory’s affected and fixed fields read Unknown and no package is listed, so I cannot give a reliable version check; a browser-control MCP server is worth upgrading to its latest release regardless, since it holds a debugging session on your logged-in browser. Source: GHSA-2mw5-2f2c-v2g3

WordPress AI plugins (by title only, not opened). GitHub also indexed unreviewed records on 28 and 29 Oct for the AI Engine plugin (described as chatbot, AI framework and MCP for WordPress, GHSA-xfc5-7gqh-v42g, Moderate), two Royal MCP plugin permission checks (GHSA-334j-cwwv-qmmh, GHSA-94r9-pgqm-7rh9, Moderate and Low; an earlier Royal MCP issue was in the 23 Oct brief), and several AI chatbot plugins including a file-upload validation record. If you run an MCP-enabled WordPress site, update plugins; I did not read these records and give no details. Source: unreviewed advisories list

Incidents and threat intelligence

Aoki infostealer collects AI coding tool credentials (late find, early-tagged)

EarlyLate find · first published 15 Oct

What happened. Per search-result extracts from several outlets (Infosecurity Magazine, SC World and others; none of their pages opened from this environment), Symantec reported on 15 Oct that newer variants of the Aoki infostealer search for AI coding tool files: .claude.json, Claude desktop and ChatGPT cookies, the Codex config.toml and .env files, and tokens for GitHub Copilot, Cursor, Gemini, JetBrains AI Assistant, Kiro and AWS. A secondary outlet lists more specific paths such as ~/.claude/.credentials.json and ~/.codex/auth.json; one aggregator attributes a similar analysis to Check Point instead, so the attribution is inconsistent across the extracts. No threat group is named, and the extracts describe harvesting from compromised endpoints, not a breach of the AI providers.

Analysis and why it matters. Unconfirmed beyond the extracts: variant details, victim counts, file paths. What the extracts agree on is the direction: commodity stealers now treat agent configuration and session tokens as high-value loot, because those hold long-lived credentials with reach into repositories, cloud accounts and CI. That is consistent with the Python-startup stealer in the poisoned LiteLLM build I covered on 23 Oct, which also went for agent and provider keys. A stolen coding-agent token is a stolen developer identity with the developer’s tool permissions and API budget.

Mitigation and detection. Prefer short-lived, device-bound sessions for coding agents over long-lived keys in files; keep agent config directories out of backups and sync; restrict who may read those files with endpoint policy; alert on unusual processes reading ~/.claude, ~/.codex and similar directories; rotate tokens after any infostealer detection on a developer machine.

Recommendation (opinion): watch, and fold agent credential files into your infostealer playbook. Do not change controls on this report alone; when Symantec’s page is readable, confirm the file list and variant.

Sources: Search extract: Infosecurity Magazine (not opened)

Research and policy

Nothing new in the window passed the inclusion test. I found no new OWASP, NIST, CISA, ENISA or INCIBE agent-security publication dated 28 or 29 Oct, and arXiv and the news and vendor research sites do not resolve from this environment, so I cannot rule out research published in the window. I report none.