GitHub y npm completan una revisión masiva de autenticación para frenar los ataques a la cadena de suministro. Los tokens clásicos de larga duración han muerto, pero los expertos advierten que el phishing sigue siendo el talón de Aquiles.
Si eres desarrollador de JavaScript, tu flujo de trabajo acaba de volverse más estricto (y más seguro). Hoy 13 de febrero de 2026, que el registro de paquetes npm ha finalizado una actualización crítica de su infraestructura de seguridad en respuesta a la oleada de ataques de 2025, incluyendo el infame incidente “Sha1-Hulud”.
Históricamente, npm dependía de “tokens clásicos”: credenciales que nunca expiraban y tenían permisos amplios. Si un atacante robaba uno, podía inyectar malware en paquetes populares indefinidamente. Eso se acabó.
Los Cambios: Muerte al Token Clásico
La nueva política de npm impone un cambio radical en cómo publicamos código:
- Revocación Masiva: Todos los tokens clásicos antiguos han sido revocados.
- Tokens de Sesión: Ahora, por defecto, se utilizan tokens de corta duración.
- Flujos Interactivos: Para publicar un paquete desde la terminal (npm publish), ahora se requiere una sesión interactiva que dura típicamente solo dos horas y exige autenticación multifactor (MFA) en el momento.
- Publicación de Confianza (OIDC): Se incentiva el uso de OpenID Connect para sistemas de CI/CD (como GitHub Actions), eliminando la necesidad de guardar secretos estáticos en los repositorios.
La Crítica: El Problema Humano Persiste
A pesar de estos avances, expertos de seguridad advierten que la puerta no está cerrada del todo.
- El Factor Phishing: El ataque original a paquetes como chalk y debug no fue por fuerza bruta, sino por phishing dirigido a los mantenedores para robar sus códigos MFA. Los nuevos tokens de sesión, aunque cortos, todavía pueden ser robados si el desarrollador es engañado en el momento justo.
- MFA Opcional: Sorprendentemente, los desarrolladores aún pueden generar tokens de 90 días con el “bypass de MFA” habilitado para automatización legacy, reintroduciendo el riesgo que se intentaba eliminar.
El Dato Alarmante
Según el análisis, en el 98.5% de los paquetes maliciosos encontrados en npm, el malware no estaba en el código fuente del repositorio (GitHub), sino que fue inyectado solo en el artefacto publicado en npm. Esto resalta la importancia de construir desde el código fuente verificado y no confiar ciegamente en lo que descargamos de los registros públicos.
¿Qué debes hacer como Dev?
- Revisa tus Tokens: Ve a tu perfil de npm y asegúrate de no tener tokens de automatización antiguos activos.
- Adopta OIDC: Si usas GitHub Actions, migra tus flujos de publicación a “Trusted Publishing” para no depender de secretos almacenados.
- Vigilancia: Ten cuidado con correos que parezcan venir de npm pidiendo “re-autenticar” tu cuenta urgentemente; suelen ser el preludio de un ataque de robo de paquetes.
