Verdaccio expone 3.336 registros npm privados y los tokens que reparte
El recuento de ZoomEye es una huella indexada y no confirma que esos hosts respondan, pero pone número a un patrón conocido: registros npm privados visibles desde fuera de su red.
Una consulta por título en ZoomEye devuelve 3.336 hosts con Verdaccio en su interfaz. Verdaccio es un registro privado y ligero para paquetes npm: los equipos lo levantan para alojar sus librerías internas, cachear las públicas y decidir de qué dependencias puede tirar una build. El recuento sale de la condición title="Verdaccio" y de una huella indexada, no de una comprobación en vivo: no confirma que el host responda ahora mismo ni revela si exige autenticación.
Por qué importa un registro expuesto
El registro está en el camino de dependencias de cada build que lo usa, y eso le da dos valores distintos. En lectura, expone los paquetes internos: nombres de endpoints internos, configuración por defecto, fixtures de test con datos de ejemplo y, a veces, credenciales que se commitearon antes de que hubiera un escáner de secretos. También la metadata de qué versiones existen y quién las publicó.
En escritura, es una posición en la cadena de suministro. Quien puede publicar un paquete del que dependen otros equipos influye en lo que esos equipos construyen después. Verdaccio permite acotar el alcance de los tokens, pero hay que configurarlo, y la configuración por defecto es generosa.
Hay una tercera propiedad fácil de pasar por alto: Verdaccio suele desplegarse como proxy de caché delante del registro público, así que guarda las credenciales con las que se autentica contra el upstream y puede permitir que el enlace las transporte.
Cómo acaba un registro en un índice público
Tres patrones explican la mayoría de los hosts alcanzables. Un registro montado para acelerar builds entre varias oficinas, con una dirección accesible más allá de la red de build. Una imagen de contenedor o de CI que expone el puerto del registro por defecto, de modo que un despliegue pensado para uso interno lo publica la propia plataforma donde corre. Y un registro que quedó vivo tras retirarse el proyecto que alimentaba, porque apagarlo obliga a tocar configuración de build que nadie quiere tocar.
Verdaccio ha publicado correcciones de seguridad en su historial de versiones, incluidas fallos de autenticación y de manejo de rutas en ramas antiguas. Un registro sin actualizar arrastra lo que esas correcciones arreglaban, y en la mayoría de despliegues la versión se ve desde la interfaz web.
Cinco comprobaciones
Si tu organización corre un registro, merece la pena mirar si la dirección resuelve desde fuera de la red de build; si hay acceso anónimo a algún paquete y si eso incluye los internos; qué tokens existen, con qué alcance y cuándo se emitieron; si las credenciales del uplink están en texto plano en la configuración; y si la versión está soportada y con los parches al día.
Para un registro que se quiere público a propósito, el control útil es la configuración del proxy: permitir lectura anónima de paquetes públicos no es lo mismo que permitirla de todo lo que el registro cachea o aloja.
Una consulta por título sirve para acotar la población, y un filtro por proveedor de hosting la reduce a las direcciones que probablemente pertenezcan a una organización conocida; la sintaxis de búsqueda está documentada. Lanzada antes y después de una revisión, la misma consulta muestra si el registro volvió a la red interna. El límite está claro: el número es una huella indexada, sin información sobre autenticación, alcances de tokens ni contenido de paquetes.
