El error abierto de VSX permite que las extensiones de código VS maliciosas omitan las comprobaciones de seguridad previas a la publicación
Los investigadores de ciberseguridad han revelado detalles de un error ahora parcheado que afecta el proceso de escaneo previo a la publicación de Open VSX y hace que la herramienta permita que una extensión maliciosa de Microsoft Visual Studio Code (VS Code) pase el proceso de investigación y entre en funcionamiento en el registro.
«La canalización tenía un único valor de retorno booleano que significaba ‘no hay escáneres configurados’ y ‘todos los escáneres no pudieron ejecutarse’», Oran Simhony, investigador de Koi Security. dicho en un informe compartido con The Hacker News. «La persona que llamó no pudo notar la diferencia. Entonces, cuando los escáneres fallaron bajo carga, Open VSX lo trató como ‘nada que buscar’ y agitó la extensión directamente».
A principios del mes pasado, la Fundación Eclipse, que mantiene Open VSX, anunció planes para hacer cumplir controles de seguridad previos a la publicación antes de que las extensiones de VS Code se publiquen en el repositorio en un intento de abordar el creciente problema de las extensiones maliciosas.
Dado que Open VSX también sirve como mercado de extensiones para Cursor, Windsurf y otras bifurcaciones de VS Code, la medida fue vista como un enfoque proactivo para evitar que se publiquen extensiones maliciosas en primer lugar. Como parte del análisis previo a la publicación, las extensiones que no superan el proceso se ponen en cuarentena para revisión del administrador.
La vulnerabilidad descubierta por Koi, cuyo nombre en código Sésamo abiertotiene que ver con cómo este servicio basado en Java informa los resultados del análisis. Específicamente, se debe al hecho de que malinterpreta las fallas en el trabajo del escáner, ya que no hay escáneres configurados, lo que hace que una extensión se marque como aprobada y luego se active inmediatamente y esté disponible para su descarga desde Open VSX.
Al mismo tiempo, también puede hacer referencia a un escenario en el que los analizadores existen y los trabajos del analizador han fallado y no se pueden poner en cola porque el grupo de conexiones de la base de datos está agotado. Aún más preocupante, un servicio de recuperación diseñado para reintentar análisis fallidos sufrió el mismo problema, permitiendo así que las extensiones omitan todo el proceso de análisis bajo ciertas condiciones.
Un atacante puede aprovechar esta debilidad para inundar el punto final de publicación con varias extensiones .VSIX maliciosas, lo que provoca que la carga simultánea agote el grupo de conexiones de la base de datos. Esto, a su vez, conduce a un escenario en el que los trabajos de escaneo no se ponen en cola.
Lo notable del ataque es que no requiere ningún privilegio especial. Un actor malicioso con una cuenta de editor gratuita podría haber activado de manera confiable esta vulnerabilidad para socavar el proceso de escaneo y publicar su extensión. El problema era dirigido en Abierto VSX versión 0.32.0 el mes pasado luego de la divulgación responsable el 8 de febrero de 2026.
«El escaneo previo a la publicación es una capa importante, pero es una capa», dijo Koi. «El diseño del oleoducto es sólido, pero un solo valor booleano que no podía distinguir entre ‘nada que hacer’ y ‘algo salió mal’ convirtió toda la infraestructura en una puerta que se abrió bajo presión».
«Este es un antipatrón común: manejo de errores de apertura fallida escondido detrás de una ruta de código diseñada para un caso legítimo de ‘nada que hacer’. Si está creando canalizaciones similares, haga explícitos los estados de falla. Nunca permita que ‘no se necesita trabajo’ y ‘trabajo fallido’ compartan un valor de retorno».
