CVE-2026-75130: el servidor de documentación MCP de Context7 obtiene una puntuación de 9.0, y el registro no indica ninguna versión corregida

El 18 de agosto de 2026, VulnCheck publicó CVE-2026-75130 contra Context7, el servidor de documentación de bibliotecas que Upstash ejecuta para el Model Context Protocol y que los agentes de programación consultan para obtener documentación específica por versión. La falla reside en la función que Upstash llama Custom AI Instructions: el propietario de una biblioteca adjunta orientaciones a una entrada de documentación, Context7 sirve esas orientaciones en la ventana de contexto de cada agente que consulta la biblioteca, y nada en esa ruta las sanea. Noma Security, cuyo investigador sénior de vulnerabilidades de IA, Eli Ainhorn, figura como descubridor, demostró que una entrada envenenada puede hacer que un agente conectado lea archivos .env en la raíz del proyecto, envíe su contenido a un repositorio de GitHub que controla el atacante como una incidencia, y elimine carpetas locales con el pretexto de una “limpieza” — todo a partir de una solicitud de documentación rutinaria. No se registra ninguna víctima. El resto de los incidentes documentados de agentes, cada uno con su propia gravedad, grado de confianza e indicador de disputa, figura en el archivo de incidentes de IA, donde las entradas vecinas de este registro pueden leerse junto a él.

El servidor de Context7 es pequeño, y esa es la parte que conviene entender primero. El artículo de Noma señala que expone dos herramientas, resolve-library-id y query-docs, y que no puede ejecutar código, escribir archivos ni acceder a la red por sí mismo. Todo impacto documentado lo lleva a cabo el agente del otro lado, que sí tiene acceso al sistema de archivos, al shell y a la red en la máquina del desarrollador. El registro de npm muestra lo grande que es la base instalada: @upstash/context7-mcp se descargó 4,064,176 veces en los treinta días comprendidos entre el 22 de julio y el 20 de agosto de 2026, la ventana en torno a la publicación.

El mecanismo: una biblioteca envenenada, cada agente que la consulta

La demostración de Noma, descrita en su informe de ContextCrush del 5 de marzo de 2026, se desarrolló en tres pasos que ejecuta el agente en lugar del servidor. Registró una biblioteca en el registro de Context7 con reglas envenenadas adjuntas. Las instrucciones de esas reglas indicaban al agente que buscara y leyera cada archivo .env en la raíz del proyecto; otras instrucciones le indicaban que publicara el contenido como una incidencia en un repositorio de GitHub controlado por el atacante; un último conjunto le indicaba que eliminara carpetas y archivos locales para la “limpieza”. La solicitud que hace que todo esto entre en contexto es una solicitud corriente: pedirle a un asistente de programación ayuda con una biblioteca.

La razón por la que esto es un problema de cadena de suministro y no una inyección de prompts ordinaria está en dónde reside la carga útil. El atacante nunca llega a la máquina de la víctima y nunca tiene que colocar texto en un documento que el usuario abra. Las instrucciones envenenadas están en el propio registro de Context7, están alojadas y servidas por la propia infraestructura de Context7, y llegan por el mismo canal de confianza que la documentación legítima, indistinguibles de ella. Noma señala que la puntuación de confianza de Context7, que califica las bibliotecas según el historial de GitHub que las respalda, no defiende contra esto, porque una cuenta de larga antigüedad puede comprarse, secuestrarse o fabricarse. El propio resumen de la empresa sobre el punto estructural es contundente: «La superficie de ataque no es lo que el servidor MCP puede hacer. Está en lo que puede hacer que haga el agente de IA.»

Dos puntuaciones para un error

El aviso incluye CVSS 3.1 9.0 (crítica) y CVSS 4.0 6.4 (media). Ambos vectores fueron proporcionados por VulnCheck como CNA asignador, y NVD mantiene ambos sin cambios, atribuyendo cada uno a VulnCheck. La discrepancia no es un error; es que los dos marcos contabilizan el mismo daño contra máquinas diferentes. CVSS 3.1 marca Scope como Changed —la inyección cruza del servidor a la máquina del desarrollador y más allá— y por eso registra todo el impacto alto en confidencialidad, integridad y disponibilidad de las capacidades del agente con pleno peso. CVSS 4.0 reemplaza Scope por métricas separadas para el sistema vulnerable y el posterior: no registra ningún impacto en confidencialidad, integridad ni disponibilidad para Context7 en sí (VC:N/VI:N/VA:N) y sí un impacto alto en los sistemas posteriores (SC:H/SI:H/SA:H), que su fórmula pondera menos. El servidor es el mensajero, no la víctima.

