Extensiones de código: auditoría antes de instalar

⏱️ Lectura: 16 min

Kevin Beaumont, el investigador que rastreó WannaCry y publica como @GossiTheDog, escribió en Mastodon que la extensión de Claude Code habría sido comprometida. Anthropic no confirmó el reporte y la publicación no aporta indicadores técnicos verificables.

📑 En este artículo

1. TL;DR
2. ¿Qué es auditar extensiones de código?
3. Por qué importa: de una denuncia en Mastodon a un backdoor confirmado en LiteLLM
4. Cómo funciona una extensión maliciosa por dentro
   1. Scripts de instalación automática
   2. Telemetría no declarada
   3. Dependencias transitivas comprometidas
   4. Permisos amplios en extensiones de asistentes de código
5. Cómo empezar: auditar una extensión paso a paso
   1. Checklist para auditar extensiones de código antes de instalar
   2. Para extensiones de editor (VS Code, JetBrains)
6. Qué hacer si ya instalaste una extensión sospechosa
7. Casos de uso reales: más allá de LiteLLM
8. Errores comunes y buenas prácticas
9. Comparativa de herramientas de auditoría
10. Profundizando: procedencia, SBOM y firmas criptográficas
    1. Software Bill of Materials (SBOM)
    2. Procedencia verificable con SLSA
    3. Firmas con Sigstore
    4. Builds reproducibles
11. Preguntas frecuentes
    1. ¿Cómo hacer control de dependencias de software sin pagar herramientas comerciales?
    2. ¿La denuncia de Kevin Beaumont sobre Claude Code se confirmó?
    3. ¿Qué diferencia hay entre un backdoor y telemetría excesiva en una extensión?
    4. ¿Alcanza con revisar el código fuente en GitHub antes de instalar un paquete?
    5. ¿Con qué frecuencia hay que repetir la verificación de paquetes de terceros?
12. Referencias

Da igual que esa denuncia puntual se confirme o no: el mismo patrón, código oficial que termina filtrando credenciales, explica por qué cada vez más equipos tratan cada extensión, plugin o paquete como código no confiable hasta probar lo contrario. Y ese patrón ya tiene un caso confirmado este año: LiteLLM 1.107.0 en PyPI.

TL;DR

• Revisar permisos, red y dependencias antes de instalar detecta backdoors como el de LiteLLM 1.107.0 en PyPI.
• Un postinstall script en npm o un hook de importación en pip puede exfiltrar credenciales sin mostrar ningún error.
• La bandera –ignore-scripts de npm y pip-audit detectan o bloquean código de instalación sin revisar.
• osv-scanner cruza tu lockfile contra la base pública de OSV.dev antes de que el ataque llegue a producción.
• Una extensión marcada como oficial no garantiza ausencia de telemetría oculta ni de dependencias comprometidas.

¿Qué es auditar extensiones de código?

Auditar extensiones de código es el proceso de revisar permisos, llamadas de red y dependencias de un plugin o paquete antes de instalarlo, aunque venga de un marketplace oficial. Busca detectar robo de credenciales, telemetría oculta o código inyectado antes de que se ejecute en tu máquina o en un pipeline de CI/CD.

El término “oficial” genera una falsa sensación de seguridad. Un marketplace de extensiones, un registro de paquetes como npm o PyPI, o la cuenta verificada de un proyecto open source certifican la identidad de quien publica, no la ausencia de código malicioso en cada versión. La auditoría llena exactamente ese espacio: la distancia entre “lo publicó quien dice ser” y “el código que publicó es seguro”.

Por qué importa: de una denuncia en Mastodon a un backdoor confirmado en LiteLLM

La publicación de Beaumont no incluye hashes ni un análisis técnico público. Es la afirmación de un investigador reconocido, no una auditoría publicada ni una confirmación de Anthropic. Tratarla como hecho consumado repetiría el mismo error que cualquier guía de seguridad critica: aceptar una fuente sin corroborarla.

El riesgo real no depende de si esa denuncia puntual se confirma. Ya existe un caso documentado con el mismo patrón: LiteLLM, el proxy open source para unificar APIs de modelos de lenguaje, publicó en PyPI la versión 1.107.0 con un robacredenciales y una puerta trasera incluidos en el paquete. Quien instaló esa versión con un simple pip install litellm==1.107.0 ejecutó ese código con los mismos permisos que su propia aplicación.

La lección no es “no uses LiteLLM” ni “no confíes en Anthropic”: es que ninguna plataforma (PyPI, npm, un marketplace de extensiones) revisa línea por línea cada publicación antes de distribuirla. El control de calidad recae, en la práctica, en quien instala.

