Paquete PyPI de Telnyx Comprometido: Otro Ataque a la Cadena de Suministro que No Viste Venir
El 27 de marzo de 2026, alguien ejecutó pip install telnyx y sus credenciales fueron exfiltradas silenciosamente a un servidor controlado por el atacante. Sin errores. Sin advertencias. Solo una instalación de paquete rutinaria que envió malware directamente a producción.
El SDK de Python de telnyx — 742.000 descargas en el último mes — fue comprometido por un actor de amenazas llamado TeamPCP. Dos versiones maliciosas (4.87.1 y 4.87.2) fueron subidas a PyPI. En el momento en que cualquier aplicación ejecutó import telnyx, el malware se ejecutó.
Este no fue un incidente aislado. Fue el quinto ataque importante en nueve días por el mismo grupo. Y si estás construyendo software que depende de paquetes de código abierto — lo cual es todo el mundo — esto debería quitarte el sueño.
Qué le Pasó a Telnyx
Telnyx es una plataforma de comunicaciones en la nube. Su SDK de Python se utiliza en aplicaciones de telefonía, automatización de llamadas e infraestructura de mensajería. El tipo de software que se ejecuta en producción, a menudo con acceso a credenciales sensibles.
El atacante modificó un solo archivo — telnyx/_client.py — e inyectó 74 líneas de código malicioso. Esto es lo que hizo:
En Linux y macOS:
- Descargó un archivo de audio
.wav del servidor del atacante
- Extrajo un script de Python oculto de los datos de audio usando esteganografía
- Recopiló claves SSH, credenciales de la nube, variables de entorno e historial de shell
- Cifró todo con AES-256 y RSA-4096
- Exfiltró el paquete al servidor C2 del atacante
En Windows:
- Descargó un archivo
.wav diferente
- Decodificó un ejecutable de Windows oculto en su interior
- Lo dejó como
msbuild.exe en la carpeta de inicio de Windows
- El binario se ejecuta silenciosamente en cada inicio de sesión — acceso persistente
El truco del .wav es digno de mención. La carga útil no era un script o un binario. Estaba disfrazada como un archivo de audio válido. Los filtros de contenido que permiten descargas de .wav no lo marcarían. Los datos maliciosos se ocultaban en los fotogramas de audio, decodificados en tiempo de ejecución usando XOR. Como señaló Charlie Eriksen de Aikido, TeamPCP utilizó por primera vez esta técnica de esteganografía WAV el 22 de marzo y le gustó lo suficiente como para seguir desplegándola.
Cinco Ataques en Nueve Días: La Campaña de TeamPCP
Telnyx no fue el principio. Fue el último dominó. Aquí está la cronología completa, documentada por Aikido y StepSecurity:
1. Trivy — 19 de marzo
El escáner de vulnerabilidades de código abierto de Aqua Security fue comprometido (CVE-2026-33634, CVSS 9.4). Todas las pipelines de CI/CD que ejecutaban Trivy sin fijar la versión tuvieron sus credenciales exfiltradas. El atacante renombró 44 repositorios de GitHub de Aqua Security con el prefijo tpcp-docs-. Esto le dio a TeamPCP las credenciales robadas que necesitaban para todo lo que siguió.
2. CanisterWorm en npm — 20 de marzo
Usando tokens robados de usuarios de Trivy, TeamPCP publicó una puerta trasera autorreplicante — CanisterWorm — en más de 46 paquetes npm, incluyendo ámbitos como @EmilGroup y @opengov. Con un token npm robado, el gusano enumeró todos los paquetes publicables, actualizó las versiones y publicó código comprometido en todo el ámbito en menos de 60 segundos.
3. Acciones de GitHub de Checkmarx — 23 de marzo
Las acciones de GitHub kics-github-action y ast-github-action fueron comprometidas, junto con dos extensiones de OpenVSX. 35 etiquetas fueron secuestradas en menos de cuatro horas. La carga útil utilizó un nuevo dominio C2 que suplantaba la marca Checkmarx.
4. LiteLLM en PyPI — 24 de marzo
LiteLLM — aproximadamente 95 millones de descargas al mes, ampliamente desplegado como una pasarela LLM centralizada con acceso a credenciales para OpenAI, Anthropic, AWS Bedrock y GCP VertexAI — tuvo las versiones 1.82.7 y 1.82.8 comprometidas. Las credenciales fueron robadas de la pipeline de CI/CD de LiteLLM, que ejecutaba Trivy sin fijar. PyPI puso en cuarentena los paquetes después de unas tres horas.
5. Telnyx en PyPI — 27 de marzo
El compromiso descrito anteriormente. Misma clave pública RSA-4096. Misma firma de exfiltración tpcp.tar.gz. Mismo esquema de cifrado. Paquete diferente, mismo manual.
El patrón: Comprometer una herramienta de confianza → robar credenciales de sus usuarios → usar esas credenciales para comprometer el siguiente objetivo → repetir.
Por Qué los Ataques a la Cadena de Suministro Siguen Funcionando
Esto no es nuevo. Y ese es el problema.
- 2024: La puerta trasera de
xz-utils casi comprometió todos los sistemas Linux del planeta a través de una campaña de ingeniería social de años en un solo mantenedor.
- 2025: Múltiples campañas de typosquatting en PyPI atacaron paquetes populares como
requests, boto3 y tensorflow.
- 2026: TeamPCP está ejecutando una campaña de varias semanas y múltiples ecosistemas — PyPI, npm, Acciones de GitHub, extensiones de VS Code — y están iterando en tiempo real.
La razón por la que esto sigue funcionando se reduce a algunas verdades incómodas:
1. La mayoría de los equipos no fijan las dependencias.
Ejecutar pip install --upgrade telnyx el 27 de marzo extrajo malware silenciosamente. Sin bandera. Sin diferencia. Solo la última versión, porque eso es lo que significaba "última" esa mañana.
2. La cadena de suministro no está en el modelo de amenazas.
La seguridad de las aplicaciones se centra en su código. La seguridad de la infraestructura se centra en sus servidores. Pero el código que se ejecuta en su entorno es abrumadoramente código que usted no escribió. La mayoría de los programas de seguridad tratan los registros de paquetes como fuentes confiables.
3. La detección es difícil.
TeamPCP utilizó esteganografía WAV, codificación base64, ofuscación XOR y subprocesos separados. El malware se ejecuta en el momento de la importación, se limpia a sí mismo y no deja artefactos en el disco. Los escáneres de seguridad tradicionales no detectan esto.
4. El radio de explosión es masivo.
Un paquete comprometido con 742K descargas mensuales significa miles de entornos potencialmente exfiltrados antes de que alguien se dé cuenta. Los 95 millones de descargas mensuales de LiteLLM lo empeoran aún más.
Qué Debes Hacer Ahora Mismo
Si instalaste telnyx==4.87.1 o telnyx==4.87.2:
# Comprueba tu versión
pip show telnyx
# Haz un downgrade inmediatamente
pip install "telnyx==4.87.0"
Luego rota todo: claves SSH, claves API, credenciales de la nube, variables de entorno, contraseñas de bases de datos — cualquier cosa accesible en esa máquina. Busca conexiones salientes a 83.142.209.203 en el puerto 8080 en tus registros de red.
En Windows, busca msbuild.exe en %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ y elimínalo.
Para todos los demás — las soluciones estructurales:
Fija tus dependencias. Usa archivos de bloqueo (pip freeze, poetry.lock, package-lock.json). No dejes que pip install --upgrade te sorprenda.
Habilita la verificación de hash. pip install --require-hashes asegura que solo instales el artefacto exacto que esperas.
Audita tu cadena de suministro de CI/CD. Si tu pipeline instala paquetes, ejecuta Acciones de GitHub o extrae imágenes de contenedores, todas esas son superficies de ataque. Fija las acciones a los SHAs de commit, no a las etiquetas de versión.
Monitorea las conexiones de red anómalas. Las conexiones HTTP salientes a IPs inesperadas desde tus servidores de compilación o aplicación son una señal de alerta.
Usa herramientas de escaneo de dependencias. Servicios como Aikido, StepSecurity, Socket.dev y Snyk pueden detectar paquetes comprometidos — a veces en cuestión de horas.
Asume que tus dependencias serán comprometidas. Construye tu postura de seguridad en torno a esa suposición. El acceso con privilegios mínimos, la segmentación de red, la rotación de credenciales y la monitorización en tiempo de ejecución ya no son opcionales.
El Panorama General
TeamPCP comprometió cinco paquetes en tres ecosistemas en nueve días. Están utilizando técnicas novedosas (esteganografía WAV), iterando rápidamente (corrigiendo errores entre 4.87.1 y 4.87.2) y encadenando credenciales entre herramientas. Esto no es un script kiddie. Este es un actor de amenazas operacionalmente maduro que ejecuta una campaña organizada.
El ecosistema de código abierto es infraestructura. Impulsa todo, desde startups hasta bancos y hospitales. Y ahora mismo, el modelo de seguridad está fundamentalmente roto: una sola cuenta de mantenedor comprometida o un token de CI/CD puede enviar malware a millones de máquinas antes de que nadie parpadee.
Hasta que los registros de paquetes, los sistemas de compilación y las organizaciones traten la seguridad de la cadena de suministro como una preocupación de primera clase — no como una ocurrencia tardía — seguiremos escribiendo estas publicaciones. Y otro paquete caerá.
Referencias
Virendra Singh Bhalothia
