La investigación de Resurrección de Extensiones de Bloom Security expone un punto ciego en la seguridad de los desarrolladores.

      TL;DR La investigación de "Resurrección de Extensiones" de Bloom Security encontró que paquetes de extensiones legítimos de VS Code y Open VSX pueden hacer referencia a extensiones que no existen en el mercado. Los atacantes podrían reclamar esos espacios de nombres y publicar extensiones maliciosas que se instalan automáticamente a través de paquetes de confianza. 677 de 4,179 paquetes de VS Code y 94 de 321 paquetes de Open VSX eran vulnerables, con más de 500,000 descargas combinadas. Tanto Microsoft como la Fundación Eclipse han implementado protecciones tras la divulgación de Bloom.

      Los equipos de seguridad han pasado años examinando las dependencias de software, los repositorios de paquetes y las tuberías de construcción. La última investigación de Bloom Security sugiere que otra parte de la cadena de suministro de software merece una atención más cercana: las extensiones que los desarrolladores instalan dentro de sus IDE.

      La investigación "Resurrección de Extensiones" de la compañía examinó paquetes de extensiones en el Mercado de Visual Studio Code y Open VSX. Bloom encontró que los paquetes legítimos podían contener referencias a extensiones que en realidad no existían en el mercado, creando una oportunidad para que los atacantes reclamaran esos espacios de nombres no utilizados y publicaran extensiones maliciosas bajo ellos.

      La investigación identificó 94 de 321 paquetes de extensiones de Open VSX con al menos una "Dependencia Sombra". En el Mercado de VS Code, Bloom encontró 677 de 4,179 paquetes con al menos una dependencia de este tipo. A través de los paquetes vulnerables, las descargas superaron las 500,000.

      El verdadero problema es el modelo de confianza

      Lo que hace notable el hallazgo es que el ataque no depende de convencer a un desarrollador para que instale una extensión desconocida. El desarrollador ya ha tomado una decisión de confianza al instalar un paquete de extensiones legítimo.

      Esa decisión puede extenderse a múltiples dependencias que el usuario puede nunca examinar individualmente. La investigación de Bloom muestra cómo una extensión faltante dentro de esa cadena puede convertirse en una oportunidad si el mercado continúa reconociendo su identidad mientras permite que alguien más registre el espacio de nombres correspondiente.

      El resultado es una desconexión entre lo que los desarrolladores creen que han aprobado y lo que su entorno de desarrollo puede instalar en última instancia.

      La automatización agranda el problema

      La investigación de Bloom también destaca el papel de las actualizaciones automáticas. Los paquetes de extensiones no fijan sus extensiones empaquetadas a versiones específicas, lo que significa que un paquete instalado en el pasado puede potencialmente adquirir una versión recién publicada de una dependencia que faltaba anteriormente.

      Eso cambia la naturaleza del riesgo. Una organización no necesita necesariamente instalar una extensión maliciosa hoy para quedar expuesta. Un desarrollador podría haber instalado un paquete legítimo semanas, meses o incluso años antes y luego recibir una extensión a través del mecanismo de actualización del paquete.

      Bloom encontró que el conteo combinado de descargas para paquetes vulnerables superó las 500,000, ilustrando la posible escala de la exposición.

      El impacto técnico también es significativo. Según Bloom, las extensiones de VS Code y las extensiones para IDEs compatibles como Cursor, Kiro, Windsurf, Antigravity, VSCodium y Eclipse Theia se ejecutan con acceso de host a Node.js. Pueden leer y escribir archivos, generar procesos secundarios y hacer solicitudes de red salientes.

      Un problema de diseño del mercado

      Los hallazgos de Bloom apuntan en última instancia a debilidades en cómo los mercados manejan las dependencias y los espacios de nombres.

      La compañía identificó dos brechas: los mercados podrían aceptar paquetes que contengan referencias a extensiones que no existían, y los espacios de nombres referenciados por software existente podrían seguir disponibles para registro. Juntas, esas condiciones crearon un camino para que un atacante convirtiera una referencia inactiva en una dependencia activa.

      El problema no se limitó completamente a los paquetes de extensiones. Durante su investigación, Bloom encontró que las dependencias de extensiones de Open VSX declaradas en manifiestos podrían estar expuestas al mismo problema subyacente.

      Ambos operadores de mercado respondieron tras la divulgación. Bloom informó del problema de Open VSX a la Fundación Eclipse el 5 de febrero de 2026, y dijo que el equipo actuó rápidamente para proteger los espacios de nombres en riesgo e implementar controles para extensiones y dependencias inexistentes.

      Bloom informó del problema a Microsoft el 17 de febrero. Microsoft inicialmente lo calificó como Moderado antes de reabrir el caso después de que Bloom proporcionara evidencia adicional. Microsoft confirmó posteriormente que se habían implementado protecciones contra la resurrección de extensiones en etapas, con protecciones de acción del administrador que datan de octubre de 2025 y protecciones de acción del usuario completadas en junio de 2026.

      Lo que la investigación significa para los equipos de seguridad

      La lección más amplia de la investigación de Bloom es menos sobre una vulnerabilidad específica del mercado y más sobre cómo las organizaciones piensan sobre los puntos finales de los desarrolladores.

      Las extensiones de IDE a menudo se tratan como herramientas de productividad en lugar de componentes de software que requieren supervisión continua de seguridad. Sin embargo, pueden tener un acceso profundo a los sistemas en los que trabajan los desarrolladores, y los paquetes de extensiones pueden multiplicar el número de componentes introducidos a través de una sola instalación.

      Para los equipos de seguridad, eso significa que la visibilidad debe extenderse a las extensiones y paquetes instalados, sus configuraciones, el comportamiento de actualización automática y las capacidades de extensiones individuales. También significa reconocer que una instalación confiable no es necesariamente una instantánea permanente de lo que se está ejecutando en un punto final.

      La investigación de Bloom demuestra cómo una brecha aparentemente menor, una dependencia que apunta a algo que no existe, puede convertirse en un problema significativo de seguridad de la cadena de suministro cuando se combina con la instalación y actualizaciones automáticas.

      Por lo tanto, la pregunta importante para las organizaciones puede no ser simplemente qué extensiones han aprobado los desarrolladores, sino qué extensiones son capaces de instalar sus entornos de desarrollo sin preguntar nuevamente.