CVE de MCPHub señala un fallo en el reenvío de cabeceras; v1.1.8 ya estaba publicada
CVE-2026-120323 atribuye a MCPHub una divulgación de información por passthroughHeaders en versiones hasta 1.0.45 y 1.1.7. El registro recomienda 1.1.8, publicada antes del aviso, aunque sus notas no mencionan esta corrección.
El CVE-2026-120323 atribuye a MCPHub una divulgación de información ligada a passthroughHeaders, una función de la que el registro público ofrece pocos detalles. La ficha marca como afectadas las versiones 1.0.0–1.0.45 y 1.1.0–1.1.7, recomienda actualizar a 1.1.8 y considera esta última versión no afectada. El CVE se publicó el 2 de noviembre; la versión recomendada ya aparecía en el repositorio del proyecto desde el 21 de octubre.
El dato operativo es más concreto que el relato técnico: el CVE describe una posible filtración remota, pero no aclara qué cabeceras quedarían expuestas, qué configuración activa el fallo ni qué datos habría visto un tercero. VulDB, la CNA que publicó el registro, asigna 4,3 en CVSS 3.1 y marca interacción del usuario como necesaria; ese vector sirve para priorizar, no para completar por nuestra cuenta los pasos que faltan. Tampoco hay en la ficha víctimas, incidentes ni evidencia de explotación observada.
-SecureCrew dice: el vector de una CVE orienta la investigación; no es una licencia para rellenar con imaginación los huecos del informe.-
Una corrección anterior a la ficha pública
La cronología evita una confusión habitual: CVE nuevo no significa parche nuevo. GitHub muestra MCPHub v1.1.8 publicado el 21 de octubre, doce días antes de que el registro CVE apareciera el 2 de noviembre. La ficha de vulnerabilidad presenta esa versión como no afectada y señala el commit 040f7b9 como parche, de modo que la actualización no nació con la noticia de hoy.
Hay, sin embargo, una pieza que conviene leer con cuidado: las notas públicas de v1.1.8 no mencionan este problema de seguridad. Enumeran cambios de cuenta, parámetros de herramientas y dependencias, pero no explican CVE-2026-120323 ni el tratamiento de passthroughHeaders. Eso no invalida por sí solo el dato de la CNA —los registros pueden describir una corrección sin que las notas de versión la destaquen—, pero sí deja menos contexto del que agradecería quien tenga que demostrar qué build desplegó y qué cambió.
-SecureCrew dice: que el número de versión sea anterior al CVE es buena noticia; que el changelog calle sobre el parche merece una comprobación, no una teoría.-
Qué revisar en una instalación
Para quienes mantienen MCPHub, la primera comprobación es la versión exacta en ejecución. Si sigue en los rangos citados, la CNA recomienda 1.1.8; antes de cerrar el hallazgo, conviene confirmar en el repositorio que el artefacto instalado corresponde a la versión que el registro marca como corregida. No hace falta convertir la publicación en una migración a ciegas: la noticia no detalla compatibilidades, requisitos de configuración ni consecuencias de actualización.
La segunda revisión es la configuración de cabeceras reenviadas y los destinos upstream, especialmente si una integración pasa valores que puedan identificar una sesión o autenticar una llamada. El registro no dice cuáles son esos valores, así que no se puede afirmar que se hayan expuesto tokens o cookies en una instalación concreta. Si existe telemetría de solicitudes hacia los servidores conectados, revisar el periodo previo a la actualización puede ayudar a acotar el riesgo; su ausencia tampoco demuestra que no ocurriera exposición.
El aviso tampoco ofrece una mitigación temporal distinta de actualizar ni confirma explotación activa. La acción proporcionada es cerrar el desfase de versión y dejar evidencia del artefacto instalado, mientras se valida cualquier efecto sobre los flujos que dependan del reenvío de cabeceras. Para una plataforma que conecta herramientas y servicios, esa comprobación importa porque una cabecera aceptada en el lado entrante puede acabar en otro sistema; el punto es verificar el recorrido real, no presumir que todo MCPHub filtró información.
La noticia es, por tanto, útil para equipos que mantengan ramas antiguas, pero requiere atribución precisa. La CNA registra la vulnerabilidad, enumera 1.1.8 como no afectada y relaciona un commit con la corrección; el proyecto publicó esa versión antes del CVE, aunque no lo explica en sus notas. Esa diferencia permite actuar sin presentar la fecha de divulgación como fecha del parche ni convertir una descripción escueta en prueba de una brecha.
Diccionario de la Crew
CNA — Organización autorizada para asignar y publicar registros CVE.
CVSS — Sistema que puntúa la severidad técnica de una vulnerabilidad; no confirma explotación ni mide por sí solo el riesgo de un despliegue.
MCPHub — Proyecto que agrupa y conecta servidores del Model Context Protocol (MCP).
Upstream — Servicio o servidor al que una plataforma reenvía una solicitud.