Cómo funciona una extensión maliciosa por dentro

La mayoría de los ataques por este canal no explotan una vulnerabilidad de memoria ni un exploit sofisticado. Abusan de un mecanismo legítimo que casi todos los gestores de paquetes ofrecen: ejecutar código automáticamente durante la instalación.

Scripts de instalación automática

En npm, el campo scripts.postinstall de un package.json corre apenas termina de descargarse el paquete, sin que el usuario lo apruebe explícitamente. En pip, el equivalente clásico es un setup.py con código a nivel de módulo, fuera de cualquier función, que Python ejecuta durante el build. Ambos mecanismos existen por razones legítimas, como compilar una dependencia nativa, pero son indistinguibles a simple vista de un script que exfiltra variables de entorno.

Telemetría no declarada

Una extensión de editor (VS Code, JetBrains) puede declarar permisos amplios, como acceso a archivos o a red, que el marketplace aprueba porque son parte del modelo de negocio del propio editor. Nada impide que, además de la función anunciada, la extensión envíe eventos a un dominio de analítica propio sin romper ninguna regla formal del marketplace.

Dependencias transitivas comprometidas

El paquete que instalás a propósito casi nunca es el problema. El problema suele estar dos o tres niveles abajo, en una dependencia de una dependencia que nadie en tu equipo revisó nunca. Un npm ls --all en un proyecto mediano fácilmente devuelve varios cientos de paquetes transitivos.

Permisos amplios en extensiones de asistentes de código

Las extensiones de asistentes de IA para programar, como Claude Code, GitHub Copilot o Cursor, son un caso particular porque su función misma requiere acceso amplio: leer el repositorio completo, ejecutar comandos de shell y, en muchos flujos, leer variables de entorno donde suelen vivir tokens de API y credenciales de nube. Ese nivel de acceso no es un error de diseño, es necesario para que la herramienta funcione, pero convierte a cualquier extensión de este tipo en un objetivo de alto valor: comprometerla una sola vez da acceso a todo lo que el desarrollador podría tocar.

sequenceDiagram
    participant Dev as Desarrollador
    participant Reg as Registro de paquetes
    participant Script as Script de instalación
    participant C2 as Servidor del atacante
    Dev->>Reg: pip install litellm 1.107.0
    Reg-->>Dev: entrega el paquete
    Dev->>Script: ejecuta instalación
    Script->>C2: envía variables de entorno
    Note over Dev,C2: la exfiltración ocurre antes del primer uso del paquete

⚠️ Ojo: el flag --ignore-scripts de npm bloquea los scripts de instalación de TODAS las dependencias, no solo las sospechosas. Puede romper paquetes legítimos que compilan binarios nativos durante el install.

Cómo empezar: auditar una extensión paso a paso

Esta checklist asume que ya tenés Node.js y npm instalados, cualquier versión reciente de Node incluye npm. Si trabajás en Python, los comandos equivalentes usan pip y se indican entre paréntesis.

Checklist para auditar extensiones de código antes de instalar

Antes de correr npm install o agregar una extensión desde un marketplace, cuatro pasos reducen la mayoría del riesgo:

1. Leer el manifiesto sin instalar. npm view express scripts --json muestra los scripts declarados sin descargar ni ejecutar nada. Salida esperada para un paquete sin scripts de instalación: {}. Si aparece una clave postinstall o preinstall, revisá ese script antes de seguir.
2. Revisar el árbol de dependencias. npm ls --all (o pip show -f <paquete> en Python) lista cada dependencia transitiva. Un paquete chico con cientos de líneas de dependencias es una señal de que auditarlo a mano no es viable y conviene apoyarse en una herramienta automatizada.
3. Escanear contra vulnerabilidades conocidas. osv-scanner, de Google, cruza tu package-lock.json o requirements.txt contra la base pública de OSV.dev: osv-scanner scan source --lockfile=package-lock.json. Si no hay coincidencias, el comando termina sin listar vulnerabilidades y devuelve código de salida 0.
4. Observar el tráfico de red en una instalación aislada. Corré la instalación dentro de un contenedor o una VM descartable y capturá las conexiones salientes con strace -f -e trace=network -o salida.log npm install. Un paquete que solo contacta registry.npmjs.org es lo esperado; una conexión a un dominio desconocido en ese log es la señal de alarma que justifica no seguir.

Para extensiones de editor (VS Code, JetBrains)

