Wenn das Update nicht die ganze Korrektur ist: gespeicherte MCP-Tokens und cgroup-v1-Knoten

Serguey Asael Shinder07 October 2026, 07:331 Min. Lesezeit

Die meisten Update-Hinweise enden mit „auf Version X aktualisieren“. Zwei vom 6. Oktober sagen ausdrücklich, dass das nur ein Teil der Arbeit ist.

MCP-TypeScript-SDK. Der Hinweis zu CVE-2026-104850 behebt eine Schwachstelle, durch die ein bösartiger MCP-Server bestimmen konnte, welcher Autorisierungsserver das Refresh-Token und das Client-Secret eines Clients erhält. Der korrigierte Client speichert einen issuer bei den Zugangsdaten und schickt sie an keinen anderen. Der Hinweis nennt aber, was das Paket-Update nicht erreicht:

• vor dem Update gespeicherte Zugangsdaten haben keinen issuer und gehen beim ersten Gebrauch weiter dorthin, wo der Server es sagt;
• mitgelieferte Provider folgen weiter dem Server, solange man kein expectedIssuer übergibt;
• ein eigener OAuthClientProvider muss das neue Feld speichern, sonst geht es verloren.

Die Korrektur steckt im Code; die Gefährdung in den Daten, die man schon geschrieben hat.

Kubernetes und cgroup v1. Seit v1.35 ist failCgroupV1 standardmäßig true; ein aktualisiertes Kubelet startet auf einem Knoten mit cgroup v1 nicht, und der Preflight von kubeadm bricht ab, statt zu warnen. Die Empfehlung hat eine Reihenfolge: vor dem Upgrade jeden Knoten umstellen oder die vorübergehende Ausnahme bewusst setzen. Wer zuerst aktualisiert, findet die verbliebenen v1-Knoten daran, dass sie ausfallen.

Das gemeinsame Muster. In beiden Fällen ändert die neue Version einen Standard oder einen Vertrag, und Zustand, der älter ist – gespeicherte Tokens oder die Kernel-Konfiguration eines Knotens –, behält das alte Verhalten oder funktioniert nicht mehr. Praktisch heißt das: Bevor man ein solches Update als erledigt markiert, auflisten, was unter den alten Regeln entstanden ist, und es gegen die neuen prüfen. Beide Quellen liefern diese Liste mit – im Sicherheitshinweis und im Blogbeitrag, nicht in der Versionsnummer.