HashiCorp, Veeam y Django Software Foundation publicaron a principios de agosto de 2026 correcciones para 11 vulnerabilidades, tres de las cuales son de gravedad crítica. Las más peligrosas son: una suplantación de tokens entre tenants en Terraform MCP Server (CVE-2026-16498, CVSS 10.0), el robo de credenciales de un agente gestionado sin autenticación en Veeam Service Provider Console (CVE-2026-58073, CVSS 9.5) y la escritura de archivos con posible ejecución de código a través de GeoDjango (CVE-2026-15307). Los parches están disponibles para: Terraform MCP Server 1.1.0+, Veeam VSPC 9.3.0.35057, Django 6.0.8 / 5.2.17. Ninguna de las vulnerabilidades figuraba en el catálogo CISA KEV ni contaba con un exploit público en el momento de la publicación; sin embargo, la dependencia de cada una respecto a la configuración requiere evaluar de forma individual su aplicabilidad.
Veeam VSPC: suplantación de agente y escritura arbitraria de archivos
El boletín de seguridad de Veeam del 4 de agosto describe cuatro vulnerabilidades corregidas en la build 9.3.0.35057 (publicada el 29 de julio). Se ven afectadas todas las builds de la versión 9 hasta la 9.2.1.33875 incluida.
El problema principal es CVE-2026-58073 (CVSS 9.5 según la escala CVSS 4.0): un atacante no autenticado puede suplantar a un agente gestionado y obtener sus credenciales. Pese a no requerir autenticación, el vector CVSS indica una alta complejidad de ataque: no se trata de un exploit trivial de un solo clic. La segunda vulnerabilidad crítica, CVE-2026-58072 (CVSS 9.0), permite a un usuario con privilegios bajos efectuar escritura arbitraria de archivos en el servidor de gestión, con una posible escalada hacia Remote Code Execution (RCE).
Dos vulnerabilidades de alta gravedad completan el conjunto:
- CVE-2026-58067 — Denial of Service (DoS) por agotamiento de memoria sin autenticación;
- CVE-2026-58071 — exposición temporal del API de dispositivo proxificado con privilegios de Portal Administrator tras el inicio de una sesión de administrador.
Este es ya el segundo ciclo de parches críticos para VSPC en tres meses. En mayo, Veeam corrigió CVE-2026-32998 (CVSS 9.4), Remote Code Execution a través del mecanismo de ejecución de scripts de alertas. Para las organizaciones que utilizan VSPC como plataforma de gestión de las copias de seguridad de clientes, la repetición de vulnerabilidades críticas configura un patrón de riesgo persistente que exige dar prioridad a las actualizaciones.
Terraform MCP Server: el token de un tenant da acceso a todos
HashiCorp reveló el 28 de julio tres vulnerabilidades relacionadas en el transporte Streamable HTTP del servidor Terraform MCP, que conecta asistentes de IA con Terraform mediante Model Context Protocol. La corrección está disponible en la versión 1.1.0 (publicada el 14 de julio) y posteriormente en la 1.2.0 (4 de agosto). Los despliegues en modo stdio (modo local monousuario) no están afectados: las vulnerabilidades se limitan exclusivamente al modo HTTP multiusuario, que HashiCorp promovió al anunciar la disponibilidad general (GA) en junio.
CVE-2026-16498 (CVSS 10.0) es la más grave de las tres. En el modo HTTP stateless, la biblioteca base de MCP no asigna identificadores de sesión únicos, y la caché de credenciales del servidor utilizaba precisamente esos identificadores para separar a los usuarios. Resultado: el token de Terraform de un usuario podía aplicarse a las peticiones de usuarios posteriores, con independencia del token que estos proporcionaran. Es un caso clásico de ruptura de aislamiento entre tenants cuyo origen está en una suposición errónea sobre el comportamiento de la capa de abstracción subyacente.
CVE-2026-16496 (CVSS 8.9) presenta un problema de aislamiento similar, pero en el modo stateful, que es el modo predeterminado para los despliegues centralizados. La caché utilizaba el identificador de sesión MCP como única clave de búsqueda, sin vincular el cliente en caché al token que lo había creado. Un atacante que obtuviera el identificador de sesión de otro usuario podía realizar llamadas de herramientas usando el cliente de la víctima y acceder a los recursos permitidos por el token de la víctima. Esta vulnerabilidad fue descubierta por Juan Pablo Martínez Kuhn de Coinspect; las otras dos las encontró HashiCorp internamente.
CVE-2026-14869 (CVSS 8.6) — Server-Side Request Forgery (SSRF). El middleware rechazaba la dirección de Terraform pasada mediante una cabecera HTTP, pero permitía el mismo valor si se enviaba como parámetro de la petición. Un llamante no autenticado con acceso de red al listener Streamable HTTP podía forzar que el servidor enviara un bearer token configurado a un endpoint controlado por el atacante.
Matiz a la hora de comparar puntuaciones CVSS
La comparación directa de las puntuaciones de Veeam y HashiCorp no es correcta: Veeam utiliza CVSS 4.0, mientras que los registros CVE de HashiCorp emplean CVSS 3.1. Las puntuaciones 9.5 y 10.0 en versiones distintas de la escala no son magnitudes equivalentes. Además, las dos vulnerabilidades de aislamiento en Terraform MCP Server afectan a configuraciones diferentes: CVE-2026-16498 (10.0) se aplica al modo stateless, que debe activarse explícitamente, mientras que CVE-2026-16496 (8.9) afecta al modo stateful por defecto. La prioridad práctica viene determinada por la configuración del despliegue y no por el valor numérico de CVSS.
Cabe señalar una discrepancia en los rangos de versiones afectadas publicados: el boletín global de HashiCorp indica las versiones 0.2.1–1.0.0, mientras que la entrada CVE individual comienza en la 0.3.0. Ambas fuentes coinciden en que la 1.1.0 es la primera versión corregida.
Django: nueva ofensiva contra el código GIS
La publicación de Django del 4 de agosto (versiones 6.0.8 y 5.2.17) corrige cuatro CVE. La única vulnerabilidad de alta gravedad es CVE-2026-15307 en GeoDjango. Las consultas espaciales aceptaban valores de tipo cadena y diccionario y los pasaban a GDALRaster cuando aparentaban ser datos ráster. En función del driver de ráster, esto permitía escribir un archivo en disco o iniciar una petición de red desde el proceso de Django. La escritura de un archivo en un directorio desde el que la aplicación importa código posteriormente conduce a Remote Code Execution (RCE) arbitraria.
La vía de explotación documentada requiere una cuenta de empleado (staff) con permisos para ver un modelo registrado que contenga un campo espacial. La corrección prohíbe los valores de tipo diccionario y las cadenas que no sean valores GEOSGeometry válidos en las consultas espaciales — se trata de un cambio incompatible hacia atrás. La asignación directa a los campos del modelo sigue aceptando estos tipos.
Tres vulnerabilidades de menor gravedad:
- CVE-2026-15920 — Stored XSS en el panel de administración mediante valores inseguros de URLField;
- CVE-2026-15830 — Denial of Service (DoS) a través de objetos GEOMETRYCOLLECTION profundamente anidados (el límite se fija en 198 colecciones);
- CVE-2026-15337 — agotamiento de memoria en check_for_language() (ahora se rechazan los códigos de idioma de más de 500 caracteres).
Las ramas no soportadas de Django 5.1, 5.0 y 4.2 no han sido evaluadas y también podrían estar afectadas.
Contexto: el código GIS de Django en el punto de mira
El módulo GIS de Django ya había atraído la atención de los atacantes en 2026. En febrero, el proyecto corrigió CVE-2026-1207, una SQL injection en las consultas ráster de PostGIS. Según CrowdSec, se observó explotación in-the-wild: la regla de detección se publicó el 18 de febrero, los primeros ataques se registraron el 26 de febrero y posteriormente se inició un escaneo sostenido en busca de aplicaciones Django con backend PostGIS. La nueva vulnerabilidad CVE-2026-15307 requiere una cuenta de empleado, lo que imposibilita su explotación directa a partir de los resultados de aquel escaneo; sin embargo, el interés continuado en el código GIS de Django implica que cualquier nueva vulnerabilidad en este módulo será analizada por los atacantes en el menor plazo posible.
Recomendaciones de respuesta
- Veeam VSPC: actualizar a la build 9.3.0.35057. Todas las builds de la versión 9 hasta la 9.2.1.33875 incluida son vulnerables. Dado que se han producido dos ciclos de parches críticos en tres meses, se recomienda incluir VSPC en el calendario de actualizaciones prioritarias.
- Terraform MCP Server: actualizar a la versión 1.1.0 o posterior. Si no es posible actualizar de inmediato, limite el acceso de red al listener Streamable HTTP a usuarios de confianza y trate los identificadores de sesión MCP como valores confidenciales. Los despliegues en modo stdio no se ven afectados.
- Django: actualizar a 6.0.8 o 5.2.17. Comprobar la existencia de modelos con campos espaciales registrados en el panel de administración y auditar las cuentas de staff con permisos para ver dichos modelos. Tener en cuenta la incompatibilidad hacia atrás de la corrección de CVE-2026-15307 durante las pruebas.
- Las organizaciones en ramas de Django no soportadas (5.1, 5.0, 4.2) deben partir de la base de que también son vulnerables y planificar la migración a una versión soportada.
Las 11 vulnerabilidades cuentan con parches disponibles, ninguna se explota in-the-wild en el momento de la publicación y sigue abierto el margen para actualizar de forma proactiva. La prioridad de actualización viene determinada no tanto por el valor numérico de CVSS como por la configuración de cada despliegue concreto: los operadores de VSPC, las instalaciones centralizadas de Terraform MCP Server en modo HTTP y las aplicaciones Django con GeoDjango deberían aplicar los parches en los próximos días, sin esperar a que aparezcan exploits públicos.