El mismo principio aplica a extensiones de editor, con una diferencia práctica: la mayoría no expone un manifiesto tan legible como package.json. code --list-extensions --show-versions lista lo que ya tenés instalado; antes de agregar una nueva, revisar su página en el marketplace por los permisos declarados y, sobre todo, por quién la publica (la cuenta del propio proyecto frente a un fork de un tercero) evita la mayoría de los casos de suplantación.

flowchart TD
    A["Extensión nueva a instalar"] --> B{"Publicador verificado?"}
    B -->|"No"| X["Rechazar"]
    B -->|"Si"| C{"Scripts de instalación declarados?"}
    C -->|"Si"| D["Revisar el script línea por línea"]
    C -->|"No"| E{"Dependencias transitivas excesivas?"}
    D --> E
    E -->|"Si"| F["Escanear con osv-scanner"]
    E -->|"No"| G["Instalar y monitorear tráfico de red"]
    F --> G

Qué hacer si ya instalaste una extensión sospechosa

Si la auditoría llega tarde y la extensión ya está instalada y en uso, el orden de las acciones importa más que la velocidad de cada una.

1. Rotar credenciales primero, investigar después. Cualquier token de API, clave de nube o contraseña accesible desde el entorno donde corrió la extensión se considera comprometido. Rotarlas no espera a confirmar si hubo exfiltración real.
2. Revisar logs de red salientes. Si tenés un firewall de salida o un proxy corporativo, buscá conexiones hacia dominios que no correspondan a los registros oficiales del paquete (registry.npmjs.org, pypi.org, el dominio propio del proyecto) en la ventana en que la extensión estuvo activa.
3. Buscar persistencia. Un backdoor que solo roba credenciales una vez es grave pero acotado; uno que instala una tarea programada, un hook de git o un servicio que sobrevive a la desinstalación es un incidente de otra escala. Revisar crontab -l, hooks en .git/hooks/ y servicios nuevos del sistema cubre los vectores de persistencia más comunes.
4. Documentar la cadena completa. Versión exacta instalada, fecha y qué credenciales estaban accesibles en ese momento. Esa información es la que necesita cualquier reporte posterior al equipo de seguridad o al propio proyecto afectado.

flowchart LR
    A["Extensión sospechosa detectada"] --> B["Rotar credenciales"]
    B --> C["Revisar logs de red"]
    C --> D["Buscar persistencia"]
    D --> E["Documentar el incidente"]

📌 Nota: una extensión de IA para programar suele pedir acceso de lectura y escritura a todo el repositorio y a las variables de entorno del shell donde corre. Ese nivel de acceso es exactamente lo que vuelve atractivo a este vector de ataque.

Casos de uso reales: más allá de LiteLLM

El patrón no es exclusivo de un ecosistema. En 2026, investigadores documentaron una campaña atribuida a actores de Corea del Norte que infectó más de 1.700 paquetes distribuidos entre npm, PyPI, Go y Rust con malware, aprovechando el mismo mecanismo: un script de instalación o un hook de importación que corre sin revisión humana. La escala cambia, el vector es el mismo.

El caso de Claude Code que denuncia Beaumont, confirmado o no, encaja en esa misma categoría de riesgo: una extensión con acceso directo al entorno de desarrollo (variables de entorno, tokens de API, archivos del proyecto) es un objetivo de alto valor precisamente porque corre con los mismos permisos que el desarrollador que la instaló.

Para equipos en LATAM que integran agentes de IA en su flujo de trabajo sobre repositorios con información de clientes, el costo de una credencial filtrada no es solo técnico: puede implicar una notificación obligatoria a usuarios según la legislación local de protección de datos. La auditoría previa, en ese contexto, es tanto parte del cumplimiento como de la seguridad.

Errores comunes y buenas prácticas

• Confiar en el badge de “verificado” sin revisar el contenido. Un marketplace certifica identidad del publicador, no la ausencia de código malicioso en cada actualización.
• No fijar versiones exactas. Un rango como ^1.107.0 en vez de 1.107.0 exacto en el lockfile permite que una actualización comprometida se instale sola en el próximo npm install.
• Ignorar los scripts de instalación por costumbre. La mayoría de los desarrolladores nunca leyó un postinstall de una dependencia que usa todos los días.
• No monitorear tráfico de salida. Sin un registro de qué dominios contacta una herramienta, una exfiltración de credenciales puede pasar meses sin detectarse.
• Auditar una sola vez y olvidarse. Una extensión limpia hoy puede recibir una actualización comprometida la semana próxima; la auditoría es un proceso continuo, no un trámite único.

Comparativa de herramientas de auditoría

Profundizando: procedencia, SBOM y firmas criptográficas

