Recientemente se descubrió una grave falla de seguridad en Open VSX, el mercado de extensiones utilizado por editores de código populares como Cursor y Windsurf, así como por el ecosistema más amplio de bifurcaciones de VS Code. La vulnerabilidad se encontró dentro de la nueva canalización de escaneo previa a la publicación de la plataforma, una capa de seguridad diseñada para revisar cada extensión antes de que esté disponible.

Se descubrió recientemente una grave falla de seguridad en Open VSX, el mercado de extensiones utilizado por editores de código populares como Cursor y Windsurf, así como por el ecosistema más amplio de bifurcaciones de VS Code.

La vulnerabilidad se encontró dentro de la nueva canalización de escaneo previa a la publicación de la plataforma, una capa de seguridad diseñada para revisar cada extensión antes de que esté disponible para los usuarios.

La falla, ahora conocida como “Open Sesame”, permitía que una extensión maliciosa eludiera por completo el escaneo de seguridad y se publicara en el mercado, apareciendo ante los usuarios como si hubiera superado todas las comprobaciones de seguridad.

La canalización de escaneo se diseñó con buenas intenciones. Se creó para detectar malware, buscar secretos codificados, revisar binarios sospechosos y evitar el name-squatting, donde actores maliciosos copian nombres de extensiones populares para engañar a los usuarios y hacer que descarguen software dañino.

Esta canalización mantiene cada extensión subida en un estado inactivo hasta que todos los escáneres registrados la aprueban. Solo después de pasar todas las comprobaciones, la extensión se vuelve descargable.

En teoría, este sistema representaba un gran avance para la seguridad de todo el ecosistema.

Analistas e investigadores de Koi identificaron que la raíz del problema era un único valor booleano de retorno dentro del código de escaneo.

Este valor se utilizaba para significar dos cosas muy diferentes: o bien no había escáneres configurados, o todos los escáneres fallaron durante el proceso.

Como el sistema no podía distinguir entre estas dos situaciones, trataba un fallo total del escáner de la misma manera que un estado limpio y sin configurar.

El resultado fue que la plataforma marcaba la extensión como “APROBADA” y la activaba para su descarga pública, a pesar de que no se había realizado ningún escaneo de seguridad.

El ataque no requería acceso especial ni conocimiento interno. Cualquier persona con una cuenta de editor gratuita podía explotar esta falla simplemente inundando el punto final de publicación con múltiples solicitudes de carga al mismo tiempo.

Este tipo de tráfico intenso agotaba el grupo de conexiones de la base de datos, lo que provocaba que los trabajos de escaneo fallaran durante el proceso de encolado. Sin escaneos exitosos enviados, el sistema aún permitía que la extensión pasara.

La vulnerabilidad se reportó de manera responsable al equipo de Open VSX el 8 de febrero de 2026. El equipo respondió rápidamente y lanzó una solución funcional el 11 de febrero de 2026, solo tres días después de recibir el informe.

Cómo funcionaba el error de fallo abierto en la práctica

El problema técnico residía en dos archivos clave: ExtensionScanService.java y PublishExtensionVersionHandler.java. Cuando se ejecutaba el método de envío del escaneo y todos los trabajos de escáner fallaban al encolarse debido a una sobrecarga de la base de datos, devolvía un valor de “false”.

El llamador en el archivo del manejador interpretaba este “false” como si no hubiera escáneres configurados, lo que se consideraba un estado seguro y normal.

En lugar de bloquear la extensión, el sistema llamaba a scanService.markScanPassed() y luego activaba la extensión de inmediato para su descarga.

Lo que empeoraba las cosas era que la misma lógica defectuosa existía dentro de ExtensionScanJobRecoveryService.java, que se había construido específicamente como un sistema de respaldo para reintentar escaneos fallidos. La red de seguridad tenía el mismo fallo que el sistema que debía proteger.

Un atacante podía explotar esto preparando un lote de archivos de extensión maliciosos .vsix y enviándolos todos a la vez a través del punto final de publicación. Sin limitación de tasa, los intentos repetidos no tenían costo.

Cada ronda de publicaciones masivas sobrecargaba el grupo de conexiones de la base de datos hasta que el trabajo de escaneo comenzaba a fallar al encolarse. Una vez que esto ocurría, se activaba la condición de fallo abierto, la extensión se publicaba y nada en la interfaz de usuario indicaba que se había omitido alguna comprobación.

Los usuarios que instalaron extensiones nuevas o actualizadas desde el mercado de Open VSX durante la ventana vulnerable, que existió antes del parche del 11 de febrero de 2026, deberían revisar esas extensiones con cuidado.

Los desarrolladores que construyan canalizaciones de escaneo similares deben asegurarse de que los estados de fallo siempre se manejen por separado de los estados de “nada que hacer”. Un único valor de retorno nunca debería usarse para describir tanto una elección de configuración deliberada como un error del sistema.

Cuando un escáner falla al ejecutarse, la respuesta correcta es bloquear la extensión, no aprobarla. También se recomienda encarecidamente implementar limitación de tasa en los puntos finales de publicación para evitar el agotamiento del grupo de conexiones mediante inundaciones repetidas.