npm agrega controles de instalación de paquetes y publicación controlados por 2FA contra ataques a la cadena de suministro – CYBERDEFENSA.MX

GitHub ha implementado nuevos controles para npm para mejorar la seguridad de la cadena de suministro de software, brindando a los mantenedores la capacidad de aprobar explícitamente una versión antes de que los paquetes estén disponibles públicamente para su instalación.

La función, denominada publicación por etapas, ahora está disponible de forma generalizada en npm. Exige que un mantenedor humano pase un desafío de autenticación de dos factores (2FA) para aprobar un paquete antes de enviarlo a npmjs.[.]com.

«En lugar de una publicación directa que pone inmediatamente a disposición de los consumidores una versión del paquete, el tarball prediseñado se carga en una cola de espera donde un responsable de mantenimiento debe aprobarlo explícitamente antes de que sea instalable», GitHub dicho.

La subsidiaria propiedad de Microsoft dijo que el cambio garantiza una «prueba de presencia» para cada publicación, incluidas aquellas que provienen de flujos de trabajo CI/CD no interactivos y publicaciones confiables con autenticación OpenID Connect (OIDC).

Antes de usar publicación en escenalos mantenedores de paquetes deben cumplir los siguientes criterios:

  • Tener acceso de publicación al paquete.
  • El paquete ya existe en el registro npm, lo que significa que no se puede preparar un paquete nuevo
  • 2FA está habilitado para la cuenta

Los desarrolladores pueden utilizar el comando «npm stage Publish» desde el directorio raíz del paquete para enviarlo a un área de preparación. Para utilizar este comando, es esencial actualizar a npm CLI 11.15.0 o posterior. Para una protección óptima, GitHub recomienda que la publicación por etapas se combine con publicación confiable utilizando OIDC.

Ciberseguridad

Una segunda actualización centrada en npm se relaciona con la introducción de tres nuevos indicadores de fuente de instalación junto con el indicador existente -allow-git –

  • –allow-file: Controla las instalaciones desde rutas de archivos locales y archivos tar locales
  • –allow-remote: controla las instalaciones desde URL remotas, incluidos archivos tar https
  • –allow-directory: Controla las instalaciones desde directorios locales

Las banderas permiten a los desarrolladores «aplicar el mismo enfoque de lista permitida explícita a cada fuente de instalación que no sea del registro», dijo GitHub.

El desarrollo se produce en medio de un aumento masivo de ataques a la cadena de suministro de software dirigidos a ecosistemas de código abierto en los últimos meses, con un grupo cibercriminal conocido como TeamPCP involucrado en envenenar paquetes populares a una escala sin precedentes a través de un ciclo de compromisos que se perpetúa a sí mismo.

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».

Ciberseguridad

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.

Ciberseguridad

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».