Security brief: the MCP project's own reference servers get eight fixes, agent control planes keep shipping with no login, and ten more vLLM crash bugs
The Model Context Protocol project shipped a security release of its reference servers (filesystem, fetch, everything) on 25 Oct that fixes eight advisories, and date-versioned npm installs will not be offered it automatically. Separately, OpenHands, Archon, DB-GPT and Letta all have advisories where the agent's control interface is open to anyone who can reach it.
Covers Mon 26 Oct 08:00 CET to Tue 27 Oct 08:00 CET
Tuesday window, with a heavy load of items published on the weekend that no earlier PADAWAN report covered (the 26 Oct brief stopped at Monday 08:00). I counted those as in scope and tagged the older ones as late finds. Roughly 40 searches and page fetches. Most news sites and CVE hosts (NVD, CISA, OSV, VulnCheck, Elastic, The Hacker News, Corgea) do not resolve from this environment, so everything below rests on GitHub advisory and release pages, the npm and PyPI registries, and search-result extracts; where a claim rests only on an extract I say so. No new confirmed exploitation of agentic software and no agentic CISA KEV entry found. The ledger and source registry that AGENT.md v2 describes are still not in the repository, so I kept the two legacy report types the build accepts. Ecosystem and release developments are in the [daily signal](/reports/2026-10-27-daily-signal/). I could not verify any new model release in the window and report none.
Act now
- Upgrade the MCP reference servers: server-filesystem and server-everything to 2.0.1, mcp-server-fetch to 2026.10.24 npm: run `npm ls @modelcontextprotocol/server-filesystem @modelcontextprotocol/server-everything` in every repo and agent image. If the version is a date (2025.x or 2026.x) or a lock file pins it, Dependabot and `npm update` will not offer 2.0.1, so run `npm install @modelcontextprotocol/server-filesystem@2.0.1` explicitly. pip: `mcp-server-fetch` 2026.10.10 to 2026.10.19 has the SSRF guard bypass; install 2026.10.24. Do not run server-everything over HTTP or SSE below 2.0.1 on a machine with real secrets in its environment.
- Find agent control interfaces that are reachable without a login, and take them off the network Check any host that runs OpenHands (SDK before 1.52.0, DockerWorkspace or Apptainer), Archon 0.2.13 to 0.11.1, DB-GPT 0.8.2 and earlier, or Letta up to 0.16.8: list listening ports (`ss -ltnp`) and confirm the agent API is bound to loopback or sits behind an authenticating reverse proxy. Archon, DB-GPT and Letta have no fixed version, so isolate them or remove them until the vendor ships one.
In brief
- MCP reference servers: v2.1.0 of modelcontextprotocol/servers, 25 Oct, fixes eight advisories. server-everything let any web page read every environment variable of a locally running HTTP server; server-filesystem has three path-check bypasses; mcp-server-fetch has an IDNA SSRF-guard bypass. Upgrade to server-filesystem and server-everything 2.0.1 and mcp-server-fetch 2026.10.24, and install the npm ones explicitly if you pinned a date version.
- OpenHands Software Agent SDK (CVE-2026-112346, CVSS 9.3, fixed 1.52.0): DockerWorkspace published its agent server on every host interface with authentication off, so a reachable port meant root in the sandbox and the secrets store. The CVE came three weeks after the 5 Oct fix. Late finds with the same shape and no fix: Archon (CVE-2026-111322, 9.3), DB-GPT (CVE-2026-77932, 9.3) and Letta (CVE-2026-77937, 8.6).
- vLLM (Update): ten advisories dated 25 Oct (CVE-2026-116172 to 116181), all denial of service or SSRF, with fixes between 0.24.0 and 0.31.0. 0.32.0 (18 Oct) contains every fix and also stops allowing all CORS origins by default.
- npm campaign (late find, early-tagged): packages from a fake 'Web3 accelerator' reportedly repackage an open-source coding agent so it sends model traffic to the attacker, registers the attacker's MCP server and defaults tool approval to 'yolo'. I confirmed the package and its version history on the npm registry but not the malicious content.
- Small items: llama.cpp PLaMo2 tokenizer heap write (b10261), smg JPEG allocation (1.11.0), FastMCP post-transform authorization skip (3.4.10 and 4.1.2), and four no-fix products (iFlytek astron-agent, CreditNirvana call-centre agent, agent-teams-ai, Letta).
Executive summary
The level stays elevated. There is no live campaign against agentic software in this window, but two things deserve a decision this week. First, the MCP project’s own reference servers, the code many teams copied into their agents as a starting point, shipped a security release that most automated tooling will not pick up, because the package switched from date versions to semantic versions. Second, four unrelated agent platforms show the same design error: the interface that tells a coding agent what to do has no login, and the agent behind it already holds a shell. That is the controls pattern from the last two weeks (Storybook, Trigger.dev, ADK, obsidian-tc) one layer down, from the browser tab to the network.
Vulnerabilities
| Item | Severity | Fixed in | Exploited | Notes |
|---|---|---|---|---|
| MCP reference servers: server-everything cross-origin env read | Moderate 6.5 | 2.0.1 | No evidence | No CVE; HTTP/SSE transports only |
| MCP reference servers: server-filesystem (4 advisories) | Low to Moderate | 2.0.1 | No evidence | Case-variant symlink bypass, quote/space path bypass, TOCTOU, metadata leak |
| MCP reference servers: mcp-server-fetch (4 advisories) | Low to Moderate | 2026.10.24 | No evidence | IDNA SSRF-guard bypass, NAT64, robots.txt on redirects |
| OpenHands Software Agent SDK (CVE-2026-112346) | Critical 9.3 | 1.52.0 | No evidence | Unauthenticated root shell in the sandbox if the port is reachable |
| Archon (CVE-2026-111322) | Critical 9.3 | None referenced | No evidence | Late find. Control API open, agent runs with bypassPermissions |
| DB-GPT (CVE-2026-77932) | Critical 9.3 | None referenced | No evidence | Late find. Every caller is admin; unsandboxed code and shell tools |
| Letta (CVE-2026-77937) | High 8.6 | None referenced | No evidence | Late find. user_id header is trusted |
| vLLM, ten advisories (CVE-2026-116172 to 116181) | High 7.1 to 8.8 | 0.24.0 to 0.31.0 | No evidence | Denial of service, one SSRF |
| llama.cpp PLaMo2 tokenizer (CVE-2026-116816) | High 8.5 | b10261 | No evidence | Crafted model file |
| FastMCP authorization after transforms (GHSA-7xgj-8392-5q4r) | Moderate 6.8 | 3.4.10, 4.1.2 | No evidence | No CVE |
The MCP reference servers: eight fixes, and an upgrade path that skips you
What happened. On 25 Oct the modelcontextprotocol/servers repository released v2.1.0 with eight advisories across three servers. The npm packages @modelcontextprotocol/server-filesystem and @modelcontextprotocol/server-everything are fixed in 2.0.1, and the Python package mcp-server-fetch in 2026.10.24. None has a CVE yet. I read the advisories (GHSA-mvf5-2qqv-rg3c, GHSA-4gxg-m5jx-9j57, GHSA-7rgq-gccq-qphx, GHSA-53mr-w429-c597, GHSA-hhwq-wxfx-cj7g, GHSA-v38p-wf49-hx2j, GHSA-66qx-2266-pmj6, GHSA-3jqg-r5pp-rmp2), the release notes, and the npm and PyPI registry entries, which confirm 2.0.1 and 2026.10.24 were published at 00:05 UTC on 25 Oct.
Analysis. These are small bugs in code that is meant to be an example, and that is exactly why they matter: the reference servers are copied, wrapped and vendored into agents, so every product that copied them inherited the flaw and never saw the advisory. Entry point in all cases is a tool argument the model chooses, which an attacker can steer by putting instructions in content the model reads (OWASP LLM01 prompt injection, and Agentic ASI02 tool misuse). Three mechanisms stand out.
- server-everything (6.5). With the SSE or Streamable HTTP transport it sent
Access-Control-Allow-Origin: *, bound to every interface, had no authentication, and itsget-envtool returns the whole process environment. A web page open in the developer’s browser can complete the handshake cross-origin and callget-env; the reporter got 47 variables back. The default stdio transport is not exposed. This is the browser-to-localhost pattern again (Storybook, ADK, obsidian-tc), in the project that defines the protocol. - server-filesystem (three path-check bypasses). The check and the use disagree about what the path is. A trailing quote or whitespace is stripped for the allow-list check but not for the file operation, so
/allowed/proj'passes as/allowed/projand acts on a sibling outside the root (all 14 tools). A case variant of a symlink name slips past the symlink check on case-insensitive file systems (macOS, Windows) and the write follows the link out of the root. A parent-directory fallback leaves a race between check and write. The Windows fix is described as partial. Same check-versus-use class as the Nginx UI and mcp-atlassian cases of 19 Oct. - mcp-server-fetch (IDNA). The new private-address guard (added in 2026.10.10) resolves the Unicode form of a host name while httpx connects to the punycode form; the two can resolve differently (
ßbecomesssunder one standard), so an attacker who owns a domain gets a public address past the check and an internal one at connect time, and the response is returned to the model. That reaches loopback and cloud metadata. A second advisory covers the NAT64 prefix64:ff9b::/96, treated as public although it embeds an IPv4 address; a third, robots.txt not being rechecked after redirects. Comparable to the five-server SSRF family I covered on 24 Oct.
The release-engineering detail is the part most teams will miss. The npm packages moved from date versions (2025.x, 2026.x) to 1.0.0 on 11 Oct and 2.0.x after that, and a semantic version compares lower than a date, so range-based updates, npm outdated and Dependabot do not offer 2.0.1 to anyone on a date version. The registry’s latest tag does point to 2.0.1, so a fresh npm install is fine; a pinned or locked project is not. I did not test Dependabot; the advisories say it will not open a pull request.
Why it matters. The advisories are low and moderate, and I do not expect incidents from them on their own. The reason to act is that the filesystem server is the default ‘give the agent access to a folder’ building block, and its path boundary is the security control in the design. A boundary that fails on a quote character is not a boundary when the model’s input is untrusted.
Mitigation and detection. Upgrade as in the act-now item. Run the filesystem server in a container that mounts only the directory it needs, so a bypass reaches nothing else, and do not allow symlinks inside the mounted root. Keep fetch servers off networks that can reach metadata endpoints, and block 169.254.169.254 and NAT64 ranges at the egress. Search egress logs for fetches to hosts that resolve to private ranges. If you ran server-everything over HTTP, treat the environment of that process as exposed and rotate its secrets.
Recommendation (opinion): act today. Inventory every place you copied or pinned a reference server, upgrade by hand, and add a check to CI that fails when a dependency’s latest dist-tag is higher than the lock file by a major version, so a versioning-scheme change cannot hide a security release again.
Sources: servers v2.1.0 release · server-everything GHSA-mvf5-2qqv-rg3c · server-filesystem GHSA-7rgq-gccq-qphx · GHSA-4gxg-m5jx-9j57 · GHSA-53mr-w429-c597 · fetch GHSA-v38p-wf49-hx2j · GHSA-3jqg-r5pp-rmp2 · npm: server-filesystem
Agent control planes with no login: OpenHands, Archon, DB-GPT and Letta
What happened. On 26 Oct GitHub’s advisory database added CVE-2026-112346: the OpenHands Software Agent SDK’s DockerWorkspace and Apptainer workspace launchers bound the sandbox agent server to all interfaces and started it with an empty session-key list, which disables authentication. Anyone who could reach the published port could run shell commands as root in the sandbox, read the mounted workspace and read the stored secrets (CVSS 4.0: 9.3, unreviewed). The fix is in v1.52.0, released 5 Oct; the CVE record was assigned three weeks later. Looking for the same shape I found three more that PADAWAN had not covered, each with a VulnCheck advisory as a reference: Archon 0.2.13 to 0.11.1 (CVE-2026-111322, 15 Oct), DB-GPT through 0.8.2 (CVE-2026-77932, 20 Oct) and Letta through 0.16.8 (CVE-2026-77937, 20 Oct). They were surfaced through the GitHub advisory search for ‘ai agent’, not a new outside source.
Analysis. Entry point: the agent’s own control interface, not the model. Trust boundary: network position is used as identity. The agent behind it is configured to run commands without asking (Archon’s bypassPermissions, OpenHands’ sandbox root, DB-GPT’s unsandboxed code and shell tools), so one unauthenticated request is a command execution. Details differ: OpenHands’ port is published on host interfaces by Docker while the server inside listens on 0.0.0.0 by design, and the 1.52.0 change (PR 5209) publishes it on 127.0.0.1 and forwards a configured key to the client; I could not tell from the PR whether the server now generates a key if none is set, so treat ‘fixed’ as ‘not reachable from outside the host’ rather than ‘authenticated’. DB-GPT replaces authentication with a mock function that returns admin, and the ReAct endpoint lets the caller choose the tools. Letta is a weaker case that is still telling: with LETTA_SERVER_SECURE on, the server trusts a user_id header from the caller, so one tenant reads and rewrites another’s agents and memory (CWE-639). Mapping: OWASP Agentic ASI03 (identity and privilege abuse), ASI05 (unexpected code execution), LLM06 excessive agency. Earlier cases of the same class: AgenticSeek and Agent Zero in the 23 and 24 Oct briefs. I found no exploitation, and for Archon and DB-GPT only third-party write-ups and the advisories, not a vendor statement.
Why it matters. Teams run these tools on a laptop or a shared build host, often through a container whose ports Docker publishes on all interfaces without a firewall prompt. Developer networks, VPN subnets and cloud instances with open security groups are the exposure. The credentials that the agent holds (model API keys, repository tokens) are the payoff, which makes this as attractive as the LiteLLM chain without needing a supply-chain step.
Mitigation and detection. Bind agent APIs to loopback and put an authenticating proxy in front for remote use; publish Docker ports as 127.0.0.1:port:port. Find listeners with ss -ltnp and docker ps --format '{{.Ports}}' (look for 0.0.0.0:). For tools with no fix (Archon, DB-GPT, Letta) restrict them with a host firewall or a private network segment and remove them from shared hosts. Alert on shell processes spawned by the agent’s server process, and on new outbound connections from the agent container to anything but the model provider. If one of these was reachable from a network you do not control, rotate every secret the agent could read.
Recommendation (opinion): treat ‘agent API with no key’ as a procurement fail. Add ‘authentication on by default and loopback bind by default’ to your selection criteria for agent platforms, and re-test after each upgrade because the default can change.
Sources: GHSA-rp7h-crm7-h5qj · OpenHands PR 5209 · OpenHands v1.52.0 · GHSA-3q7p-hhhj-qh4p (Archon) · GHSA-5vjv-vw3m-qpqp (DB-GPT) · GHSA-8p6h-849r-ww4h (Letta)
vLLM: ten more advisories, and one release that covers all of them (Update)
What happened. On 25 Oct the GitHub advisory feed added ten vLLM advisories, CVE-2026-116172 to 116181, all unreviewed and each referencing a VulnCheck advisory. Eight are denial of service: the Rust gRPC frontend (three: top_n, more than 128 logprob_token_ids, out-of-vocabulary prompt token ids), an audio decompression bomb, Nemotron-VL processors that switch off Pillow’s image-size check for the whole process, inconsistent multimodal metadata on the disaggregated /inference/v1/generate endpoint, the video num_frames override, and an uninitialized logprobs tensor that crashes a shared engine. One is an out-of-bounds write in the V2 runner’s logits buffer through stop_token_ids. One is SSRF: in a prefill/decode setup with the P2P NCCL connector, a decode address carried in the X-Request-Id header makes the prefill worker connect to an attacker’s host (CVE-2026-116176, 8.8). The fixed releases range from 0.24.0 to 0.31.0.
Analysis. This extends a series (CVE-2026-114049 to 114055 were covered on 21 to 26 Oct): input accepted at the API edge reaches a model-specific code path with a fatal consequence, and one request takes down every tenant on the engine. The SSRF is the odd one: it only applies to disaggregated serving, but a header that doubles as routing data is a trust-boundary error and could leak KV-cache tensors, which hold prompt content. Preconditions vary; most need only network access, and vLLM’s API key is optional. I confirmed the vLLM 0.32.0 release notes (18 Oct): it fixes three further advisories, stops allowing every CORS origin by default, limits untrusted images to raster formats, signs shared-memory multimodal cache handles and rejects JSON schemas nested deeper than 64 levels. Since every fix in this batch is in 0.31.0 or earlier, 0.32.0 contains them all. I did not check the individual patches.
Why it matters. Availability of a shared model server is a security property, and seventeen CVEs in one engine in about a week says the multimodal and disaggregated paths are still being hardened by external reporters.
Mitigation and detection. Upgrade to 0.32.0 or later. Do not expose the gRPC or disaggregated endpoints beyond the cluster. Require an API key and put a gateway with request-size, media-size and rate limits in front. Alert on engine restarts and out-of-memory kills.
Recommendation (opinion): one upgrade, scheduled. If you serve untrusted callers, move to 0.32.0 this week; if the engine is internal-only, fold it into the next maintenance window.
Sources: GHSA-3r8v-vh9c-f8hq (SSRF) · GHSA-vchq-p6cc-h35x · GHSA-w9hx-wr9v-56wv · GHSA-6gg7-pp4x-7486 · GHSA-v8gv-gxpf-cg62 · vLLM releases
Shorter items
llama.cpp builds b5899 to before b10261 (CVE-2026-116816, CVSS 8.5): the PLaMo2 tokenizer parses a byte token such as <0x-1> into a negative index and writes before the start of a heap buffer when a crafted GGUF model is loaded. Fixed in b10261. Same class as the GGUF parser bugs of March: models are untrusted input, so load only models you trust or from a verified source. smg 1.7.0 to 1.10.1 (CVE-2026-116095, 5.5): a crafted JPEG forces a huge allocation in the multimodal decoder; fixed in 1.11.0. FastMCP 3.0.0 to before 3.4.10 and 4.0.0 to before 4.1.2 (GHSA-7xgj-8392-5q4r, 6.8, no CVE): when a server transform changes the metadata an authorization policy reads, the list view authorizes the transformed tool but a direct call skips the final check, so a low-privilege caller who knows the name can call a hidden admin tool; fixed in 3.4.10 and 4.1.2; enforce required authorization in the handler, not in a policy a transform can change. No fix, vendor silent or unspecified: iFlytek astron-agent up to 1.1.2 (CVE-2026-116339 DDL allow-list bypass, 5.5, and CVE-2026-116340 knowledge-base authorization bypass, 2.1, public proof of concept for both), CreditNirvana’s agentic call-centre application (CVE-2026-110474, 8.7, a hard-coded API key in the JavaScript bundle that returns call transcripts and recordings; CERT-In CIVN-2026-0523), and 777genius agent-teams-ai up to 2.17.10 (CVE-2026-116228, 1.9, unauthenticated local HTTP service). The CreditNirvana flaw is the one with real data behind it: call recordings are regulated personal data, and the ‘fix’ is to stop using the exposed key’s service until the vendor rotates it.
Sources: GHSA-3r8c-j789-2864 · GHSA-55xq-367r-px8q · GHSA-7xgj-8392-5q4r · GHSA-2rxp-23g6-8q6h · GHSA-c5pp-m7xr-h39f · GHSA-72fh-w73q-9x49 · GHSA-66pv-c3hh-r626
Incidents and supply chain
A fake ‘Web3 accelerator’ and a trojanised coding agent on npm
What happened. Search results point to a campaign by a fake Web3 accelerator (‘Apex’) that published npm packages aimed at founders: @apexacc/cli, @apexfdn/apex, @copilot-mcp/apex and @apexfdn/copilot-mcp. Extracts quoting Elastic Security Labs, The Hacker News, Corgea and an npm malicious-package record (MAL-2026-17924, 16 Oct) say @apexacc/cli is a repackaged open-source coding agent (Oh My Pi) with added code that reroutes model traffic to attacker infrastructure, registers an attacker-controlled remote MCP server, and defaults tool approval to ‘yolo’; the other packages ran a post-install script that asked for administrator credentials and fetched a binary, and delivered stealers and backdoors on macOS and Windows. Attribution is unclear; Elastic reportedly notes Russian-language commit comments do not establish an actor. I could not open any of those pages. What I did verify on the npm registry: @apexacc/cli was created on 9 Aug, has 124 time entries and latest 1.6.2, last modified 13 Oct; @apexfdn/copilot-mcp (an ‘MCP server for portfolio diligence and operator tools’) was created on 30 Apr, latest 0.11.6, last modified 20 Jul, and is still published. I did not download either package.
Analysis. The technique worth noting is not the stealer but the target: an agent configuration. Three features give an attacker durable control without a normal malware footprint: a model endpoint they own (every prompt and file the agent reads goes there, and every answer comes back), an MCP server they own (its tool descriptions steer the agent), and an approval mode that removes the human check. A search extract describes the same pattern in the SANDWORM_MODE typosquats earlier this year, which reportedly planted a malicious MCP server in Claude, Cursor and Windsurf configs. Mapping: OWASP Agentic ASI04 (supply chain), LLM03; MITRE ATLAS supply-chain compromise. I could not confirm the scale (downloads) or any victim.
Why it matters. Anyone who installed the CLI or the MCP package, or ran the post-install script, should assume the agent configuration is attacker-controlled, not just that a binary ran.
Mitigation and detection. Search developer machines and lock files for the package names above; check ~/.config, Claude Desktop, Cursor and Windsurf MCP configs and any agent settings for model endpoints, MCP servers and approval modes you did not set; rotate every credential that was on a machine where the packages ran. Treat ‘a coding agent distributed as an npm CLI by an unknown publisher’ like any unvetted code that runs with your credentials.
Recommendation (opinion): check, do not wait. The registry confirms the packages exist; the malicious behaviour is reported by sources I could not read, so a one-hour search of your estate costs less than a wrong guess.
Sources: npm: @apexacc/cli · npm: @apexfdn/copilot-mcp · Elastic Security Labs (not opened; search extract) · Corgea (not opened; search extract) · OSV MAL-2026-17924 (not opened)
Policy and research
Nothing new that passes the test in this window. I found no agentic CISA KEV entry for October (the latest AI-infrastructure KEV additions I can see are the Langflow and LiteLLM entries of July to September, from secondary coverage only), no new OWASP or MITRE ATLAS publication since the 2026 LLM Top 10 and Agent Control Standard of 1 Sep, and no EU AI Act or INCIBE item dated in the window. MCP’s open Attested Tool-Server Admission proposal (SEP-2809, open since 28 May) and a restructured Security Interest Group (pull request 3331) are the two security items still in the specification queue; see the daily signal.
Sources: MCP specification pull requests · SEP-2809