Tabla de contenidos

1. Dos ataques, una semana
2. Axios 1.14.1 — Un RAT dentro de tu cliente HTTP
3. LiteLLM 1.82.7 — Tu proxy de IA robando tus secretos
4. El patrón: TeamPCP y ataques encadenados
5. ¿Estoy afectado?
6. Cómo proteger tus proyectos hoy
7. Qué protegen los lockfiles (y qué no)
8. La verdad incómoda

---

Dos ataques, una semana

Entre el 24 y el 31 de marzo de 2026, dos de los paquetes más descargados de los ecosistemas JavaScript y Python fueron comprometidos en la fuente:

• LiteLLM (Python, ~95M descargas mensuales) — stealer de credenciales con movimiento lateral en Kubernetes
• Axios (npm, ~83M descargas semanales) — RAT completo (Remote Access Trojan) con payloads específicos por plataforma

No fueron ataques de typosquatting. No fueron forks maliciosos. Los paquetes oficiales en los registros oficiales estaban publicando malware. Si corriste npm install o pip install en el momento equivocado, quedaste comprometido.

Audité mis propios proyectos después de estos incidentes. Esto es lo que encontré y lo que estoy haciendo al respecto.

---

Axios 1.14.1 — Un RAT dentro de tu cliente HTTP

Qué pasó

El 31 de marzo de 2026 a las 00:21 UTC, se publicó una versión maliciosa de Axios (1.14.1) en npm. 39 minutos después llegó 0.30.4 — apuntando a usuarios en la rama legacy 0.x.

El atacante comprometió la cuenta npm del maintainer principal de Axios (jasonsaayman), cambió el email a una dirección de ProtonMail, y publicó directamente via npm CLI — saltándose el pipeline de GitHub Actions por completo.

El payload

El ataque fue operacionalmente sofisticado. Axios 1.14.1 agregó una dependencia fantasma llamada plain-crypto-js que nunca aparecía en el código real. Su único propósito era un hook postinstall.

El dropper (setup.js) usaba ofuscación de dos capas: un array de strings decodificados por XOR (clave: OrDeR_7077) más base64. Contactaba un servidor C2 en sfrclak.com:8000 y descargaba RATs específicos por plataforma:

SO	Payload	Persistencia
macOS	AppleScript → curl → RAT binario	/Library/Caches/com.apple.act.mond (imita daemon de Apple)
Windows	VBScript → PowerShell (copiado como wt.exe) → RAT	%PROGRAMDATA%\wt.exe
Linux	Shell → Python RAT	/tmp/ld.py via nohup

Después de desplegar el RAT, el dropper se autodestruía y reemplazaba package.json con un stub limpio — destruyendo evidencia forense.

Detección y respuesta

Socket detectó plain-crypto-js automáticamente 6 minutos después de la publicación. La comunidad lo reportó en el issue #10604. npm removió las versiones maliciosas en horas.

Pero el daño ya era visible: el otro colaborador de Axios (DigitalBrainJS) declaró públicamente: “Como sus permisos son más altos que los míos… Lo que yo arregle, él lo va a ‘arreglar’ después.” Al momento de escribir, los maintainers no habían recuperado el control total del proyecto.

Ventana de exposición: unas pocas horas. Pero para un paquete con 83 millones de descargas semanales, unas pocas horas son millones de instalaciones.

---

LiteLLM 1.82.7 — Tu proxy de IA robando tus secretos

Qué pasó

El 24 de marzo de 2026, las versiones 1.82.7 y 1.82.8 de LiteLLM se publicaron en PyPI con código malicioso inyectado en proxy_server.py.

El ataque fue parte de una campaña más grande del grupo TeamPCP. La cadena:

1. Primero comprometieron Trivy (scanner de vulnerabilidades de Aqua Security — una GitHub Action)
2. A través de Trivy comprometido, robaron credenciales de PyPI de un maintainer de LiteLLM
3. Con esas credenciales, publicaron directamente en PyPI, saltándose el CI/CD oficial de BerriAI

El payload

Este fue un stealer de credenciales de 3 etapas, mucho más peligroso que el RAT de Axios:

Etapa 1 — Recolección de credenciales: recopilaba +50 categorías de secretos incluyendo SSH keys, variables de entorno, credenciales AWS/GCP/Azure, configs de Kubernetes, contraseñas de bases de datos, .gitconfig, historial de shell, e incluso billeteras de criptomonedas. Si corría en la nube, raspaba los endpoints de metadata de instancias (EC2, GKE).

Etapa 2 — Movimiento lateral en Kubernetes: toolkit para moverse lateralmente dentro de clusters K8s, capaz de comprometer clusters enteros.

Etapa 3 — Backdoor persistente: ejecución remota de código que sobrevivía reinicios.

