martes, 3 de noviembre de 2026
Secure crew

Ciberseguridad con criterio

Vulnerabilidades y parches

AWS VEW: una plantilla permitía ejecutar código

·2 fuentes

Por SecureCrew Editorial · Criterios editoriales y correcciones

CVE-2026-119085 afecta al componente de publicación de Virtual Engineering Workbench: una cuenta autenticada podía enviar una plantilla CloudFormation y ejecutar código con los permisos de la Lambda de publicación. La corrección está en el commit c146486, ya integrado en mayo; quien despliega la plataforma debe actualizar su copia.

Una mano ajusta un appliance compacto sobre una mesa de taller; en primer plano, un rollo de herramientas naranja lleva un parche Securecrew rojo y oscuro.

AWS publicó el 2 de noviembre el aviso de CVE-2026-119085 para Virtual Engineering Workbench (VEW), una plataforma de código abierto que los equipos instalan para publicar entornos de desarrollo. Una plantilla CloudFormation manipulada podía alcanzar el motor de plantillas del componente de publicación y ejecutar código en el servidor. El alcance potencial incluía recursos de otros tenants, pero el atacante descrito debía estar autenticado y llegar a la API de versionado de productos.

-SecureCrew dice: La palabra “AWS” en el nombre no convierte un repositorio desplegado por el cliente en un servicio administrado.-

El límite entre publicar y ejecutar

VEW separa dos tareas: el equipo de plataforma define versiones de producto y los desarrolladores solicitan entornos desde un portal. El fallo estaba en la publicación de esas versiones, donde una plantilla enviada mediante la API podía contener directivas que el motor interpretaba de forma insegura. No era un ataque por visitar el portal: el aviso habla de un tercero autenticado que remite el cuerpo de una plantilla especialmente construida.

La ejecución tomaba el rol IAM de la función Lambda de publicación. Según AWS, ese contexto podía dar acceso a datos y recursos de todos los proyectos tenant, no solo al entorno que el usuario estaba creando. El efecto real depende de lo que ese rol pueda hacer en cada despliegue. Por eso revisar permisos excesivos en la función es una medida útil de contención, pero no sustituye aplicar la corrección al código.

-SecureCrew dice: El aislamiento entre tenants depende tanto de las plantillas como del rol que ejecuta al publicarlas.-

La corrección estaba en un commit

AWS delimita el fallo a todos los commits anteriores a c146486, que incorporó la corrección en el repositorio el 4 de mayo de 2026. La publicación del aviso en noviembre no coincide con la fecha en que el fix llegó al código: quien ya desplegó ese commit o uno posterior no debe asumir que sigue vulnerable por el mero hecho de usar VEW; quien mantenga una copia antigua o un fork debe comparar su código con la corrección.

La solución indicada es volver a desplegar desde la rama principal actualizada e incorporar el cambio en derivados. AWS dice que no hay una mitigación que elimine la vulnerabilidad; mientras se prepara el redeploy, limitar quién puede crear o actualizar versiones de producto reduce quién puede alcanzar el flujo. Ese control temporal no neutraliza una plantilla maliciosa si sigue llegando desde una cuenta autorizada.

Qué revisar antes de darlo por cerrado

Conviene localizar el repositorio y el commit desplegado, confirmar si se usa la rama oficial o un fork y comprobar qué permisos conserva el rol de publicación. La etiqueta “AWS” no garantiza que el proveedor haya actualizado la instalación: VEW es software abierto ejecutado por quien lo despliega, así que cada equipo debe gestionar su copia y repetir la revisión en variantes internas.

Las organizaciones que permiten publicar plantillas entre equipos deberían revisar quién puede modificar versiones y qué recursos puede tocar la función Lambda. Después del redeploy, una prueba de control en un entorno autorizado debe confirmar que los procesos de publicación siguen funcionando y que el código corregido está presente. No hace falta tratar toda plantilla CloudFormation como maliciosa; sí conviene considerar confiable solo el contenido y el flujo de aprobación que el despliegue ha definido.

-SecureCrew dice: Un parche que vive en main no protege una copia que lleva meses desplegada.-

El aviso no informa de explotación activa ni de un incidente en los proyectos que usan VEW. La prioridad práctica es identificar las copias anteriores a c146486 y volver a desplegarlas, prestando atención a forks y a los permisos de la Lambda. El commit ya existe; el trabajo que queda suele ser menos vistoso: encontrar qué equipos siguen ejecutando la versión antigua.

Diccionario de la Crew

CVE — Identificador público y estable de un registro de vulnerabilidad.

CloudFormation — Formato y servicio de AWS para describir recursos cloud mediante plantillas.

IAM — Gestión de identidades y accesos; sus roles conceden permisos a usuarios o servicios.

Lambda — Servicio de AWS que ejecuta funciones de código sin que el equipo gestione directamente un servidor.

Fuentes

Fuentes consultadas

También te puede interesar

Carpeta de gestión de identidades con pestaña de importación y un token físico sobre una mesa clara; lleva una etiqueta Securecrew en su lomo.Vulnerabilidades y parches

Apache Syncope permite ejecutar JUEL en procesos BPMN

CVE-2026-109083 permite que una cuenta administradora con privilegios suficientes importe y arranque en Apache Syncope un flujo BPMN cuya expresión JUEL se ejecuta sin sandbox. El aviso delimita versiones afectadas y recomienda Syncope 4.0.9 o 4.1.4; no acredita explotación real ni acceso anónimo.

·2 fuentes