Para equipos que gestionan cientos de dependencias, revisar manifiestos a mano no escala. La industria converge en varios mecanismos complementarios.

Software Bill of Materials (SBOM)

Un SBOM es un inventario formal, en formato SPDX o CycloneDX, de cada componente que compone un artefacto de software, con su versión exacta y su licencia. Herramientas como syft generan un SBOM a partir de una imagen de contenedor o un repositorio, lo que permite responder en segundos a “¿usamos en algún lado la versión comprometida de este paquete?” en vez de revisar proyecto por proyecto.

Procedencia verificable con SLSA

El marco SLSA (Supply-chain Levels for Software Artifacts) define niveles de garantía sobre cómo se construyó un artefacto, desde “el build corrió en algún lado” hasta “el build corrió en un sistema aislado, con el código fuente y los pasos de build firmados criptográficamente y verificables por un tercero”. Un paquete con procedencia SLSA de nivel alto reduce, aunque no elimina, la posibilidad de que alguien inserte código entre el repositorio y el registro de distribución.

Firmas con Sigstore

Sigstore permite firmar un artefacto sin gestionar una clave privada permanente: usa certificados de corta duración ligados a una identidad, como una cuenta de GitHub, y registra la firma en un log público e inmutable. Verificar esa firma contra una imagen confirma esa cadena. Sin esto, comprobar que un binario publicado corresponde exactamente al código fuente público depende de la buena fe del mantenedor.

Builds reproducibles

Un build reproducible permite que cualquiera, compilando el mismo código fuente con las mismas herramientas, obtenga exactamente el mismo binario, byte a byte, que el que publicó el mantenedor. Si dos partes independientes reproducen el mismo resultado, la posibilidad de que el binario publicado contenga algo que no está en el código fuente público baja drásticamente. Debian y el proyecto Tor son dos de los ejemplos más antiguos de este enfoque aplicado en producción.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: correr npm view <paquete> scripts --json sobre una dependencia que ya uses todos los días y confirmar que no declara ningún postinstall que no hayas revisado antes.

Preguntas frecuentes

¿Cómo hacer control de dependencias de software sin pagar herramientas comerciales?

Con herramientas gratuitas alcanza para la mayoría de los casos: npm audit y pip-audit son gratuitos, osv-scanner es open source, y revisar manifiestos con npm view no cuesta nada. El gasto de herramientas comerciales como Socket.dev o Snyk está en el monitoreo continuo automatizado, no en la capacidad básica de detección.

¿La denuncia de Kevin Beaumont sobre Claude Code se confirmó?

No, al momento de escribir este artículo Anthropic no publicó una confirmación ni un desmentido público de la publicación en Mastodon. Tratala como una alerta a seguir, no como un hecho establecido.

¿Qué diferencia hay entre un backdoor y telemetría excesiva en una extensión?

Un backdoor ejecuta código con la intención explícita de dar acceso no autorizado o robar datos, como el caso de LiteLLM. La telemetría excesiva suele estar declarada en algún lugar de los términos de uso, aunque sea poco visible; sigue siendo un problema de privacidad, pero no es, técnicamente, un ataque.

¿Alcanza con revisar el código fuente en GitHub antes de instalar un paquete?

No siempre. El código publicado en el registro (npm, PyPI) no siempre coincide con el del repositorio público; sin procedencia verificable, como SLSA o Sigstore, no hay garantía automática de que ambos sean idénticos. Por eso conviene auditar el paquete que efectivamente se instala, no solo el repositorio.

¿Con qué frecuencia hay que repetir la verificación de paquetes de terceros?

Como mínimo, en cada actualización de versión mayor o menor de una dependencia crítica, y de forma automatizada, con osv-scanner u otra herramienta similar, en cada build de CI. Una revisión hecha una sola vez pierde valor en cuanto aparece la próxima actualización.

Referencias

• Mastodon (@GossiTheDog): la publicación de Kevin Beaumont que denuncia, sin confirmación pública, el presunto compromiso de la extensión de Claude Code.
• Repositorio de LiteLLM en GitHub: proyecto open source afectado por el paquete comprometido publicado en PyPI.
• osv-scanner: escáner de Google que cruza lockfiles contra la base de datos pública de vulnerabilidades OSV.dev.
• Documentación oficial de npm sobre scripts: referencia de cómo y cuándo corren los scripts de instalación como postinstall.
• SLSA (Supply-chain Levels for Software Artifacts): marco de niveles de procedencia verificable para artefactos de software.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Lewis Kang’ethe Ngugi en Unsplash