Un paquete con un nombre como "requests-http" puede enviar tu token de AWS a un servidor remoto a los pocos segundos de ejecutar pip install. Así funciona, en la práctica, el malware pypi: paquetes python maliciosos que imitan a librerías legítimas para colarse en tu máquina o en tu pipeline de CI/CD. El pip malware ya no es una curiosidad de conferencia de seguridad: es un vector activo de supply chain python que compromete servidores, roba credenciales y secuestra wallets de criptomonedas. La técnica estrella se llama typosquatting pip y funciona porque los desarrolladores, como todo el mundo, escriben rápido y no siempre miran bien. PyPI no audita cada subida, y eso deja la puerta entornada para quien sepa jugar con nombres parecidos y paciencia.
Qué es el malware en PyPI y por qué es diferente a otros vectores
PyPI (Python Package Index) es el repositorio oficial de paquetes Python. Cualquiera puede publicar ahí sin pasar por una revisión exhaustiva de código. Eso es una ventaja enorme para la comunidad open source y, a la vez, un problema de seguridad estructural.
A diferencia del phishing clásico, aquí no hace falta engañar a un humano con un correo urgente. Basta con que un desarrollador ejecute pip install con el nombre equivocado, o que un proyecto legítimo dependa de una librería que alguien ha comprometido silenciosamente. El malware se ejecuta automáticamente al instalar (via setup.py o hooks de instalación), sin que el usuario abra nada ni haga clic en ningún enlace.
Según reportes de empresas como Sonatype y Checkmarx, el volumen de paquetes maliciosos detectados en PyPI ha crecido de forma sostenida cada año desde 2021, y en 2026 la cifra sigue en aumento según estimaciones del sector. La superficie de ataque es enorme: PyPI aloja cientos de miles de paquetes, muchos con mantenimiento mínimo o abandonado.
Las técnicas más comunes: typosquatting, dependency confusion y cuentas comprometidas
No todos los ataques a la cadena de suministro en Python usan el mismo truco. Conviene distinguirlos porque la defensa cambia según el caso.
| Técnica | Cómo funciona | Ejemplo típico |
|---|---|---|
| Typosquatting | Nombre casi idéntico a un paquete popular | "reqeusts" en vez de "requests" |
| Dependency confusion | Sube a PyPI público un paquete con el mismo nombre que uno interno privado, con versión más alta | Un paquete interno "acme-utils" clonado en PyPI |
| Cuenta comprometida | El atacante roba credenciales del mantenedor real y publica una versión troyanizada | Caso ctx (2022), aún citado como referencia |
| Paquetes abandonados reclamados | Se apropia de un nombre huérfano tras eliminarlo el mantenedor original | Librerías con miles de descargas/mes sin actividad |
El typosquatting pip es el más barato de ejecutar y el más difícil de erradicar del todo, porque depende de errores humanos que se repiten indefinidamente. Basta con registrar variantes de nombres populares (colorama vs colourama, python-dateutil vs python-dateutil2) y esperar.
La dependency confusion es más sofisticada y afecta sobre todo a empresas: si tu organización usa un paquete interno llamado igual que uno público, y tu configuración de pip no prioriza el registro privado, puedes acabar instalando la versión maliciosa sin darte cuenta. Este mismo problema de configuraciones mal cerradas aparece también en el contexto de Shadow IT y aplicaciones no autorizadas en la empresa, donde nadie tiene visibilidad completa de qué se está ejecutando.
Qué hace el malware una vez instalado
El payload varía, pero los patrones se repiten con insistencia:
- Robo de credenciales: busca variables de entorno con tokens de AWS, GCP, claves SSH y archivos de configuración de Docker o Kubernetes.
- Exfiltración silenciosa: envía los datos robados a un servidor de comando y control (C2) vía DNS o HTTP, a menudo camuflado como telemetría legítima.
- Backdoors persistentes: instala un proceso en segundo plano que sobrevive a reinicios, típico en ataques dirigidos a servidores de CI/CD.
- Cryptojacking: usa la CPU o GPU de la máquina infectada para minar criptomonedas sin que el usuario lo note hasta ver la factura eléctrica o de cloud.
- Ransomware ligero: cifra archivos de proyecto o repositorios locales, algo que conecta directamente con las técnicas descritas en qué es el ransomware y cómo funciona.
Lo más inquietante del supply chain python es que el ataque no necesita comprometer tu máquina directamente. Basta con comprometer una dependencia de una dependencia (una transitiva de tercer o cuarto nivel) que ni siquiera sabías que estaba instalada. Herramientas como pip show --files o pipdeptree ayudan a mapear ese árbol, pero pocos desarrolladores lo revisan de forma habitual.
Cómo protegerte: herramientas y hábitos concretos
La buena noticia es que hay defensas reales y accesibles, no solo "ten cuidado":
- Verifica el nombre exacto del paquete antes de instalar. Copia y pega desde la documentación oficial, no lo escribas de memoria.
- Usa
pip install --require-hashescon un archivo de requirements que incluya hashes SHA256, así pip rechaza cualquier versión que no coincida exactamente. - Escanea dependencias con herramientas dedicadas: Safety, pip-audit (mantenida por la PyPA) y Bandit detectan vulnerabilidades conocidas y patrones sospechosos en el código.
- Sube archivos sospechosos a VirusTotal antes de ejecutarlos si dudas de un paquete concreto, especialmente si trae binarios compilados.
- Comprueba si tus credenciales ya han sido filtradas con Have I Been Pwned, sobre todo si has instalado algo dudoso en las últimas semanas.
- Usa entornos virtuales aislados (venv, Docker) para instalar paquetes nuevos antes de llevarlos a producción.
- Configura un proxy de paquetes privado (Artifactory, Nexus, o el registro propio de GitHub) para evitar dependency confusion en entornos corporativos.
- Fija versiones exactas en
requirements.txten lugar de rangos abiertos, y revisa los changelogs antes de actualizar.
Si trabajas en una empresa con varios equipos de desarrollo, esto entra de lleno en el terreno de la continuidad de negocio ante ciberataques: un solo paquete comprometido en un pipeline de despliegue puede tumbar servicios enteros. Las políticas de seguridad empresarial en 2026 empiezan a exigir SBOM (Software Bill of Materials) como requisito de auditoría, algo que hace unos años era opcional.
Casos reales que conviene recordar
El caso ctx (2022) sigue siendo la referencia obligada: un atacante tomó el control del paquete PyPI abandonado ctx y de una librería PHP en Packagist, e inyectó código que exfiltraba variables de entorno completas a un servidor externo. El paquete llevaba años instalado en miles de proyectos sin que nadie sospechara.
Más recientemente, campañas de typosquatting masivo han registrado cientos de variantes de nombres populares de una sola vez, usando scripts automatizados que generan combinaciones plausibles (cambio de guion por guion bajo, letras dobles, sufijos numéricos). Según estimaciones de firmas de seguridad para 2026, estas campañas automatizadas representan la mayoría de los paquetes maliciosos nuevos detectados cada mes, muy por encima de los ataques dirigidos y manuales.
El patrón de fondo es siempre el mismo: aprovechar la confianza implícita que tenemos en el ecosistema open source. Si tu empresa necesita reforzar la seguridad de su infraestructura digital más allá del código, en gestión profesional de WordPress aplicamos principios similares de control de dependencias y actualizaciones auditadas.
Preguntas frecuentes
¿Cómo sé si un paquete de PyPI es seguro antes de instalarlo?
Revisa el número de descargas, la fecha de la última actualización y si el repositorio de código (normalmente en GitHub) tiene actividad real y coincide con el paquete. Herramientas como pip-audit también comprueban si hay vulnerabilidades conocidas registradas.
¿Qué hago si ya he instalado un paquete malicioso?
Desinstálalo, rota inmediatamente todas las credenciales que pudieran estar accesibles en esa máquina (tokens de cloud, claves SSH, contraseñas de bases de datos) y revisa los logs de red en busca de conexiones salientes sospechosas. Si estaba en un servidor de producción, considera reconstruir el entorno desde cero.
¿PyPI elimina los paquetes maliciosos cuando se detectan?
Sí, el equipo de seguridad de PyPI retira paquetes reportados, pero la detección depende en gran parte de reportes de la comunidad. El tiempo entre publicación y retirada puede ser de horas o de semanas, según la visibilidad del paquete.
¿El typosquatting solo afecta a Python o también a otros lenguajes?
Afecta a todos los gestores de paquetes con publicación abierta: npm (JavaScript), RubyGems, Crates.io (Rust) y Packagist (PHP) han sufrido casos similares. El problema es estructural del modelo de repositorios públicos, no exclusivo de Python.
¿Sirve de algo revisar el código fuente antes de instalar?
Ayuda, pero tiene límites: el código malicioso suele estar ofuscado o escondido en setup.py, que se ejecuta automáticamente durante la instalación. Revisar manualmente cada dependencia transitiva no es viable a gran escala, por eso el escaneo automatizado es más fiable que la inspección visual.
El siguiente paso
Ejecuta ahora mismo pip install pip-audit && pip-audit sobre tu proyecto actual y revisa el resultado antes de instalar nada nuevo esta semana.
