La proveniencia no es prueba: qué revisar antes de `npm install -g` un Tunnel CLI

Hay dos cosas ciertas en noviembre de 2026. npm 12 ahora se niega a ejecutar por defecto los scripts de instalación de dependencias, lo que cierra la ruta de entrega de la cadena de suministro más común. Y en el mismo año, atacantes han publicado versiones maliciosas de npm que portaban attestaciones de proveniencia válidas, además de cargas útiles que nunca tocan un script de instalación en absoluto.

Si vas a ejecutar npm install -g en un Tunnel CLI, ambos hechos importan. Un Tunnel CLI es un proceso de larga duración que mantiene un token de autenticación, hereda las variables de entorno de tu shell y retransmite tráfico entre Internet público y tu localhost. Esta guía explica qué cambia npm 12, qué hace y no demuestra la proveniencia, y una lista de verificación previa a la instalación: fijar versiones, ignore-scripts, binarios independientes verificados con sumas y listas de egresos permitidos.

Por qué un cliente de túnel es un objetivo de alto valor

Un Tunnel CLI se ejecuta durante horas o días, con los privilegios de tu usuario, en la máquina donde viven tu código, tus llaves y .env archivos, y en una ruta de red donde una copia manipulada puede leer lo que retransmite. La nota de Palo Alto Networks sobre la versión secuestrada de @bitwarden/cli enumera los objetivos: llaves SSH, .npmrc tokens, .env archivos, credenciales de AWS, configuraciones de Git, tokens de GitHub CLI, tokens de autenticación npm y configuraciones de IA/MCP. El auth token propio de un Tunnel CLI encajaría naturalmente junto a esos, y un proceso que ya tiene conectividad saliente está bien ubicado para enviarlo a algún lugar.

Qué cambió npm 12, y qué no

GitHub anunció npm 12 en julio de 2026, con allowScripts desactivado por defecto. Según la cobertura de The Hacker News, los scripts de preinstall, install y postinstall de las dependencias, y las compilaciones implícitas de node-gyp ya no se ejecutan a menos que se permita explícitamente. Las dependencias de Git y los tarballs de URL remota también están desactivados a menos que optes por --allow-git o --allow-remote. El aviso del changelog de GitHub sobre los cambios que rompen datos data, data? El periodo es julio de 2026.

Tres consecuencias prácticas para los Tunnel CLIs:

• Paquetes envoltorio que descargan un binario en tiempo de instalación dejarán de hacerlo. El wrapper de Node.js para ngrok documenta que npm install descarga el binario de la plataforma desde el hosting de ngrok durante su paso postinstall. Con npm 12 esa descarga está bloqueada hasta que la apruebes. Esto es una característica: te obliga a decidir si confías en esa ruta de descarga.
• Las instalaciones globales necesitan una bandera, no una lista de permitidos. Informes en el tracker de npm CLI muestran que para npm install -g, la advertencia te dirige a npm install -g --allow-scripts=<pkg>, o npm config set allow-scripts=<pkg> --location=user para persistirlo. Una reseña comunitaria también señala que npm approve-scripts falla en instalaciones globales, una laguna conocida.
• Las versiones antiguas de npm aún requieren ignore-scripts. La PR que invirtió el valor por defecto dice ignore-scripts=true y sigue siendo la alternativa para versiones antiguas. Mantenla en tu configuración hasta que cada máquina de tu fleet ejecute npm 12.

La brecha: cargas útiles que se ejecutan al ejecutar el código

Bloquear los scripts de instalación no evita código que se ejecuta cuando se utiliza el paquete. El análisis de julio de 2026 de Microsoft sobre el compromiso de AsyncAPI encontró una carga útil que se activó en el tiempo de carga del módulo, y afirmó que --ignore-scripts no neutraliza ese patrón. Los informes del incidente indican que cuatro paquetes @asyncapi fueron troyanizados, incluido @asyncapi/specs, que tiene aproximadamente 2.66 millones de descargas semanales.

El caso de Bitwarden CLI muestra la misma brecha desde otro ángulo. La versión maliciosa 2026.4.0, publicada el 22 de abril de 2026, reconfiguró tanto un gancho preinstall como la entrada binaria bw a un script cargador. Un análisis de OpenReplay apunta que la entrada bin significaba que la carga útil seguía ejecutándose cada vez que alguien invocaba el comando, incluso con --ignore-scripts configurado.

