Daily signal: MCP's Stable extensions can change only with a new core revision, the Events proposal keeps collecting security comments, and Tasks reaches Claude Code

Executive summary

The level stays elevated, carried by the security brief. The one ecosystem fact that changed risk is in the MCP process, and it follows from yesterday’s signal: the extension lifecycle text now states that a Stable extension changes only with a new core revision. Combined with the two-releases-a-year calendar merged on 27 Oct, that means a security flaw in a Stable extension has no documented faster route than the next revision, unless the maintainers add one. Elsewhere the window was quiet: the Events proposal is moving through review with its security questions partly answered, and Tasks is arriving in more clients.

MCP governance: the patch-path question gets an answer, and it is “next revision” (Update)

OfficialUpdate · 27 to 28 Oct

What happened. On 27 Oct the maintainers dismissed a stale review on SEP-3392 (Extension Lifecycle), added the final label and merged main into the branch, and dsp-ant approved. The pull request was still open when I read it, with no recorded activity on 28 or 29 Oct. Its summary states that a Stable extension changes only with a new core protocol revision. The 28 Oct signal reported that the text I could read did not say how a security fix reaches a Stable extension; this is the closest the text comes, and I did not find a security or emergency-fix exception on the page I read.

Analysis. The lifecycle has four stages (Experimental, Beta, Stable and Core), and Stable is where a client may enable an extension by default. If a flaw is found in a Stable extension’s semantics, as opposed to an SDK implementation bug, the rule as summarised sends the change to the next core revision. SEP-3398, merged the same day, sets those revisions at March and September, so the interval is on the order of six months, though the SEP also mentions emergency approvals for the review queue, which I could not read in full and which concerns review, not release. The practical consequence: the real patch channel for an extension’s security behaviour will be the SDK and the client, as it already is for the audience, redirect and size-limit fixes in the 28 Oct brief. That is workable, but it means two conformant implementations can differ in the safe behaviour for months, and a flaw in the wire semantics has no fix at all until a revision. Compare how TLS handled this: the protocol versions move slowly and the real fixes ship as library and configuration changes, with a deprecation path for the unsafe mode; MCP has not yet written the deprecation path.

Why it matters. A team that builds on a Stable extension is trusting a rule that is hard to change quickly. It should expect to carry its own mitigations and to track the SDK changelog, not the specification calendar.

Mitigation and detection. Pin extensions by name and version and gate them behind a feature flag you control; log the negotiated extension set per connection so you can see which clients still use a superseded behaviour; read the full SEP-3392 text (not the pull-request summary I read) for a security or hotfix clause before relying on Stable status.

Recommendation (opinion): ask for a security exception in the text before it merges. One paragraph would do: security-motivated changes to a Stable extension may ship in a point revision with a deprecation window for the unsafe behaviour. The pull request is the place to ask.

Sources: SEP-3392 pull request #3392 · SEP-3398 pull request #3398 · PADAWAN 28 Oct signal

SEP-3415 Events: signing moves to the Server Card, and the comments are not closed (Update)

OfficialUpdate · 28 Oct