La parte ingeniosa: la versión 1.82.8 incluía un archivo litellm_init.pth que se ejecutaba automáticamente en cada inicio del intérprete Python — ni siquiera necesitabas hacer import litellm. Solo tenerlo instalado era suficiente.

Todos los datos robados se exfiltraban a models.litellm.cloud — un dominio controlado por el atacante que imita el oficial litellm.ai.

Detección y respuesta

La comunidad detectó el compromiso en ~5.5 horas. BerriAI reconoció el ataque, removió las versiones afectadas de PyPI, y pausó todos los releases nuevos hasta completar una revisión completa del supply chain.

El proyecto DSPy de Stanford abrió el issue #9500 para notificar a sus usuarios, ya que DSPy depende de LiteLLM.

---

El patrón: TeamPCP y ataques encadenados

TeamPCP no atacó LiteLLM de forma aislada. Ejecutaron una campaña de supply chain en cascada a través de 5 ecosistemas:

Trivy (scanner de seguridad) → comprometido
    → LiteLLM (proxy de IA) → comprometido via creds de PyPI robadas
        → Telnyx (comunicaciones) → siguiente objetivo
Checkmarx (herramienta SAST) → comprometido
KICS (scanner de IaC) → comprometido

Cada compromiso les daba credenciales para el siguiente. Las propias herramientas de seguridad se convirtieron en el vector de ataque — las herramientas que usas para escanear vulnerabilidades eran las que entregaban malware.

El ataque a Axios parece ser una operación separada (compromiso directo de cuenta, no encadenado), pero el timing — una semana de diferencia — es notable. Coordinados o no, marzo de 2026 demostró que los ataques supply chain a paquetes tier-1 ya no son teóricos.

---

¿Estoy afectado?

Axios (npm)

# Revisa tu lockfile
grep '"axios"' package-lock.json
# o
grep 'axios@' yarn.lock pnpm-lock.yaml

Versiones afectadas: solo 1.14.1 y 0.30.4. Si tu lockfile muestra cualquier otra versión, estás limpio. Si instalaste entre el 31 de marzo 00:21 UTC y la remoción (unas horas después), revisa.

También busca la dependencia fantasma:

ls node_modules/plain-crypto-js 2>/dev/null && echo "COMPROMETIDO" || echo "Limpio"

LiteLLM (Python)

pip show litellm 2>/dev/null | grep Version
# También busca el archivo de persistencia
find / -name "litellm_init.pth" 2>/dev/null

Versiones afectadas: 1.82.7 y 1.82.8. Si instalaste entre el 24 de marzo 10:39 UTC y ~16:00 UTC, revisa.

Si estás afectado

Esto no es un “actualiza y sigue”. Asume que la máquina está comprometida.

1. No solo actualices — reconstruye el entorno desde cero
2. Rota TODOS los secretos: tokens npm, claves AWS, SSH keys, contraseñas de BD, secretos de CI/CD, API keys
3. Audita Kubernetes si el entorno tenía acceso a clusters
4. Revisa logs de red buscando conexiones a sfrclak.com (Axios) o models.litellm.cloud (LiteLLM)
5. Bloquea IPs C2: 142.11.206.73 (Axios)

---

Cómo proteger tus proyectos hoy

Ninguna de estas es una solución mágica. Los ataques supply chain explotan la confianza, y la confianza es la base de los gestores de paquetes. Pero puedes reducir tu superficie de ataque:

1. Pinea versiones exactas — siempre

// Mal
"axios": "^1.14.0"

// Bien
"axios": "1.14.0"

El prefijo ^ es lo que hace que npm install tome 1.14.1 automáticamente. Sin él, solo recibes actualizaciones cuando tú lo decides.

2. Usa lockfiles y commitéalos

Tu package-lock.json, yarn.lock, o pnpm-lock.yaml es tu defensa contra auto-upgrades. Commitéalo. Siempre. En CI, usa npm ci (no npm install) para respetar el lockfile estrictamente.

3. Desactiva scripts postinstall para paquetes no confiables

El ataque de Axios dependía enteramente de un hook postinstall. Puedes bloquearlo:

# .npmrc
ignore-scripts=true

Luego ejecuta scripts manualmente solo para paquetes en los que confías:

npm rebuild <paquete-confiable>

4. Audita regularmente

npm audit          # npm
pip-audit          # Python (instalar: pip install pip-audit)

5. Usa Socket, Snyk, o similar en CI

Estas herramientas detectan anomalías de comportamiento en paquetes (llamadas de red, acceso al filesystem, ofuscación) — cosas que npm audit no detecta porque aún no son CVEs.

6. Revisa qué acceso tiene tu CI

Ambos ataques explotaron credenciales de CI/CD. Si tu workflow de GitHub Actions tiene tokens de npm/PyPI:

• Usa OIDC trusted publishing en vez de tokens de larga duración
• Restringe los permisos del token al mínimo
• Activa 2FA en tus cuentas de registro (npm, PyPI)

7. Auto-merge solo parches de seguridad

Si usas Dependabot, configúralo para abrir PRs de todas las actualizaciones pero solo auto-mergear parches de seguridad. Crea un workflow de GitHub Actions que verifique si el PR tiene un ghsa-id (GitHub Security Advisory) antes de aprobar y mergear:

# .github/workflows/dependabot-auto-merge.yml
name: Auto-merge Dependabot security patches
on: pull_request
permissions:
  contents: write
  pull-requests: write
jobs:
  auto-merge:
    if: github.actor == 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: Fetch Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
      - name: Auto-merge security updates only
        if: steps.metadata.outputs.ghsa-id != ''
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Así, los version bumps se quedan como PRs abiertos esperando tu revisión manual — solo los fixes de seguridad verificados se mergean automáticamente. Si el ataque de Axios hubiera sido un PR de version bump, habría quedado esperando tu aprobación en vez de ser auto-mergeado.

8. No seas el conejillo de indias

Cuando instales un paquete nuevo, no instales ciegamente la última versión publicada. Revisa el changelog. Elige una versión reciente que lleve días o semanas en la calle sin reportes de problemas. Si el último release salió hace 20 minutos, deja que otro descubra si está comprometido. Tanto Axios 1.14.1 como LiteLLM 1.82.7 fueron detectados en horas — si hubieras esperado un día, nunca los habrías instalado.

9. Monitorea compromisos de cuentas

Suscríbete a advisories de seguridad de tus dependencias críticas. Sigue los canales #security de tu ecosistema y activa las alertas de seguridad de GitHub en tus repositorios.

10. Pinea GitHub Actions a commit SHAs, no a tags

🔄 Actualización (31 de marzo, 2026 — 20:13 hora Chile): Este tip se agregó tras analizar cómo TeamPCP explotó los tags mutables de Git en la GitHub Action de Trivy.

Los tags en Git son mutables por defecto. Cualquiera con acceso push puede mover un tag para que apunte a un commit completamente diferente. TeamPCP explotó exactamente esto — forzaron push en 76+ tags de trivy-action hacia commits maliciosos. Cada pipeline que referenciaba esas acciones por tag empezó a ejecutar código del atacante silenciosamente, sin ningún cambio visible en GitHub.

# Vulnerable — el tag puede moverse a un commit malicioso
- uses: actions/checkout@v4

# Seguro — referencia inmutable a un commit específico
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4

Después de enterarme, audité mis propios workflows y encontré 5 actions pineadas a tags en dos proyectos. Las reemplacé todas por referencias SHA el mismo día. Tomó 10 minutos.

Esto solo aplica a GitHub Actions (.github/workflows/*.yml). npm/pip usan resolución de versiones diferente — los lockfiles y el pineo de versiones manejan esos casos.

---

Qué protegen los lockfiles (y qué no)

Los lockfiles te protegen si: ya tienes una instalación limpia y usas npm ci en CI. El lockfile pinea la versión exacta resuelta, así que una nueva versión comprometida no se descargará.

Los lockfiles no te protegen si: corres npm install (que actualiza el lockfile), o si estás configurando un proyecto nuevo, o si la versión comprometida se publicó antes de tu primera instalación.

Los lockfiles no te protegen de: una versión comprometida publicada antes de que crearas el lockfile. Si 1.14.1 existía cuando corriste npm install por primera vez, está en tu lockfile para siempre hasta que actualices.

La protección real es conciencia + pineo + auditoría + scanning de comportamiento. Ninguna herramienta sola resuelve esto.

---

La verdad incómoda

Los ataques supply chain se están volviendo más sofisticados, no menos. El atacante de Axios usó anti-forense (dropper que se autodestruye). TeamPCP encadenó compromisos a través de herramientas de seguridad. Ambos saltaron los pipelines oficiales de CI/CD yendo directamente al registro.

El ecosistema open source funciona con confianza y maintainers voluntarios. Cuando las credenciales de un solo maintainer se comprometen, millones de proyectos quedan expuestos. No hay solución fácil — es un problema sistémico.

Lo que sí puedes hacer es reducir tu exposición: pinear versiones, auditar regularmente, desactivar scripts, usar scanning de comportamiento, y asumir que cualquier dependencia puede ser comprometida en cualquier momento.

Porque en marzo de 2026, dos de ellas lo fueron.

---

Mis proyectos no fueron afectados — lo verifiqué. Axios estaba pineado en una versión anterior en mis lockfiles, y no uso LiteLLM. Pero el margen fue delgado. Si hubiera corrido npm update esa mañana, este sería un post muy diferente.