When upgrading is not the whole fix: MCP's stored tokens and Kubernetes' cgroup v1 nodes

Serguey Asael Shinder07 October 2026, 07:331 min read

Most upgrade notes end with "upgrade to version X". Two published on 6 October say plainly that this is only part of the job.

MCP TypeScript SDK. The advisory for CVE-2026-104850 fixes a flaw that let a malicious MCP server choose the authorization server receiving a client's refresh token and client secret. The patched client records an issuer on saved credentials and refuses to send them elsewhere. But the advisory lists what the package update cannot reach:

• credentials saved before the upgrade have no issuer, so they still go wherever the server says at first use;
• bundled providers still follow the server unless you pass expectedIssuer;
• a custom OAuthClientProvider must store the new field, or it drops it.

The fix is in the code; the exposure is in the data you already wrote.

Kubernetes cgroup v1. Since v1.35, failCgroupV1 defaults to true, so an upgraded kubelet refuses to start on a node still running cgroup v1, and kubeadm's preflight now errors instead of warning. The guidance is ordered: migrate every node, or set the temporary override deliberately, before upgrading. An upgrade done first finds the remaining v1 nodes by failing on them.

The common pattern. In both cases the new version changes a default or a contract, and state that predates it, stored tokens or a node's kernel configuration, keeps the old behaviour or stops working. The practical reading is the same: before marking such an upgrade done, list what was created under the old rules and check it against the new ones. Both sources make that list for you; it is in the advisory and the blog post, not in the version number.