What happened. SEP-3415 defines an Events extension (io.modelcontextprotocol/events) that lets a client subscribe to things that happen upstream, such as a message or a repository push, so an agent can react without a user present, by poll, push stream or webhook. On 28 Oct the author marked it ready for review and pushed a commit moving signing keys and egress ranges onto the Server Card (with a dependency on ext-server-card#55). It is open with no approving review. The page I read was cut at 100,000 of 101,146 characters, so the last comments may be missing.

Analysis. The security design, as the page describes it, is sound in outline and copies what works in webhooks elsewhere: subscriptions keyed by principal, so one tenant cannot unsubscribe another or rotate its secret; webhook subscribe and unsubscribe require an authenticated principal, and unauthenticated servers may offer only poll and push; a challenge handshake on subscribe through the same SSRF-hardened path as deliveries (delivery-time IP validation, no redirects, per-host rate limits); deliveries signed to the Standard Webhooks scheme with an optional ed25519 server signature; opaque resumption cursors. Comments from 20 Oct by a reviewer (preston-footprint) remain the open items I could see: event ids are written into an HTTP header with no character or length limit, so line breaks or long values could break it (header injection or truncation); the subscription id is a plain hash that may be logged, so a guessed principal can be checked against it, and a keyed hash was suggested; the secret encoding is not pinned; and lastError lacks categories for DNS failures, blocked addresses and refused redirects. Separate review threads ask whether unauthenticated stdio servers should be exempt from the principal rule, which I read as unresolved. The event-id and webhook-id dedupe problem was addressed in a commit. In threat terms, an event feed is an injection channel with a long fuse: any external text carried in an event reaches an agent that no one is watching. That is the trust problem of indirect prompt injection with the human taken out of the loop, so the extension’s own text about how clients treat event payloads (untrusted data, not instructions) matters more than its transport details. I did not find such a requirement on the page I read.

Why it matters. Events is what makes agents autonomous in practice, and an agent waking on an unattended trigger is the setting in which the approval-gate failures covered on 22 Oct bite hardest.

Mitigation and detection. Do not build on Events yet; if you prototype, treat every event field as untrusted input, cap and validate ids and header values, use keyed subscription identifiers, and run event-triggered agents with the narrowest tool set and no auto-approval.

Recommendation (opinion): comment on the pull request. Ask for an explicit client requirement that event payloads are untrusted and not interpreted as instructions, and for the header and id limits to be normative.

Sources: SEP-3415 pull request #3415 · PADAWAN 23 Oct signal

Tasks reaches Claude Code and Claude.ai

Official26 to 28 Oct

What happened. Two documentation pull requests merged in the modelcontextprotocol repository: #3355 (26 Oct) added the Tasks extension to the client support matrix, and #3459 (28 Oct) marked Tasks as supported in Claude.ai and added a Claude Code row with a check in the Tasks column. Both are documentation changes; neither page gives client versions. I could not see the full matrix.

Analysis and why it matters. Tasks lets a tool call return a handle immediately and finish later, which suits long jobs and is also what lets an agent keep working after the person looked away. The new supported clients make that a default-adjacent feature for a large developer population. The relevant security detail is a separate TypeScript SDK advisory published on 20 Oct, which by title said experimental tasks were not tied to the session that created them (High, @modelcontextprotocol/sdk; I read only the listing, not the advisory, and it was in the 21 Oct brief). That is the same identifier-as-authority error as the cases in today’s brief: if a task id works across sessions, another client can read or cancel a result. A server written on an older SDK may still have it.

Mitigation and detection. Check that the SDK your server uses is at or beyond the release that fixes the task-binding advisory; require task ids to be unguessable and checked against the creating session and principal; set a lifetime on task results. For clients, log task creation and completion so a background action can be tied to a person.

Recommendation (opinion): enable Tasks for servers you operate, not for third-party servers you have not reviewed. An asynchronous result from a server you do not control is a channel for content to reach the model later, outside the turn where the user saw the call.

Sources: #3459 · #3355 · GHSA-22jm-h49p-29qw (title only)

Releases read for security

modelcontextprotocol/servers 2.2.0 (28 Oct)

What happened. The project’s second reference-server release in four days ships mcp-server-fetch, mcp-server-git and mcp-server-time 2026.10.28, server-everything and server-filesystem 2.1.0 and server-memory 2.0.1. It fixes GHSA-w766-5x43-whvw in the git server and responds to the 20 Oct disclosure that eMudhra intermediate certificate-authority keys could be recovered and to Node.js security releases on 21 Oct: the notes say to run Node.js 24.22.1 or 26.12.1 or later for the TypeScript servers, which use your local runtime, and that Python’s certifi 2026.10.23 removed two eMudhra roots, which fresh mcp-server-fetch installs pick up while existing environments need uvx --refresh mcp-server-fetch or pip install -U certifi. Only server-everything and the fetch server make outbound HTTPS requests, per the notes.

Why it matters. This is the first MCP server release I have seen that tells users to change their runtime. It matches the 24 Oct brief on trust stores: the exposure sits in what the server depends on, not in the server. Check Node.js with node --version on every machine that runs a TypeScript MCP server, and refresh the Python environment for the fetch server. Source: servers releases

vLLM 0.31.0 and 0.32.0: request inputs are being gated (Update)

What happened. From the release pages: 0.31.0 (5 Oct) rejects per-request mm_processor_kwargs and media_io_kwargs unless the server is started with --trust-request-mm-kwargs, tags prefix-cache keys by their source, and includes the LoRA path in the block hash so that a LoRA name and a cache_salt cannot collide. 0.32.0 (18 Oct) fixes three advisories (chat template resource exhaustion, tokenizer max_token_id, peer-to-peer ZMQ socket exhaustion), restricts default CORS origins, limits untrusted images to raster formats, signs shared-memory multimodal cache handles and rejects JSON schemas nested deeper than 64 levels. I read the highlights on the page, which was cut at 100,000 of 208,554 characters, so older entries and details are unread.

Why it matters. This is the project turning the lessons of the last three weeks into defaults: a client should not choose processing parameters, a cache key should not be forgeable across sources, and anything shared between processes should be authenticated. The cache-key change is the same fix pattern as the identifier-as-authority cases in today’s brief. Upgrade to 0.32.0 if you serve models to more than one team; the new default of rejecting request-supplied multimodal arguments may break a client that sends them, so test. Source: vLLM releases

Proposals and clients: nothing else moved

SEP-3094 (granular citations) is a draft without a sponsor, updated on 28 Oct. It would let servers and clients exchange verifiable pointers into resources using W3C annotation and schema.org metadata. The page I read has no security discussion; the point to watch is that citations are untrusted text and URLs from a tool result that a client may render as authoritative, so a rendering requirement (show the real target, never auto-fetch) belongs in the proposal. Source: #3094

Clients. Claude Code’s newest release is 2.1.312 (27 Oct), covered in the 28 Oct signal; Codex 0.165.0 (27 Oct) is also covered there. SDKs: no TypeScript SDK release after 2.4.0 (23 Oct) and no Python SDK release after 2.3.0 (2 Oct); the Python advisories of 27 Oct describe fixes that shipped in 1.30.0 and 2.2.0 on 7 Sep. A2A: no new release. Models: none verified in the window.