Phishing github, phishing desarrolladores, npm malicioso, supply chain dev y github seguridad son la combinación que más quita el sueño a quien escribe código en 2026. Los atacantes ya no van solo a tu abuela con el cuento del paquete de Correos. Ahora van a por ti, que tienes acceso a repositorios privados, tokens de CI/CD y la capacidad de publicar un paquete que descargarán miles de máquinas. Eres un objetivo de alto valor con permisos de escritura. Un correo falso de "alerta de seguridad de GitHub", un paquete con un typo de nombre, y de pronto tu token está en un servidor en otro continente. Vamos a ver cómo funciona el truco y cómo no caer.
Por qué los desarrolladores son el objetivo perfecto
Un desarrollador comprometido vale más que cien usuarios normales. Tienes la llave del reino: tokens de acceso personal (PAT), claves SSH, secretos en GitHub Actions y permisos para empujar código que otros ejecutan a ciegas.
El supply chain dev es el camino corto. En lugar de atacar a una empresa con buen perímetro, el atacante envenena una dependencia que esa empresa instala automáticamente. Tú haces npm install y abres la puerta sin enterarte.
Casos reales lo demuestran. El paquete event-stream (2018) fue secuestrado para robar carteras de Bitcoin. En 2021, las versiones maliciosas de ua-parser-js, coa y rc —paquetes con millones de descargas semanales— se publicaron tras comprometer cuentas de mantenedores. En 2024, el incidente de xz/liblzma (CVE-2024-3094) demostró que un atacante paciente puede ganarse la confianza de un proyecto durante años antes de meter la puerta trasera. Ingeniería social pura, no un exploit.
Las técnicas de phishing dirigidas a quien programa
El phishing desarrolladores tiene sabores específicos. No es el correo genérico de siempre. Está hecho a medida de tu flujo de trabajo.
- Falsas alertas de seguridad de GitHub. "Actividad sospechosa en tu cuenta, verifica ahora". El enlace lleva a un clon de
github.comen un dominio tipogithub-security.neto con caracteres Unicode parecidos (ataque homográfico). - OAuth apps maliciosas. Te invitan a autorizar una app "para revisar tu PR" o "analizar tu repo". Autorizas, y le das acceso de lectura/escritura a tus repositorios sin entregar contraseña. No hace falta robarte la clave si tú firmas el permiso.
- Falsas ofertas de trabajo. La campaña de Lazarus (Corea del Norte) lleva años enviando "pruebas técnicas" a desarrolladores: un repo que debes clonar y ejecutar. Dentro, malware que vacía carteras cripto y roba credenciales.
- Typosquatting en npm. Publican
crossenven vez decross-env, oelectron-native-notifycon código añadido. Un dedo torpe instalando dependencias y ya está. - Commits y issues con enlaces trampa. Un "colaborador" abre un issue con un enlace a un Gist o a un dominio que captura tu sesión.
La lógica del phishing github moderno es que pareces seguro porque usas 2FA, pero el atacante no quiere tu contraseña: quiere tu token o tu autorización OAuth. Y esos a veces saltan el segundo factor.
Señales de alerta que deberías reconocer al vuelo
Tu sentido arácnido de programador debería activarse con estas situaciones. Como detallamos en nuestra guía sobre correos falsos de suscripciones, el patrón es siempre el mismo: urgencia, dominio raro y una acción que beneficia al atacante.
| Señal | Qué significa |
|---|---|
Dominio que no es exactamente github.com | Clon de phishing. Revisa carácter por carácter. |
| Urgencia extrema ("tu cuenta se cerrará en 24h") | Presión psicológica clásica. |
| Te piden autorizar una OAuth app desconocida | Acceso a tus repos sin contraseña. |
| Un paquete npm con muy pocas descargas pero nombre familiar | Posible typosquatting. |
Dependencia que pide scripts postinstall sospechosos | Vector clásico de ejecución de código. |
| "Recruiter" que insiste en que clones y ejecutes su repo | Patrón Lazarus. Huye. |
Un buen reflejo: antes de instalar un paquete nuevo, míralo en npmjs.com, comprueba el número de descargas, la fecha de última publicación y si el repo de GitHub coincide. Herramientas como Socket.dev, Snyk o el propio npm audit ayudan a detectar dependencias con comportamiento raro.
Cómo blindar tu cuenta y tu cadena de suministro
La github seguridad empieza por ti, no por una herramienta mágica. Estos pasos cubren el 90% de los ataques reales.
- 2FA con clave física o passkey, no SMS. GitHub ya obliga a 2FA a quien contribuye, pero el SMS es el factor más débil. Una llave FIDO2 (YubiKey) resiste el phishing porque está atada al dominio real.
- Fine-grained PAT con caducidad corta. Olvida los tokens clásicos con permisos totales y sin fecha de fin. Da solo el scope necesario y que expiren en días, no en años.
- Audita tus OAuth apps autorizadas en Settings → Applications. Revoca todo lo que no reconozcas. Hazlo cada cierto tiempo.
- Fija versiones (lockfiles) y usa
npm cien producción. Elpackage-lock.jsonevita que una versión nueva envenenada entre sin que lo notes. - Activa Dependabot y secret scanning. GitHub avisa de dependencias vulnerables y de secretos filtrados en commits.
- Nunca ejecutes un repo de "prueba técnica" en tu máquina principal. Usa una máquina virtual o un contenedor desechable.
Si gestionas tu propia infraestructura, refuerza también el correo y la red. Una buena segmentación de tu red doméstica limita el daño si algo se cuela, y entender los distintos tipos de spam y correo malicioso te ayuda a filtrar los intentos antes de que lleguen a tu bandeja. Para equipos grandes, una solución de SIEM para detección de amenazas en tiempo real añade visibilidad sobre accesos anómalos.
Qué hacer si ya has picado
Respira. Actúa rápido, en este orden:
- Revoca todos los tokens y claves SSH desde Settings de GitHub. Inmediatamente.
- Cambia la contraseña y revisa las sesiones activas para cerrar las que no reconozcas.
- Audita y revoca OAuth apps sospechosas.
- Comprueba si tu email aparece en filtraciones con Have I Been Pwned.
- Si publicaste o instalaste un paquete dudoso, analiza el sistema. Sube cualquier fichero sospechoso a VirusTotal y rota cualquier secreto que estuviera en esa máquina.
- Revisa el historial de commits de tus repos por si hay cambios que no hiciste tú.
- Reporta el paquete malicioso al equipo de seguridad de npm y el dominio de phishing a GitHub.
Y rota los secretos como si todos estuvieran comprometidos, porque si tu máquina lo estuvo, probablemente lo están.
Preguntas frecuentes
¿Cómo sé si un paquete de npm es malicioso antes de instalarlo?
Revisa su página en npmjs.com: número de descargas, fecha de última actualización y enlace al repositorio. Pasa el nombre por Socket.dev o ejecuta npm audit. Desconfía de paquetes nuevos con nombres casi idénticos a otros populares.
¿El 2FA me protege del phishing en GitHub?
Reduce mucho el riesgo, pero no es infalible. El SMS es vulnerable y los ataques que usan OAuth apps no necesitan tu segundo factor. Una passkey o llave física FIDO2 es la única que resiste el phishing de dominio falso.
¿Qué es un ataque de supply chain y por qué me afecta como desarrollador?
Es cuando el atacante envenena una dependencia que tú instalas automáticamente, en lugar de atacarte de forma directa. Te afecta porque tu npm install ejecuta código de terceros con tus permisos. Fijar versiones con lockfiles y auditar dependencias lo mitiga.
Recibí una oferta de trabajo que me pide clonar un repositorio y ejecutarlo. ¿Es seguro?
Casi seguro que no. Es el patrón de las campañas de Lazarus dirigidas a desarrolladores. Nunca ejecutes código de un "recruiter" en tu máquina principal: usa una máquina virtual aislada o, mejor, no lo ejecutes.
¿Cómo reporto un paquete npm malicioso o un dominio de phishing?
Reporta el paquete al equipo de seguridad de npm a través del formulario de reporte de su web, y el dominio falso a GitHub vía su página de abuse. Si afecta a una empresa, avisa también a su equipo de seguridad.
Mantener limpia la bandeja de entrada es parte de la defensa: muchos de estos ataques empiezan por correo. Si quieres reducir la superficie, repasa nuestra guía para evitar el spam en 2026 y plantéate usar alias de email para tus registros en servicios de terceros. Y si construyes producto, conviene tener clara la visibilidad y el posicionamiento de tu proyecto sin descuidar la seguridad de la base sobre la que corre, ya sea una página web o una app móvil.
El siguiente paso
Entra ahora mismo en GitHub → Settings → Applications, revisa la lista de OAuth apps autorizadas y revoca cualquiera que no reconozcas. Tardas dos minutos y cierras uno de los vectores de ataque más usados contra desarrolladores.