La discrepancia se propaga a las bases de datos. El aviso de GitHub, GHSA-97r6-3rgm-v39r, se publicó a las 18:32 UTC del 18 de agosto, media hora después del CVE, y la severidad de su resumen figura como media aunque el vector CVSS 3.1 del mismo registro puntúa 9,0. La EU Vulnerability Database de ENISA refleja la entrada como EUVD-2026-61099 y almacena una puntuación base de 6,4 solo en la versión 4.0. El registro de archivo que sigue este artículo califica el incidente como alto — que no coincide con ninguna de las dos puntuaciones publicadas — y es la calificación del archivo, no una medición propia.

Una CVE publicada en agosto correspondiente a una divulgación de marzo.

El identificador CVE se reservó el 17 de agosto de 2026 y se publicó a las 18:02 UTC del 18 de agosto, que es la fecha que figura en el registro. El contenedor del CNA también incluye una segunda fecha que no aparece en las páginas del agregador: datePublic, 5 de marzo de 2026 — cinco meses y medio antes de que existiera el identificador, y el mismo día en que Noma publicó ContextCrush. La única referencia técnica del aviso es ese artículo de marzo, que VulnCheck etiqueta tanto como descripción técnica como como exploit.

La cronología de divulgación de Noma explica la brecha. En ella se informa a Upstash del fallo el 18 de febrero de 2026 con un informe completo y una prueba de concepto, se registra que Upstash aceptó los hallazgos y comenzó la remediación el 19 de febrero, se indica que una corrección se “desplegó en producción con sanitización de reglas y salvaguardas” el 23 de febrero, y se fijan la divulgación pública y la verificación final por parte de Noma para el 5 de marzo. Según la versión de Noma, el fallo de febrero se resolvió en días.

Las fechas del registro npm se alinean con esa cronología de tal modo que dejan el rango afectado con un aspecto extraño. @upstash/context7-mcp 2.1.2 se publicó el 23 de febrero de 2026 a las 10:06 UTC, el día en que Noma afirma que la corrección llegó a producción; la línea de su registro de cambios dice «Eliminar la advertencia innecesaria y actualizar las descripciones de las herramientas». 2.1.3 siguió el 4 de marzo de 2026, el día antes del informe de Noma, con notas sobre rechazar solicitudes GET en los endpoints MCP y añadir un campo de origen a los resultados de búsqueda. Ninguna de las notas de versión menciona sanitización, salvaguardas ni la inyección. El rango afectado de la CNA termina en 2.1.2, lo que convierte a 2.1.3 en la primera versión fuera de él.

Tres lecturas encajan con esas fechas, y ni VulnCheck ni Noma indican cuál es la correcta. La primera, defendida por Digital Applied en su artículo del 18 de agosto y repetida por AI Security Wire el 22 de agosto, es que la corrección sufrió una regresión: la compilación que contenía el parche de febrero se encuentra dentro del rango afectado de agosto. La segunda es que el rango simplemente está anclado a la compilación que probó el investigador, y que 2.1.3, publicada el día anterior a la divulgación, es el verdadero límite — una inferencia que varios agregadores hacen mecánicamente, incluido Feedly, que enumera «actualizar a la versión 2.1.3 o posterior» como mitigación. La tercera es que la corrección de febrero se aplicó donde se sirven las reglas en lugar de en el paquete cliente, en cuyo caso un rango de versiones de npm no describe la corrección en absoluto. Una corrección de seguridad silenciosa es lo bastante común como para que la ausencia de una entrada correspondiente en el changelog no resuelva nada en ningún sentido.

Qué está establecido y qué no

• Establecido por el registro primario. El identificador CVE, su publicación del 18 de agosto, VulnCheck como CNA, la clasificación CWE-1427 por neutralización indebida de la entrada utilizada para prompts de LLM, el crédito a Eli Ainhorn de Noma Security y un rango afectado de Context7 hasta 2.1.2.

• Establecido por la investigación de Noma. La ruta de inyección a través de Custom AI Instructions, la prueba de concepto de tres pasos, la observación de que el servidor expone solo resolve-library-id y query-docs, y la afirmación de que no se observó evidencia de explotación en la naturaleza para el fallo de febrero.

• Establecido por el registro. La fecha de publicación de 2.1.2, el 23 de febrero de 2026, la fecha de publicación de 2.1.3, el 4 de marzo de 2026, y una línea de paquete que desde entonces ha avanzado más allá de 4.0 hasta 4.4.4, el 19 de octubre de 2026.

