Se ha revelado una grave vulnerabilidad de lógica, apodada “Open Sesame”, en el mercado de extensiones Open VSX, una plataforma ampliamente utilizada por editores de código populares como Cursor, Windsurf y el ecosistema general de forks de VS Code.
La falla residía en el recién implementado pipeline de escaneo de seguridad previo a la publicación. Debido a un error de diseño en el manejo de estados de falla, un atacante podía forzar que extensiones maliciosas eludieran completamente las revisiones de seguridad (búsqueda de malware, binarios sospechosos y secretos codificados) y se publicaran en el mercado marcadas como seguras.
Anatomía del Ataque
El problema técnico se originaba en la lógica subyacente de dos archivos clave: ExtensionScanService.java y PublishExtensionVersionHandler.java. El sistema de escaneo fue diseñado para retener cada extensión subida en un estado inactivo hasta que todos los escáneres registrados la aprobaran. Sin embargo, investigadores descubrieron un error crítico de tipo fail-open basado en el retorno de un valor booleano.
- Ambigüedad Booleana: El código utilizaba un único valor booleano (false) para representar dos situaciones completamente diferentes:
- Situación A: Ningún escáner está configurado (estado normal y seguro).
- Situación B: Todos los trabajos del escáner fallaron al encolarse.
- Explotación por Saturación: Un atacante con una cuenta de publicador gratuita solo necesitaba preparar un lote de archivos de extensión .vsix maliciosos y saturar el endpoint de publicación con múltiples solicitudes de subida simultáneas.
- Agotamiento de Conexiones: Al no existir limitación de tasa (rate limiting), este tráfico intenso agotaba el pool de conexiones de la base de datos de Open VSX. Esto provocaba que los trabajos de los escáneres fallaran al intentar encolarse (Situación B).
- Bypass de Seguridad: Al fallar el encolamiento, el sistema devolvía false. El handler interpretaba erróneamente este fallo como si no hubiese escáneres configurados (Situación A). En consecuencia, el sistema llamaba a scanService.markScanPassed(), omitiendo las comprobaciones y activando inmediatamente la extensión para su descarga pública. Lo mismo ocurría con el sistema de respaldo (ExtensionScanJobRecoveryService.java).
Impacto
Cualquier actor de amenazas podía publicar malware en el mercado de Open VSX sin obstáculos, el cual aparecería ante los usuarios finales como una extensión legítima que había pasado todos los controles de seguridad. Esto exponía a los desarrolladores que utilizan IDEs basados en VS Code al riesgo de descargar extensiones maliciosas que podrían comprometer sus estaciones de trabajo, robar código fuente o extraer credenciales, impactando directamente en la cadena de suministro de desarrollo de software.
Recomendaciones y Mitigación Inmediata
- Revisión de Extensiones para Usuarios Finales: Los desarrolladores y usuarios que hayan instalado o actualizado extensiones desde Open VSX en la ventana de vulnerabilidad (antes del 11 de febrero de 2026) deben revisar cuidadosamente dichas extensiones, prestando especial atención a comportamientos inusuales, nombres que intenten suplantar extensiones populares (typosquatting) o solicitudes de red sospechosas.
- Mitigaciones para Desarrolladores de Plataformas (Lecciones Aprendidas):
- Fail-Closed, no Fail-Open: En sistemas de seguridad, un fallo en el sistema de escaneo debe resultar en un bloqueo automático (Fail-Closed), nunca en una aprobación.
- Manejo Claro de Estados: Nunca se debe utilizar un único valor de retorno (como un simple booleano) para describir simultáneamente una opción de configuración deliberada y un error del sistema. Los estados de error deben manejarse con excepciones o tipos de retorno específicos.
- Implementación de Rate Limiting: Es mandatorio aplicar límites de tasa en los endpoints de publicación y subida de archivos para prevenir ataques de denegación de servicio (DoS) o agotamiento de recursos (connection pool exhaustion) que puedan desestabilizar la lógica del sistema.
