Vulnerabilidad del intérprete de validación de flujos de trabajo MCP: el aviso real
No pudimos confirmar la vulnerabilidad del intérprete de validación MCP buscada; aquí está el aviso real de OAuth de GitHub que verificamos y qué hacer ahora.
Comprobado con las fuentes citadas el .
Lo que la búsqueda de la vulnerabilidad del intérprete de validación de flujos de trabajo MCP pretendía cubrir
Si llegaste aquí buscando una vulnerabilidad del intérprete de validación de flujos de trabajo MCP, probablemente estés buscando un anuncio de seguridad de GitHub fechado el 30 de septiembre de 2026, titulado "Mutación de prototipo compartido a través del intérprete de validación de flujos de trabajo de MCP permite la apropiación de la cuenta propietaria". Buscamos ese anuncio exacto en las fuentes oficiales de GitHub y no pudimos confirmar que exista con ese título, esa fecha, ni con una mutación de prototipo compartido como mecanismo de explotación. Este artículo lo declara con claridad y a continuación informa sobre el aviso de seguridad de GitHub real y verificado que encontramos en esa misma ventana de tiempo.
Los términos de búsqueda que los lectores usan para este tema también incluyen un aviso de seguridad del intérprete MCP, apropiación de cuenta propietaria en MCP, y un exploit de mutación de prototipo compartido. Ninguna de nuestras fuentes oficiales coincide con esa combinación específica. Lo que sí verificamos es un aviso diferente y real para el SDK oficial de Python del Model Context Protocol (MCP), publicado por sus propios mantenedores, que es el tema del resto de este artículo.
Por qué esto no es la vulnerabilidad del intérprete de validación de flujos de trabajo MCP que buscabas
Nuestra regla para este tipo de artículo es tratar el anuncio exacto nombrado como la única fuente aceptable para sus propios detalles, como las versiones afectadas, la versión corregida y los pasos de remediación. Tras revisar las fuentes oficiales de GitHub en busca del título solicitado, "Mutación de prototipo compartido a través del intérprete de validación de flujos de trabajo de MCP permite la apropiación de la cuenta propietaria", fechado el 30 de septiembre de 2026, no encontramos ningún documento que coincida, lo que significa que ninguna fuente oficial confirma esta vulnerabilidad exacta del intérprete de validación de flujos de trabajo MCP bajo ese título o esa fecha. Pensamos que publicar detalles tomados de un aviso distinto y no coincidente sería peor que no publicar nada, porque un equipo podría aplicar la corrección equivocada y sentirse falsamente tranquilo.
El documento oficial más cercano que encontramos en esa misma ventana es un aviso de seguridad de GitHub para el proyecto modelcontextprotocol/python-sdk, publicado el 28 de septiembre de 2026, dos días antes de la fecha solicitada. Su propio texto describe un cliente OAuth que puede enviar credenciales a un servidor de autorización elegido por el servidor MCP, no un exploit de mutación de prototipo compartido dentro de un intérprete de validación de flujos de trabajo. Como es el documento real que pudimos verificar, la siguiente sección lo reporta como la actualización real, siendo explícitos en que no corresponde al título ni al mecanismo originalmente solicitados.
El aviso real de GitHub que encontramos: redirección de credenciales OAuth en el MCP Python SDK
GitHub publicó este aviso, titulado "El cliente OAuth podía enviar credenciales a un servidor de autorización elegido por el servidor MCP", el 28 de septiembre de 2026, para el paquete mcp distribuido en PyPI por los mantenedores del Model Context Protocol Python SDK. El aviso establece que las versiones afectadas del soporte de cliente OAuth del SDK no validaban la identidad declarada del servidor de autorización en todas las rutas de descubrimiento, y no vinculaban las credenciales de cliente almacenadas o preaprovisionadas al servidor de autorización al que pertenecen. Indica que un servidor MCP malicioso o comprometido podría usar esta brecha para redirigir esas credenciales, incluyendo un secreto de cliente, un código de autorización o un verificador PKCE, hacia un endpoint de token de su propia elección.
Según el aviso, esto afecta a las aplicaciones que usan el SDK como cliente MCP sobre HTTP a través de OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, o el obsoleto RFC7523OAuthClientProvider de la serie 1.x, cuando ese cliente pudiera conectarse a un servidor MCP en el que no confía plenamente mientras posee credenciales de un servidor de autorización real. El aviso indica que las versiones 1.9.1 a 1.29.1 carecían de la verificación en todas las rutas, mientras que las versiones 2.0.0 a 2.1.1 carecían de ella solo en una ruta de respaldo heredada. Añade que los servidores MCP construidos con el SDK, los clientes basados en stdio, y los clientes que adjuntan sus propios tokens o encabezados no están afectados.
La corrección del aviso consiste en actualizar a la versión 2.2.0 o posterior en la línea 2.x, o a la 1.30.0 o posterior en la línea 1.x. Señala que actualizar por sí solo no cierra por completo la brecha para los dos proveedores basados en credenciales: un equipo también debe pasar un valor de issuer explícito, ya que sin él el cliente sigue a cualquier servidor de autorización que anuncie el servidor MCP conectado. El aviso llama a esto, por ahora, una advertencia de obsolescencia, que se convertirá en una configuración obligatoria en una futura versión 3.0.
| Línea del SDK | Versiones afectadas | Versión corregida | Brecha descrita por el aviso |
|---|---|---|---|
| 2.x | >=2.0.0a1, <2.2.0 | 2.2.0 | Verificación de issuer faltante en rutas donde el servidor no publicó metadatos de recursos protegidos |
| 1.x | >=1.9.1, <1.30.0 | 1.30.0 | Sin verificación de issuer ni vinculación de credenciales en ninguna ruta de descubrimiento |
Para la remediación, el aviso indica a los equipos que eliminen cualquier registro de cliente OAuth almacenado antes de actualizar, ya que un registro guardado sin un issuer permanece sin vincular, condición que afirma cubre todo lo almacenado por la línea 1.x antes de la versión 1.30.0. También establece que un cliente que pudiera haberse conectado a un servidor MCP no confiable antes de la corrección debería rotar su secreto de cliente y revocar sus tokens en el servidor de autorización. En las versiones anteriores a la corrección, el aviso dice que no hay solución alternativa salvo conectar los clientes habilitados para OAuth únicamente a servidores MCP ya confiables.
Solo como contexto, las propias notas de versión de los mismos mantenedores para la versión 2.2.0 del SDK, publicadas el 7 de septiembre de 2026, describen el cambio de código correspondiente como una verificación del issuer declarado del servidor de autorización en todas las rutas de descubrimiento, incluida una ruta heredada que antes omitía la verificación. Usamos esta nota de versión aquí solo para explicar el tipo de cambio de código que asumen los pasos de remediación del aviso, no como una fuente separada de hechos sobre la vulnerabilidad misma.
El aviso no menciona a n8n, ninguna edición de n8n, ni n8n Cloud; nombra únicamente el paquete de Python mcp, y no indica un identificador CVE ni si otros productos incluyen este SDK en su empaquetado. Aquí informamos solo lo que el aviso no aborda, ya que se trata de una limitación declarada y no de algo que otra fuente pueda completar. Este sigue siendo el documento oficial verificado más cercano a la vulnerabilidad del intérprete de validación de flujos de trabajo MCP originalmente solicitada, no una coincidencia confirmada de la misma. En nuestra opinión, una actualización de seguridad solo es procesable cuando su alcance está delimitado con esta precisión, que es exactamente lo que hace que un aviso específico sea más útil que una advertencia vaga.
Sources: OAuth client could send credentials to an authorization server chosen by the MCP server · Advisory · modelcontextprotocol/python-sdk · GitHub, Release v2.2.0 · modelcontextprotocol/python-sdk · GitHub
Qué deben hacer los equipos de n8n ahora, y qué deja abierto el aviso
Dado que el aviso no dice nada sobre n8n, el resto de esta sección ofrece nuestras propias sugerencias editoriales para los equipos que conectan n8n con herramientas MCP externas.
Sugerimos, de forma independiente a cualquier recomendación del aviso, que cualquier equipo que conecte n8n con servidores MCP externos a través de clientes de chat de IA verifique si su herramienta MCP depende del código de cliente OAuth de este SDK, y, de ser así, confirme qué versión está en ejecución antes de asumir que la corrección no aplica.
Hasta que un equipo confirme su propia exposición, comprobaciones sugeridas:
Para los equipos que quieran practicar de forma estructurada la inspección crítica de una integración MCP antes de confiar en ella en producción, el reto de servidor MCP de n8n Balloon Challenges guía la construcción de un servidor MCP en n8n que los clientes de IA pueden descubrir y a través del cual pueden llamar herramientas, lo cual es una forma de desarrollar ese hábito de escrutinio.
