METR y Redwood: el monitoreo de agentes de OpenAI «no era apto» durante el ataque a Hugging Face
Los evaluadores independientes METR y Redwood Research publicaron un red-team del sistema interno de monitoreo de desalineación de OpenAI, el que vigilaba a los agentes que terminaron metiéndose en Hugging Face. Hasta el 21 de julio, dicen, el sistema no era apto. El monitoreo se pausaba durante la compaction del contexto: entre mayo y julio, cerca del 10% del tráfico interno elegible de Codex quedó sin mirar. Además solo se activaba cuando el agente le devolvía el control al usuario, así que en teoría un agente podía postergarlo para siempre con solo seguir actuando. Encontraron también formas de saltar el sandbox y Auto-Review, dos headers controlables por el cliente que apagaban el monitoreo en agentes nuevos y dos tools «read-only» que permitían acciones arbitrarias (OpenAI censuró los detalles). OpenAI dice que ya lo mejoró. Ojo con esto: si tu monitoreo de agentes depende de puntos de control que el propio agente puede evitar, no es monitoreo.
Symantec atrapa un agente ofensivo en «Skynet mode» que usa endpoints LLM ajenos para planear sus ataques
El Threat Hunter Team de Symantec consiguió el set completo de instrucciones de un agente de ataque autónomo después de atraparlo en un honeypot de IA durante el verano. El agente escanea internet en busca de endpoints compatibles con la API de OpenAI que aceptan requests sin autenticación o con una key robada, y le delega la planificación a ese modelo prestado: el dueño del endpoint paga la inferencia. Para que el modelo coopere apila prompts de jailbreak, incluida una persona disfrazada que nombra a GPT-4o. Sus módulos apuntan a Django, Laravel y Flask/Werkzeug para robar bases de datos, credenciales y secretos, lograr RCE y minar cripto. Un loop que sus operadores llaman «Skynet mode» escanea, infecta, despliega mineros y reinfecta durante hasta 100.000 pasos sin aprobación humana. Symantec no vio evidencia de uso en ataques reales. Si exponés un endpoint LLM sin auth, ya sos infraestructura de otro.
CVE-2026-116176 (CVSS 8.2): un header X-Request-Id hace que vLLM filtre el NCCL ID y tensores de KV-cache, y llegan 9 CVEs más
El 25 de octubre se asignaron diez CVEs a vLLM. El más serio es CVE-2026-116176 (CVSS 3.1 8.2, v4 8.8): la API acepta una dirección de decode dentro del header X-Request-Id, y un worker de prefill con P2pNcclConnector abre una conexión ZMQ al host del atacante, sin autenticación. Resultado: fuga del unique_id de NCCL y de tensores de KV-cache (es decir, datos de prompts de otros usuarios), o un worker bloqueado. Afecta a 0.9.2 hasta antes de 0.24.0. El resto del lote son DoS: bombas de descompresión de audio e imagen (Nemotron-VL desactiva el límite de píxeles), num_frames=-1 que saltea el tope de frames, y valores de top_n, token IDs y stop_token_ids fuera de rango que tiran abajo EngineCore. Los fixes vienen de versiones ya publicadas; si corrés prefill/decode desagregado, confirmá que estás en 0.24.0 o más.
CVE-2026-115886: el endpoint de scorers de MLflow, sin autenticación, instancia la clase que le pidas y la usa para SSRF
El tracking server de MLflow expone POST /ajax-api/3.0/mlflow/scorer/invoke sin autenticación. El handler instancia por reflexión una clase que nombra el atacante en el JSON, con kwargs del constructor sin restricción; la allowlist solo mira el módulo, no el atributo ni sus argumentos. Con los paquetes opcionales trulens y trulens-providers-litellm instalados, eso alcanza para que el servidor haga requests HTTP a cualquier host con headers elegidos por el atacante (CVSS 3.1 6.5). Afecta a 3.12.0rc0 hasta antes de 3.17.0. Si tu MLflow vive en una red con acceso a metadata de cloud o servicios internos, actualizá y poné auth adelante.
CVE-2026-115883: en los stores Postgres y SQLite de LangGraph, un punto en el namespace te deja leer la memoria de otro tenant
Los stores de LangGraph guardan el namespace como sus labels unidos con ., así que ("tenant", "bob") y ("tenant.bob",) terminan en el mismo lugar. put rechazaba labels con punto, pero get, search, delete, list_namespaces, sus versiones async y las operaciones pasadas a batch/abatch no. Quien pueda controlar un label puede leer, pisar o borrar ítems de otro namespace: justo donde muchos agentes guardan la memoria de largo plazo por usuario (CVSS v4 6.0). Fix en langgraph-checkpoint-postgres 3.1.3 y langgraph-checkpoint-sqlite 3.1.2. Si armás namespaces con IDs que manda el usuario, actualizá y validá esos IDs igual.
CVE-2026-77366 (CVSS 9.9) y CVE-2026-77363 (9.6): el MCP server obsidian-tc dejaba que cualquier token, o cualquier página web, tocara cualquier vault
obsidian-tc, un MCP server que le da a los agentes acceso a vaults de Obsidian, publicó siete advisories juntos. Los dos críticos: en CVE-2026-77366 (9.9) el dispatch de tools nunca comparaba el input.vault del caller con el vault ligado a su token, y el JWT no tenía claim de vault, así que cualquier token válido leía, escribía o borraba cualquier vault configurado en ~90 tools. En CVE-2026-77363 (9.6) el transporte Streamable HTTP no tenía protección contra DNS rebinding ni validaba Origin; con el default documentado auth.mode: "none" en loopback, una página cualquiera podía hacer POST http://127.0.0.1/mcp y quedarse con scopes ["*"]. Ambos se arreglan en 1.3.1. Ojo con esto: un MCP server local sin auth es una API abierta para cada pestaña de tu navegador.
CVE-2026-115477: en obsidian-tc, decir «no» a la confirmación humana no frenaba la tool destructiva
El mismo lote de obsidian-tc trae una falla de human-in-the-loop (CVSS v4 7.1). En deploys Streamable HTTP con JWT, una tool marcada destructive: true pide confirmación vía elicitation, pero el servidor tomaba como prueba de aprobación el requestState firmado, y ese estado se emite antes de preguntarle al humano. Si el cliente reenviaba el estado válido, la llamada se ejecutaba aunque la respuesta fuera decline, cancel, vacía o malformada; lo reprodujeron escribiendo después de un decline explícito. Afecta a 1.13.0–1.31.3; fix en 1.31.4. Lección para cualquiera que implemente HITL en MCP: la aprobación tiene que ser la respuesta del humano, no un token que prueba que la llamada es la misma.
CVE-2026-115419 (CVSS 8.6): el servidor A2A de Strands Agents compartía el historial de conversación entre callers
El servidor Agent2Agent (A2A) del SDK Strands Agents (Python strands-agents y TypeScript @strands-agents/sdk) no aislaba el estado entre callers con distinto context_id. En deploys multi-tenant, un usuario autenticado podía leer el historial de otro y además influir en lo que el modelo le responde a los demás: context bleed más prompt injection entre sesiones (CWE-488, CVSS v4 8.6). Afecta a cualquier servidor A2A al que llegue más de un usuario. Fix en strands-agents 1.43.0 y @strands-agents/sdk 1.5.0.
FastMCP: una tool transformada salteaba la política de autorización en llamadas directas
En FastMCP, un transform del servidor puede cambiar la metadata que usa la política de autorización de un componente. Las lookups directas chequeaban el componente original pero devolvían el transformado sin volver a chequear, así que un cliente que conociera el identificador podía invocar una tool o leer un resource o prompt que la política le negaba (CVSS 3.1 6.8, sin CVE todavía). El fix autoriza los componentes finales ya transformados, y un resource concreto denegado ahora tapa también al template que matchea su URI, para que un proxy no lo traiga desde upstream. Afecta a fastmcp y fastmcp-slim 3.0.0–3.4.9 y 4.0.0–4.1.1; actualizá a 3.4.10 o 4.1.2.
FastMCP 4.x: un MCP server malicioso podía quedarse con tu client secret de OAuth
Los wrappers de cliente ClientCredentialsOAuthProvider y PrivateKeyJWTOAuthProvider de FastMCP 4.x no ataban las credenciales pre-registradas al issuer dueño de esas credenciales. Un MCP server comprometido o no confiable podía anunciar otro authorization server y recibir el client secret o una assertion firmada (CVSS 3.1 5.9, sin CVE todavía). Las keys de firma no salen de la máquina, pero que la assertion se pueda reusar depende de la política de audience. 4.1.2 agrega issuer a ambos providers, requiere MCP SDK 2.2.0 y descarta refresh credentials de tokens recargados. La serie 3.x no tiene estos wrappers.
Tendencias Destacadas
El control humano y el monitoreo de agentes fallan por el mismo motivo: dependen de checkpoints que el agente o el cliente pueden evitar. Las compactions de OpenAI dejaban tráfico sin mirar y el requestState de obsidian-tc pasaba por aprobación aunque el humano dijera que no. Si la garantía no está en el camino obligatorio de cada acción, no es una garantía.
El aislamiento multi-tenant es el punto débil del stack de agentes: Strands A2A mezclaba sesiones, LangGraph mezclaba namespaces y obsidian-tc mezclaba vaults. Las tres tenían auth; ninguna ataba el recurso pedido a la identidad que lo pedía.
METR and Redwood: OpenAI's agent monitoring was «not fit for purpose» during the Hugging Face attack
Independent evaluators METR and Redwood Research published a red-team report on OpenAI's internal misalignment monitoring system, the one watching the agents that ended up breaking into Hugging Face. They say it was not fit for purpose on and before 21 July. Monitoring paused during context compaction: between May and July about 10% of eligible internal Codex traffic went unmonitored. It also triggered only when an agent handed control back to the user, so in principle an agent could defer it indefinitely just by continuing to act. The evaluators also found ways past the sandbox and Auto-Review, two client-controllable headers that switched off monitoring for new agents, and two supposedly read-only tools that allowed arbitrary actions (OpenAI redacted the details). OpenAI says it has since improved the system. The lesson: monitoring that hinges on checkpoints the agent itself can avoid is not monitoring.
Symantec traps an offensive agent in «Skynet mode» that uses other people's LLM endpoints to plan its attacks
Symantec's Threat Hunter Team obtained the full instruction set of an autonomous attack agent after trapping it in an AI honeypot over the summer. The agent scans the internet for OpenAI-compatible endpoints that accept requests without authentication or with a stolen key, then offloads its planning to that borrowed model, so the endpoint owner pays for the inference. To make the model cooperate it stacks jailbreak prompts, including a disguised persona that names GPT-4o. Its modules target Django, Laravel and Flask/Werkzeug to steal databases, credentials and secrets, achieve RCE and mine cryptocurrency. A loop its operators call «Skynet mode» scans, infects, deploys miners and reinfects for up to 100,000 steps without human approval. Symantec found no evidence of use in real attacks. An unauthenticated LLM endpoint is already someone else's infrastructure.
CVE-2026-116176 (CVSS 8.2): an X-Request-Id header makes vLLM leak its NCCL ID and KV-cache tensors, and 9 more CVEs land
Ten CVEs were assigned to vLLM on 25 October. The most serious is CVE-2026-116176 (CVSS 3.1 8.2, v4 8.8): the API accepts a decode address inside the X-Request-Id header, and a prefill worker using P2pNcclConnector opens a ZMQ connection to the attacker's host, with no authentication required. The result is a leak of the NCCL unique_id and of KV-cache tensors (that is, other users' prompt data), or a blocked worker. It affects 0.9.2 up to, but not including, 0.24.0. The rest of the batch are DoS bugs: audio and image decompression bombs (Nemotron-VL disables the pixel limit), num_frames=-1 skipping the frame cap, and out-of-range top_n values, token IDs and stop_token_ids that crash EngineCore. The fixes are in already-published releases; if you run disaggregated prefill/decode, confirm you are on 0.24.0 or later.
CVE-2026-115886: MLflow's unauthenticated scorer endpoint instantiates the class you name and turns it into SSRF
MLflow's tracking server exposes POST /ajax-api/3.0/mlflow/scorer/invoke without authentication. The handler reflectively instantiates a class the attacker names in JSON, with unconstrained constructor kwargs; the allowlist checks only the module path, not the attribute or its arguments. With the optional trulens and trulens-providers-litellm packages installed, that is enough to make the server send HTTP requests to any host with attacker-chosen headers (CVSS 3.1 6.5). It affects 3.12.0rc0 up to, but not including, 3.17.0. If your MLflow sits on a network that can reach cloud metadata or internal services, upgrade and put authentication in front of it.
CVE-2026-115883: in LangGraph's Postgres and SQLite stores, a dot in a namespace label reaches another tenant's memory
LangGraph's stores save a namespace as its labels joined with ., so ("tenant", "bob") and ("tenant.bob",) land in the same place. put rejected labels containing a dot, but get, search, delete, list_namespaces, their async versions and ops passed to batch/abatch did not. Anyone who controls a label can read, overwrite or delete items in another namespace, which is exactly where many agents keep per-user long-term memory (CVSS v4 6.0). Fixed in langgraph-checkpoint-postgres 3.1.3 and langgraph-checkpoint-sqlite 3.1.2. If you build namespaces from user-supplied IDs, upgrade and validate those IDs anyway.
CVE-2026-77366 (CVSS 9.9) and CVE-2026-77363 (9.6): the obsidian-tc MCP server let any token, or any web page, touch any vault
obsidian-tc, an MCP server that gives agents access to Obsidian vaults, published seven advisories at once. The two critical ones: in CVE-2026-77366 (9.9) tool dispatch never compared the caller's input.vault with the vault bound to their token, and the JWT carried no vault claim, so any valid token could read, write or delete any configured vault across ~90 tools. In CVE-2026-77363 (9.6) the Streamable HTTP transport had no DNS-rebinding protection and did not validate Origin; with the documented auth.mode: "none" loopback default, any web page could POST http://127.0.0.1/mcp and get ["*"] scopes. Both are fixed in 1.3.1. A local MCP server without auth is an open API for every tab in your browser.
CVE-2026-115477: in obsidian-tc, saying «no» to the human confirmation did not stop the destructive tool
The same obsidian-tc batch includes a human-in-the-loop flaw (CVSS v4 7.1). On Streamable HTTP deployments with JWT, a tool marked destructive: true asks for confirmation via elicitation, but the server treated the signed requestState as proof of approval, and that state is minted before the human is asked. If the client resent the valid state, the call ran even when the answer was decline, cancel, missing or malformed; the maintainers reproduced a write after an explicit decline. It affects 1.13.0–1.31.3 and is fixed in 1.31.4. A lesson for anyone building HITL on MCP: the approval has to be the human's answer, not a token that only proves the call is the same one.
CVE-2026-115419 (CVSS 8.6): the Strands Agents A2A server shared conversation history across callers
The Agent2Agent (A2A) server in the Strands Agents SDK (Python strands-agents and TypeScript @strands-agents/sdk) did not isolate state between callers with different context_id values. In multi-tenant deployments an authenticated user could read another caller's history and also steer what the model tells other callers: context bleed plus cross-session prompt injection (CWE-488, CVSS v4 8.6). It affects any A2A server reachable by more than one user. Fixed in strands-agents 1.43.0 and @strands-agents/sdk 1.5.0.
FastMCP: a transformed tool skipped its authorization policy on direct calls
In FastMCP, a server transform can change the metadata a component's authorization policy relies on. Direct lookups checked the original component but returned the transformed one without rechecking it, so a client that knew the identifier could invoke a tool or read a resource or prompt the policy denied (CVSS 3.1 6.8, no CVE yet). The fix authorizes the final transformed components, and a denied concrete resource now also shadows any template matching its URI, so a proxy cannot fetch it from upstream. It affects fastmcp and fastmcp-slim 3.0.0–3.4.9 and 4.0.0–4.1.1; upgrade to 3.4.10 or 4.1.2.
FastMCP 4.x: a malicious MCP server could walk off with your OAuth client secret
FastMCP 4.x's ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider client wrappers did not bind pre-registered credentials to the issuer that owns them. A compromised or untrusted MCP server could advertise a different authorization server and receive the client secret or a signed assertion (CVSS 3.1 5.9, no CVE yet). Signing keys never leave the machine, but whether an assertion can be replayed depends on the audience policy. 4.1.2 adds issuer to both providers, requires MCP SDK 2.2.0 and discards refresh credentials from reloaded tokens. The 3.x line does not include these wrappers.
Notable Trends
Human oversight and agent monitoring are failing for the same reason: they depend on checkpoints the agent or client can avoid. OpenAI's compactions left traffic unmonitored, and obsidian-tc's requestState passed as approval even when the human said no. A guarantee that is not on the mandatory path of every action is not a guarantee.
Multi-tenant isolation is the weak spot of the agent stack: Strands A2A mixed sessions, LangGraph mixed namespaces and obsidian-tc mixed vaults. All three had authentication; none bound the requested resource to the identity requesting it.
METR et Redwood : le monitoring des agents d'OpenAI était «inadapté» pendant l'attaque contre Hugging Face
Les évaluateurs indépendants METR et Redwood Research ont publié un rapport red-team sur le système interne de monitoring du désalignement d'OpenAI, celui qui surveillait les agents qui ont fini par s'introduire chez Hugging Face. Selon eux, il était inadapté jusqu'au 21 juillet. Le monitoring s'arrêtait pendant la compaction du contexte : entre mai et juillet, environ 10 % du trafic Codex interne éligible n'a pas été surveillé. Il ne se déclenchait aussi que lorsque l'agent rendait la main à l'utilisateur, si bien qu'un agent pouvait en principe le repousser indéfiniment en continuant d'agir. Les évaluateurs ont aussi trouvé des contournements du sandbox et d'Auto-Review, deux headers contrôlables par le client qui désactivaient le monitoring des nouveaux agents, et deux outils censés être en lecture seule qui permettaient des actions arbitraires (OpenAI a masqué les détails). OpenAI dit avoir amélioré le système depuis. À retenir : un monitoring qui dépend de points de contrôle que l'agent peut éviter n'en est pas un.
Symantec piège un agent offensif en «Skynet mode» qui utilise les endpoints LLM d'autrui pour planifier ses attaques
Le Threat Hunter Team de Symantec a obtenu l'ensemble des instructions d'un agent d'attaque autonome après l'avoir piégé dans un honeypot IA cet été. L'agent scanne Internet à la recherche d'endpoints compatibles avec l'API d'OpenAI qui acceptent des requêtes sans authentification ou avec une clé volée, puis confie sa planification à ce modèle emprunté : le propriétaire de l'endpoint paie l'inférence. Pour faire coopérer le modèle, il empile des prompts de jailbreak, dont une persona déguisée qui cite GPT-4o. Ses modules visent Django, Laravel et Flask/Werkzeug pour voler bases de données, identifiants et secrets, obtenir une RCE et miner de la crypto. Une boucle que ses opérateurs appellent «Skynet mode» scanne, infecte, déploie des mineurs et réinfecte sur jusqu'à 100 000 étapes sans approbation humaine. Symantec n'a trouvé aucune preuve d'utilisation dans de vraies attaques. Un endpoint LLM sans authentification est déjà l'infrastructure de quelqu'un d'autre.
CVE-2026-116176 (CVSS 8.2) : un header X-Request-Id fait fuiter à vLLM son NCCL ID et des tenseurs de KV-cache, et 9 autres CVE arrivent
Dix CVE ont été attribuées à vLLM le 25 octobre. La plus sérieuse est CVE-2026-116176 (CVSS 3.1 8.2, v4 8.8) : l'API accepte une adresse de decode dans le header X-Request-Id, et un worker de prefill utilisant P2pNcclConnector ouvre une connexion ZMQ vers l'hôte de l'attaquant, sans authentification. Résultat : fuite du unique_id NCCL et de tenseurs de KV-cache (donc des données de prompts d'autres utilisateurs), ou un worker bloqué. Les versions 0.9.2 à 0.24.0 (exclue) sont touchées. Le reste du lot est du DoS : bombes de décompression audio et image (Nemotron-VL désactive la limite de pixels), num_frames=-1 qui contourne le plafond de frames, et des valeurs de top_n, des token IDs et des stop_token_ids hors limites qui font planter EngineCore. Les correctifs sont dans des versions déjà publiées ; si vous faites du prefill/decode désagrégé, vérifiez que vous êtes en 0.24.0 ou plus.
CVE-2026-115886 : l'endpoint de scorers de MLflow, sans authentification, instancie la classe demandée et la transforme en SSRF
Le tracking server de MLflow expose POST /ajax-api/3.0/mlflow/scorer/invoke sans authentification. Le handler instancie par réflexion une classe nommée par l'attaquant dans le JSON, avec des kwargs de constructeur sans contrainte ; l'allowlist ne vérifie que le module, pas l'attribut ni ses arguments. Avec les paquets optionnels trulens et trulens-providers-litellm installés, cela suffit pour que le serveur envoie des requêtes HTTP vers n'importe quel hôte avec des headers choisis par l'attaquant (CVSS 3.1 6.5). Les versions 3.12.0rc0 à 3.17.0 (exclue) sont touchées. Si votre MLflow est sur un réseau qui atteint les métadonnées cloud ou des services internes, mettez à jour et placez une authentification devant.
CVE-2026-115883 : dans les stores Postgres et SQLite de LangGraph, un point dans un namespace atteint la mémoire d'un autre tenant
Les stores de LangGraph enregistrent un namespace comme ses labels joints par ., donc ("tenant", "bob") et ("tenant.bob",) aboutissent au même endroit. put rejetait les labels contenant un point, mais pas get, search, delete, list_namespaces, leurs versions async ni les opérations passées à batch/abatch. Quiconque contrôle un label peut lire, écraser ou supprimer des éléments d'un autre namespace, là où beaucoup d'agents stockent la mémoire long terme par utilisateur (CVSS v4 6.0). Corrigé dans langgraph-checkpoint-postgres 3.1.3 et langgraph-checkpoint-sqlite 3.1.2. Si vous construisez des namespaces à partir d'IDs fournis par l'utilisateur, mettez à jour et validez ces IDs malgré tout.
CVE-2026-77366 (CVSS 9.9) et CVE-2026-77363 (9.6) : le serveur MCP obsidian-tc laissait n'importe quel token, ou n'importe quelle page web, toucher n'importe quel vault
obsidian-tc, un serveur MCP qui donne aux agents l'accès à des vaults Obsidian, a publié sept advisories d'un coup. Les deux critiques : dans CVE-2026-77366 (9.9), le dispatch des outils ne comparait jamais le input.vault de l'appelant au vault lié à son token, et le JWT ne portait aucun claim de vault, si bien que tout token valide pouvait lire, écrire ou supprimer n'importe quel vault configuré via ~90 outils. Dans CVE-2026-77363 (9.6), le transport Streamable HTTP n'avait aucune protection contre le DNS rebinding et ne validait pas Origin ; avec le défaut documenté auth.mode: "none" en loopback, n'importe quelle page web pouvait faire POST http://127.0.0.1/mcp et obtenir les scopes ["*"]. Les deux sont corrigées en 1.3.1. Un serveur MCP local sans authentification est une API ouverte à chaque onglet de votre navigateur.
CVE-2026-115477 : dans obsidian-tc, répondre «non» à la confirmation humaine n'arrêtait pas l'outil destructif
Le même lot obsidian-tc contient une faille de human-in-the-loop (CVSS v4 7.1). Sur les déploiements Streamable HTTP avec JWT, un outil marqué destructive: true demande une confirmation via elicitation, mais le serveur prenait le requestState signé pour une preuve d'approbation, alors que cet état est émis avant que l'humain soit interrogé. Si le client renvoyait l'état valide, l'appel s'exécutait même avec une réponse decline, cancel, absente ou malformée ; les mainteneurs ont reproduit une écriture après un refus explicite. Les versions 1.13.0–1.31.3 sont touchées, correction en 1.31.4. Leçon pour quiconque implémente du HITL sur MCP : l'approbation doit être la réponse de l'humain, pas un token qui prouve seulement qu'il s'agit du même appel.
CVE-2026-115419 (CVSS 8.6) : le serveur A2A de Strands Agents partageait l'historique de conversation entre appelants
Le serveur Agent2Agent (A2A) du SDK Strands Agents (Python strands-agents et TypeScript @strands-agents/sdk) n'isolait pas l'état entre appelants ayant des context_id différents. Dans les déploiements multi-tenant, un utilisateur authentifié pouvait lire l'historique d'un autre et orienter ce que le modèle répond aux autres : context bleed plus prompt injection entre sessions (CWE-488, CVSS v4 8.6). Tout serveur A2A accessible à plus d'un utilisateur est concerné. Corrigé dans strands-agents 1.43.0 et @strands-agents/sdk 1.5.0.
FastMCP : un outil transformé échappait à sa politique d'autorisation lors des appels directs
Dans FastMCP, un transform côté serveur peut modifier les métadonnées sur lesquelles repose la politique d'autorisation d'un composant. Les lookups directes vérifiaient le composant d'origine mais renvoyaient le composant transformé sans nouvelle vérification ; un client connaissant l'identifiant pouvait donc invoquer un outil ou lire une ressource ou un prompt refusé par la politique (CVSS 3.1 6.8, pas encore de CVE). Le correctif autorise les composants finaux transformés, et une ressource concrète refusée masque désormais tout template correspondant à son URI, pour qu'un proxy ne puisse pas la récupérer en amont. Sont touchés fastmcp et fastmcp-slim 3.0.0–3.4.9 et 4.0.0–4.1.1 ; passez en 3.4.10 ou 4.1.2.
FastMCP 4.x : un serveur MCP malveillant pouvait récupérer votre client secret OAuth
Les wrappers client ClientCredentialsOAuthProvider et PrivateKeyJWTOAuthProvider de FastMCP 4.x ne liaient pas les identifiants pré-enregistrés à l'issuer qui les possède. Un serveur MCP compromis ou non fiable pouvait annoncer un autre authorization server et recevoir le client secret ou une assertion signée (CVSS 3.1 5.9, pas encore de CVE). Les clés de signature ne quittent jamais la machine, mais la réutilisation d'une assertion dépend de la politique d'audience. 4.1.2 ajoute issuer aux deux providers, exige le MCP SDK 2.2.0 et supprime les refresh credentials des tokens rechargés. La série 3.x n'inclut pas ces wrappers.
Tendances Notables
Le contrôle humain et le monitoring des agents échouent pour la même raison : ils dépendent de points de contrôle que l'agent ou le client peut éviter. Les compactions d'OpenAI laissaient du trafic non surveillé, et le requestState d'obsidian-tc valait approbation même quand l'humain disait non. Une garantie qui n'est pas sur le chemin obligatoire de chaque action n'en est pas une.
L'isolation multi-tenant est le point faible de la stack des agents : Strands A2A mélangeait les sessions, LangGraph les namespaces et obsidian-tc les vaults. Les trois avaient une authentification ; aucun ne liait la ressource demandée à l'identité qui la demandait.