• No está establecido: si las compilaciones actuales se ven afectadas. Ninguna fuente afirma que la línea 4.x sea vulnerable, ni que esté libre de vulnerabilidad. El registro CVE, el aviso de VulnCheck y el aviso de GitHub no mencionan ninguna versión corregida, y la lista de rangos de versiones vulnerables del aviso de GitHub está vacía.

• No establecido: ninguna víctima ni uso en el mundo real. El archivo registra como falso el daño real. El enriquecimiento del registro por parte de CISA el 19 de agosto calificó Explotación como «ninguna», Automatizable como «no» e Impacto técnico como «total»; la vulnerabilidad no está en el catálogo KEV; el espejo de ENISA registra un EPSS del 0,49 por ciento. La investigación de Noma es una demostración, no un informe de incidente.

• No establecido: la propia interpretación de regresión. Se basa en una coincidencia de fechas entre una cronología de corrección y una publicación en npm, y ninguna fuente primaria afirma que la misma ruta de código fallara dos veces.

Corroboración: reiteración, y silencio donde importa

Los documentos que concuerdan con el registro derivan en gran medida de él. El boletín de VulnCheck reitera el texto del CVE y añade la clasificación de debilidad y el crédito al investigador. El boletín de GitHub es un alias del mismo envío, publicado la misma noche, sin rangos de versiones y sin revisión independiente. La entrada de ENISA es un espejo. Digital Applied, una de las dos fuentes que cita el archivo, publicó su análisis el 18 de agosto y lo actualizó el 22 de agosto con nuevas extracciones del registro; AI Security Wire publicó un segundo artículo el 22 de agosto. Ambos reiteran el boletín y difunden la inferencia de regresión, y ninguno afirma haberla verificado de forma independiente.

No encontramos ninguna cobertura periodística de la CVE el 29 de octubre de 2026 —ningún artículo de BleepingComputer, The Register o SecurityWeek— y los resultados eran páginas de agregadores de CVE en lugar de reportajes. Esa ausencia importa para cómo debe interpretarse el registro: el archivo lo califica con A, bien documentado con fuentes primarias que concuerdan, y las fuentes primarias efectivamente concuerdan, pero aquí la concordancia se da entre un registro de CNA y la investigación que este cita, no entre dos mediciones independientes. Varias páginas de agregadores añaden afirmaciones que sus fuentes no respaldan; la entrada de Feedly, por ejemplo, afirma que hay un parche disponible y nombra 2.1.3, algo que ningún aviso hace, mientras que la página de VulDB devolvió una verificación antibots en lugar de contenido y no pudo leerse en absoluto.

Qué cambió y qué no

Para el error de febrero, Upstash actuó en cuestión de días: aceptado el 19 de febrero, corregido el 23 de febrero, según el relato de Noma. Para el registro de agosto, la única declaración del proveedor a la que hace referencia el CVE es una publicación de LinkedIn de Upstash, etiquetada allí como aviso del proveedor, cuyo contenido no pudimos leer sin una sesión. Ningún aviso de seguridad de GitHub con alcance al repositorio incluye una versión corregida, y la entrada de NVD figura en estado Diferido sin configuraciones CPE y con una última modificación del 22 de octubre de 2026, por lo que el propio análisis de NVD no consta en el registro.

El paquete siguió distribuyéndose. Entre el 20 de abril de 2025 y el 23 de octubre de 2026, el repositorio upstash/context7 publicó 163 versiones, y ninguna de sus notas menciona esta CVE ni describe la sanitización de las instrucciones personalizadas que portan la inyección. Eso es un registro de lo que los mantenedores eligieron poner por escrito, no una prueba de que no se haya corregido nada.

Lo que el registro deja a un operador es gestión de exposición y no una línea de parches. Las recomendaciones de Noma se centran en revisar las integraciones con MCP e inspeccionar qué circula entre el agente y el servidor en tiempo de ejecución; las acciones sugeridas por OpenCVE son actualizar, deshabilitar o restringir la función Custom AI Instructions y añadir validación de entrada al servidor. La versión operativa de todo ello son los mismos tres movimientos: fijar la versión del servidor MCP en lugar de dejarla flotando en la última, mantener las credenciales de producción fuera de archivos de entorno en texto plano que el agente pueda leer y tratar las respuestas de las herramientas como entrada no confiable en lugar de como documentación que el agente pueda seguir.

Diez semanas después de la publicación, el registro público todavía termina donde terminaba el 18 de agosto: un identificador, dos puntuaciones separadas por dos bandas, un rango afectado cuyo límite superior es una compilación que se distribuyó en febrero, y ninguna corrección identificada. Quien realice el triaje de CVE-2026-75130 tiene que decidir en función de lo que sus agentes pueden alcanzar, porque el registro no les indica qué versión instalar.