Aplica eso a un CLI global. Lo instalas precisamente para poder ejecutarlo. Para un Tunnel CLI, el límite entre lo “instalado” y lo “ejecutado” es de un solo comando, así que bloquear scripts te da menos beneficio de lo que haría para un árbol de dependencias de front-end. Sigue valiendo la pena tenerlo. No es suficiente.

Provenancia: qué demuestra y qué no

La proveniencia de npm vincula un paquete publicado al repositorio fuente y a las instrucciones de compilación que lo produjeron. La propia documentación de npm es explícita sobre el límite: la proveniencia no garantiza la ausencia de código malicioso. Te da un registro verificable para auditar, no un veredicto.

2026 proporcionó tres demostraciones claras.

Fecha	Incidente	Qué llevó a una proveniencia válida
11 de mayo de 2026	Gusano TanStack: 84 versiones maliciosas en 42 paquetes @tanstack/*	Publicada desde la cadena de publicación real y confiable tras el robo de un token OIDC
9 de septiembre de 2026	GHAPPIER: @dforge-core/dforge-mcp@0.2.21	Construido por GitHub Actions mediante publicación confiable con OIDC; la attestación nombra el commit del atacante
Oct 2026	fallo de publicación de confianza “Slugfest”: 1,500+ paquetes expuestos	Una versión de un repositorio que afirma un nombre abandonado también contendría una attestación válida

Sobre el incidente TanStack, Unit 42 de Palo Alto lo describe como el primer gusano documentado que publica paquetes maliciosos con procedencia de Build Level 3 válida, y resume el problema así: la proveniencia confirma qué pipeline construyó un paquete, no si ese pipeline estaba limpio. Su análisis agrega que el vínculo al publicador confiable cubrió todo el repositorio en lugar de un flujo de trabajo en una rama protegida.

GHAPPIER hace el mismo punto por otra vía. CloudSEK reporta que un atacante usó el acceso de un mantenedor durante unos 105 minutos, editó el flujo de publicación para que los pushes se publicaran automáticamente, y lanzó la versión 0.2.21, que siguió siendo la última durante unos 35 minutos. Como el registro confió en la identidad de CI del repositorio, la versión habría pasado npm audit signatures.

La investigación Slugfest de Bloom Security encontró que cualquiera que registrara un nombre de repositorio en GitHub que un mantenedor hubiera abandonado podría publicar paquetes que aún lo confiaban. GitHub dice que publicó correcciones, y las configuraciones no validadas ahora expiran a las 48 horas. El consejo de Bloom para los consumidores: verifica que la attestación nombre el repositorio del que debe provenir el proyecto.

La proveniencia ausente sigue siendo una señal

Nada de esto vuelve inútil la proveniencia. El informe sobre el compromiso de axios del 31 de marzo de 2026 señala que las publicaciones maliciosas carecían de la procedencia de GitHub Actions que tenían las publicaciones legítimas, lo que era una señal clave de detección. Un análisis de seguridad de Mondoo añade una advertencia relacionada: nada impide instalar una versión que haya perdido la proveniencia. Así que la regla es: una attestación ausente o desajustada es una razón para detenerse; una attestación válida es una razón para seguir verificando.

La lista de verificación previa a la instalación

1. Confirmar identidad y fijar una versión exacta

Verifica el nombre del paquete, el ámbito y la versión frente a la documentación del proveedor. El análisis de JFrog dice que la versión secuestrada de Bitwarden, 2026.4.0, no existe en el historial real de lanzamientos, a pesar de metadatos que parecen legítimos. Luego fija lo que revisaste en lugar de instalar @latest:

npm install -g some-tunnel-cli@1.2.3

3. Añadir una compuerta de antigüedad de la versión

npm 11.10 (febrero de 2026) añadió min-release-age, medido en días. Las versiones maliciosas suelen ser detectadas y retiradas en horas. La mala versión de GHAPPIER fue la más reciente durante unos 35 minutos, y la ventana de Bitwarden se reportó en aproximadamente una hora y media. Una compuerta de siete días habría saltado ambos.

# ~/.npmrc
min-release-age=7
ignore-scripts=true

Dos peculiaridades documentadas por usuarios: npm config get min-release-age puede imprimir null porque npm la transforma internamente a una marca de tiempo before, y no se puede combinar con --before. Para instalar un hotfix crítico de inmediato, anula por comando con --min-release-age=0.

4. Inspeccionar el manifiesto sin instalar

Mira lo que el paquete declara antes de tocar tu sistema:

npm view some-tunnel-cli@1.2.3 scripts bin dependencies --json
npm pack some-tunnel-cli@1.2.3   # descarga solo el tarball
tar -tzf some-tunnel-cli-1.2.3.tgz

Señales de alerta: cualquier preinstall/install/postinstall que un CLI puro no necesita, una entrada bin que apunta a un archivo de configuración o cargador en lugar del punto de entrada real, y dependencias recién agregadas. Ambas señales aparecieron en el manifiesto de Bitwarden.

5. Verifica en un directorio desechable, luego verifica las attestations

npm audit signatures verifica firmas del registro y attestations de proveniencia, pero funciona sobre dependencias instaladas en un proyecto, por lo que no audita directamente una instalación global. Instala en un directorio de pruebas con scripts deshabilitados, luego audita:

mkdir /tmp/vet && cd /tmp/vet && npm init -y
npm install --ignore-scripts some-tunnel-cli@1.2.3
npm audit signatures

La documentación de npm requiere npm 9.5.0 o posterior para esto. Luego lee la attestación en sí. El registro expone attestations en registry.npmjs.org/-/npm/v1/attestations/<package>@<version>. Confirma que el repositorio fuente y el flujo de trabajo coinciden con el repositorio oficial del proveedor, y que la versión tiene una attestación en absoluto si versiones anteriores no la tenían.

6. Decidir qué scripts pueden ejecutarse

En npm 12, aprueba solo aquello que entiendas. Para una herramienta global que realmente necesite un postinstall:

npm install -g --allow-scripts=some-tunnel-cli some-tunnel-cli@1.2.3

Si el único script del paquete es un descargador de binarios, esa es tu señal para la siguiente sección.

Preferir binarios independientes verificados con checksums

Muchos Tunnel CLI se distribuyen como binarios estáticos únicos. Instalar el binario directamente elimina el árbol de dependencias de npm, la descarga postinstall del wrapper y la superficie de ataque en tiempo de importación en un solo movimiento.

Cloudflare publica sumas de verificación SHA-256 para cada activo de cloudflared en sus notas de la versión de GitHub. Una instalación fijada y verificada luce así:

VERSION=<reviewed-release-tag>
curl -fsSLO "https://github.com/cloudflare/cloudflared/releases/download/${VERSION}/cloudflared-linux-amd64"
echo "<hash-you-recorded-at-review-time>  cloudflared-linux-amd64" | sha256sum -c -
install -m 0755 cloudflared-linux-amd64 /usr/local/bin/cloudflared

Sé honesto sobre lo que esto demuestra. Un checksum copiado de la misma página de lanzamiento que el binario protege contra corrupción y contra una ruta de descarga alterada, no contra una versión comprometida. Registra el hash en tu propio repositorio o código de infraestructura cuando un humano revisa el lanzamiento, y haz que tu script de aprovisionamiento compare con ese hash.

Cuando un proyecto publica attestations de GitHub, añade gh attestation verify ./some-binary --repo owner/repo. La CLI gh debe estar autenticada incluso para repositorios públicos, y algunos instaladores omiten la verificación cuando un lanzamiento no tiene attestación (la documentación de Foundry dice que su instalador sí), así que haz que tu propio script falle de forma cerrada. Estas attestations comparten el límite de la proveniencia de npm: identifican la compilación, no la intención del autor.

Restringe el egreso

Un Tunnel CLI necesita muy poco acceso saliente. La mayoría de cargas maliciosas necesitan más: a dónde enviar archivos robados y, a veces, a dónde obtener una segunda etapa. El cargador de Bitwarden descargó el runtime Bun desde GitHub, y su endpoint de exfiltración estaba diseñado para parecer el dominio de telemetría de un proveedor de seguridad.

Requisitos documentados para dos clientes populares:

• cloudflared se conecta saliente en el puerto 7844, TCP para HTTP/2 o UDP para QUIC, y abre cuatro conexiones salientes a al menos dos centros de datos de Cloudflare. La guía de firewall de Cloudflare lista region1.v2.argotunnel.com y region2.v2.argotunnel.com, añade nombres de host como cftunnel.com para firewalls con SNI y trata destinos en el puerto 443 como api.cloudflare.com (comprobaciones de actualización) como opcionales. RecomendA bloquear toda entrada.
• ngrok agentes hacen una conexión TLS saliente en el puerto 443 a connect.ngrok-agent.com. La documentación de ngrok dice que sus direcciones IP rotan y deben permitirse por nombre de host, y que la familia *.ngrok-agent.com puede ser necesaria debido al enrutamiento basado en latencia. También puedes white-label el URL de conexión y ejecutar ngrok diagnose para probar la conectividad.

Como los destinos son nombres de host, las reglas basadas en IP simples no son suficientes. Usa un firewall con conciencia de FQDN, un proxy o una política estilo Cilium toFQDNs, y aplícala al usuario o contenedor que ejecuta el túnel, no solo al host completo.

Una lista de permitidos reduce el radio de explosión pero no lo elimina: los endpoints del vendedor del túnel deben estar permitidos.

Ejecútalo como si pudiera estar comprometido

Supón que un día el cliente podría ser la mala versión que no viste. Ejecútalo como un usuario dedicado o en un contenedor sin credenciales en la nube, llaves SSH ni tokens de publicación al alcance, inícialo desde un entorno limpio en lugar de una shell llena de secretos exportados, y usa un authtoken de alcance estrecho que puedas rotar. Expón solo el puerto que necesitas.

Todo lo anterior trata de confiar en el cliente. Detectar túneles no autorizados es un problema separado, cubierto en nuestra entrada anterior sobre detectar túneles SSH reversos rogue.

Preguntas frecuentes

¿Hace npm 12 seguro npm install -g? No. Bloquea por defecto los scripts de instalación de dependencias, lo que elimina una ruta de ataque importante. El código que se ejecuta cuando importas un módulo o invocas la CLI no se ve afectado.

¿Es suficiente la proveniencia de npm para confiar en un paquete? No. La proveniencia muestra dónde y cómo se construyó un paquete. Varios incidentes de 2026 publicaron versiones maliciosas a través de tuberías legítimas con attestations válidas, así que verifica que la attestación coincida con el repositorio esperado y combínala con el pinning de versiones y revisión del manifiesto.

En resumen

npm 12 elevó el piso y los atacantes se movieron a lugares que no cubre. Trata la proveniencia como una pista sobre el origen de una versión, no como una respuesta a si deberías ejecutarla. Para un Tunnel CLI de larga duración, credenciales y expuesto a la red: ancla una versión revisada, espera los primeros días de un lanzamiento, prefiere binarios verificados por hash, y deja que el proceso alcance solo los hosts que necesita.

Fuentes

• npm 12 Disables Install Scripts by Default to Reduce Supply Chain Risk, The Hacker News (Jul 2026)
• Upcoming breaking changes for npm v12, GitHub Changelog (Jun 9, 2026)
• npm CLI PR #9424: block unreviewed install scripts by default (v12)
• npm CLI issue #9797: global install allow-scripts warning
• npm approve-scripts vs allow-scripts, DEV Community
• Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery, Microsoft Security Blog
• AsyncAPI npm Attack: Import-Time Malware Defense Guide, Digital Applied
• TeamPCP Campaign Spreads to npm via a Hijacked Bitwarden CLI, JFrog
• Bitwarden CLI Impersonation Attack, Palo Alto Networks
• A Simple Defense Against npm Supply Chain Attacks, OpenReplay
• The npm Threat Landscape: Attack Surface and Mitigations, Unit 42
• Why npm Provenance Didn’t Stop the TanStack Compromise, AppSec Santa
• Attackers Abuse npm Trusted Publishing in GHAPPIER Campaign, Infosecurity Magazine
• npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover, Help Net Security
• Your node_modules Is an Attack Surface: npm Security Checklist for 2026, DEV Community
• npm Supply Chain Security in 2026, Mondoo
• Generating provenance statements, npm Docs
• Viewing package provenance, npm Docs
• npm audit, npm Docs
• Configuring minimum release age across npm, pnpm, and yarn (gist)
• ngrok Node.js wrapper README
• cloudflared releases, GitHub
• Tunnel with firewall, Cloudflare Docs
• Cloudflare Tunnel configuration, Cloudflare Docs
• ngrok network egress, ngrok Docs
• ngrok custom connect URL, ngrok Docs
• Use artifact attestations, GitHub Docs
• Verifying releases, Foundry docs
• Integrity verification, Qlty docs