Vulnerabilidades de seguridad de MCP: comprueba si estás afectado antes de aplicar el parche

Cuando aparece una vulnerabilidad MCP en tu feed, la primera pregunta operativa no es «¿qué gravedad tiene el titular?», sino: ¿afecta este aviso a un componente que realmente se está ejecutando en mi ruta de agente? Responde a eso antes de ejecutar un exploit, actualizar en masa todos los paquetes o dar por suficiente un análisis que no haya detectado nada. Un veredicto defendible se basa en cinco pruebas: 1. la identificación exacta del aviso y del paquete; 2. la versión instalada y ejecutada ; 3. el resultado del editor del aviso sobre el rango afectado; 4. la accesibilidad del punto de entrada vulnerable y cualquier medida de mitigación temporal; 5. una herramienta de evaluación posterior a la remediación, además de un justificante del resultado previsto de la tarea. Esa unión da como resultado un pequeño conjunto de estados útiles: absent , unknown , not affected , affected not reachable , exposed , patched unverified , remediation regression o remediated . Además, evita dos atajos peligrosos: considerar la presencia del paquete como una exposición confirmada y considerar un comando de actualización realizado con éxito como una recuperación. Crea la unión de exposición antes de elegir la respuesta Un catálogo de vulnerabilidades resulta útil para la detección, pero no es tu inventario en tiempo de ejecución. El aviso de seguridad puede mencionar un paquete que solo aparece en un archivo de bloqueo, en un entorno abandonado, en una capa de contenedor que nunca se ejecuta o en una dependencia transitiva de desarrollo. El caso contrario es aún peor: un cliente MCP puede ejecutar un paquete a través de un envoltorio o una instalación global que el análisis de tu repositorio nunca haya inspeccionado. Recopila las pruebas del entorno de ejecución al que pertenece el proceso MCP. No subas mensajes de solicitud, argumentos de herramientas, tokens, rutas absolutas ni datos empresariales. Un resumen conciso podría tener este aspecto: El matchStatus debe proceder de un gestor de paquetes, una herramienta SBOM o una fuente de avisos estructurada que comprenda la sintaxis de versiones del ecosistema. No compares las cadenas de versión de forma léxica. El aviso revisado GitHub para mcp remote , por ejemplo, registra = 0.0.5, < 0.1.16 como afectado y 0.1.16 como la primera versión parcheada. El aviso revisado para @modelcontextprotocol/server filesystem contiene tanto una gama heredada como una línea basada en fechas, siendo 2025.7.1 la primera versión actualizada de dicha línea. Un comparador escrito a mano no es el lugar adecuado para normalizar ambos esquemas. La información sobre el paquete y la versión sigue sin determinar la accesibilidad. La versión actual Prácticas recomendadas de seguridad para MCP ilustra por qué es importante la configuración. Su análisis del «agente confundido» enumera varias condiciones que deben darse simultáneamente, entre ellas: el uso de un proxy con un identificador de cliente estático de terceros, el registro dinámico de clientes, una cookie de consentimiento y la ausencia de consentimiento por cliente. La misma guía y el Especificaciones de autorización de MCP Prohibir el reenvío de tokens y exigir al servidor de recursos que compruebe que se ha emitido un token para dicho recurso. Esos controles deberían convertirse en campos de un informe específico de la exposición, y no en una casilla de selección genérica del tipo «seguridad habilitada». En el caso de un aviso de autorización, recopila la validación de la audiencia, la correspondencia de redireccionamientos, la titularidad del consentimiento y el comportamiento del proxy. En el caso de un aviso sobre el sistema de archivos, recopila la versión del servidor ejecutado, los directorios raíz permitidos, la superficie de herramientas accesible y la medida de mitigación exacta que hace que el punto de entrada afectado quede indisponible. En el caso de un aviso sobre inyección de comandos, recopila el envoltorio del cliente, la versión, el límite de confianza del servidor remoto y si se puede invocar esa ruta de conexión. Un componente afectado con un punto de entrada desactivado y verificado es affected not reachable , no not affected . Se trata de una prueba útil de contención, pero tiene una vigencia limitada. Anota quién es el responsable y la fecha límite para aplicar el parche, ya que una modificación de la configuración, una reversión de la implementación o un nuevo cliente pueden hacer que la ruta vuelva a ser accesible. Ejecuta un clasificador sin contenido, no un exploit No es necesario que la carga útil sea maliciosa para gestionar el incidente. La siguiente regla de decisión es deliberadamente conservadora: Los nombres de los estados determinan la siguiente decisión: Estado Lo que demuestran las pruebas Próxima acción limitada absent El componente indicado no está presente en el límite de tiempo de ejecución inspeccionado. Registrar el alcance del inventario y el cierre para este ámbito unknown Falta la identidad, la versión, la coincidencia de aviso o la accesibilidad, o bien hay un conflicto entre ellas Mantener la incertidumbre; completar el primer campo que falta not affected El componente instalado no se encuentra dentro del rango afectado por el editor. Conserva el origen y la frescura; no des por sentado que un envase con un nombre similar ofrece protección. affected not reachable El código afectado existe, pero el punto de entrada indicado está bloqueado por una contención verificada. Mantener la contención, asignar un responsable del parche y establecer una fecha de caducidad exposed La versión afectada y el punto de entrada accesible coinciden Limitar el acceso, revocar los permisos innecesarios y aplicar parches patched unverified La versión ha quedado fuera de alcance, pero los indicios funcionales son incompletos Ejecuta una prueba con la herramienta «Canary» de forma segura y comprueba que el destino sea el esperado. remediation regression El parche o la contención ha dañado la herramienta o el resultado requerido. Limita el alcance de la ruta de riesgo; restablece la compatibilidad o utiliza una versión anterior revisada remediated La versión, el comportamiento seguro de la herramienta y el resultado previsto cumplen los requisitos. Controla la frescura y cierra la operación con el recibo de entrega Apliqué esa regla a ocho casos sin contenido, uno por cada estado. Los ocho coincidieron con el resultado esperado. El caso problemático es el más valioso: @modelcontextprotocol/server filesystem figura en la versión parcheada del aviso, pero la comprobación de seguridad de la herramienta falla. El clasificador devuelve remediation regression , en lugar de remediated . Esa distinción es importante porque las tareas de seguridad pueden provocar un incidente relacionado con el estado del agente. Una actualización de dependencias puede modificar un comando de ejecución, un esquema de capacidades, un acceso root permitido, un flujo de OAuth o la compatibilidad con los clientes. Es posible que el código vulnerable haya desaparecido, pero que las funciones necesarias del agente sigan sin funcionar correctamente. El recibo tiene algunas limitaciones. No demuestra que un exploit desconocido no pueda afectar al componente. No sustituye a las pruebas forenses tras una sospecha de compromiso. Además, depende de que la identidad del paquete sea precisa y de que los datos de los avisos de seguridad estén actualizados; si dos fuentes discrepan, devuelve unknown y conserva ambas referencias. El Registro NVD correspondiente a CVE 2025 6514, por ejemplo, ofrece un registro adicional con fecha sobre el problema de inyección de comandos mcp remote , pero el rango de paquetes debe seguir estando vinculado al aviso revisado exacto que utilice tu sistema de comparación. Aplicar un parche siguiendo una secuencia que preserve el estado del agente Las medidas de contención y de remediación requieren autorizaciones independientes, ya que sus radios de explosión son distintos. Una secuencia práctica es la siguiente: 1. Identificación de congelación. Anota el ID del aviso, el paquete, la versión lanzada, el propietario del cliente o del servidor y la hora de la prueba. 2. Contiene la ruta indicada. Desactiva el servidor, la conexión remota, la herramienta o la ruta de autorización vulnerables con el menor cambio reversible posible. 3. Reducir los privilegios. Revocar las credenciales y los permisos innecesarios asociados a ese componente. Rotar un secreto solo cuando haya indicios de exposición o así lo exija la política; la rotación puede destruir pruebas útiles y provocar interrupciones del servicio no relacionadas. 4. Instala la corrección recomendada por el desarrollador. Utiliza la línea con el parche específico, no una versión más reciente cualquiera, y mantén el resultado del gestor de paquetes. 5. Reinicia el propietario real. No basta con actualizar un archivo de bloqueo o una etiqueta de imagen si un cliente de agente que lleva mucho tiempo en ejecución sigue siendo el propietario del proceso antiguo. 6. Realiza una prueba de seguridad de la herramienta. Utiliza un objetivo sintético con el mínimo de privilegios. No repitas el exploit ni dirijas el «canario» hacia los datos de producción. 7. Comprueba el resultado final. Confirma que el archivo, el ticket, el registro, el mensaje u otro resultado esperado existe y es correcto. 8. Vigila la ventana de estabilidad. Comprueba que el componente siga estando accesible cuando se espera, que no vuelva a entrar en el rango de vulnerabilidad y que no falle repetidamente tras la aplicación del parche. Mantén la sonda de la herramienta separada del recibo de resultado. Una herramienta del sistema de archivos puede indicar que la operación se ha realizado con éxito aunque haya escrito en la raíz permitida incorrecta. Una herramienta de tickets puede aceptar una solicitud aunque el registro sea rechazado posteriormente. Un transporte MCP puede seguir en buen estado aunque falte el resultado del agente. El primer recibo demuestra que la función reparada puede ejecutarse de forma segura; el segundo demuestra que el trabajo del usuario ha llegado realmente a su destino. Cierra el incidente solo cuando las pruebas más sólidas de las que se disponga coincidan: el aviso ya no se corresponde con el componente lanzado, la ruta que antes era vulnerable está controlada, la prueba «canario» de seguridad se supera y se ha alcanzado el resultado previsto. Si algún campo está desactualizado o presenta contradicciones, mantén el estado explícito en lugar de marcarlo en verde. Sidewisp se encuentra actualmente en versión preliminar privada. Su orientación de producto consiste en una capa de salud para los entornos de ejecución de agentes existentes: mostrar pruebas concretas, distinguir entre estado activo, en espera o bloqueado, mantener la aprobación humana en el límite de la acción y verificar los resultados tras la intervención. La experiencia pública actual es una demostración de acceso anticipado, no un escáner MCP, un adaptador de supervisión ni un motor de recuperación automatizada ya lanzados al mercado.