Instale herramientas de programación con IA sin fiarse del nombre de un paquete

Un nombre de producto conocido no es la identidad de un editor

El paquete dice Claude. ¿Quién va a poder ejecutar código en su equipo? Instalar de forma segura una herramienta de programación con IA empieza por establecer esa relación, antes de dar a la herramienta acceso a un repositorio o a credenciales. Un nombre en npm, una descripción convincente y una palabra de producto reconocible no demuestran que el fabricante de ese producto lo haya autorizado.

El 19 de octubre de 2026, GitHub publicó avisos de malware para los ocho nombres de paquetes npm de temática de IA que se enumeran a continuación. Esos avisos son un motivo para investigar una instalación, no una prueba de que los productos oficiales Claude, Codex o ChatGPT se vieran comprometidos. Esta guía se basa en registros de avisos y en documentación oficial; no presenta un análisis del malware ni la ejecución de una muestra. [1][2][3]

Flagged package names; do not install

claude-desktop-setup       @decoopus/claude-setup
codex-setup                chatgpt-desktop-setup
@decoopus/chatgpt-setup     chatgpt-pro-activator
chatgpt-pro-setup-tool     api-anthropic

Una retirada no nos dice qué hacía el payload

Los avisos revisados identifican el malware, pero no ofrecen un análisis de comportamiento para este grupo. A 20 de octubre, las fuentes revisadas aquí no establecen qué archivos se leyeron, si se atacó un almacén de credenciales concreto ni qué persistencia se instaló. Atribuirlo a una familia de infostealers rellenaría el vacío con un relato en lugar de con evidencias. Los paquetes comparten temática; eso por sí solo no demuestra que haya un único operador. [1][2][3]

Las cifras de descargas no resolverían ese problema. Una descarga puede estar automatizada, repetirse o realizarse con fines de análisis; no es una ejecución confirmada ni una persona afectada. Para un equipo que evalúa su propia exposición, la evidencia sólida es el paquete y la versión exactos que figuran en los registros de instalación, dónde se instaló y si el código se ejecutó con acceso a material valioso. Registre que el estado de ejecución es desconocido en lugar de tratar la falta de telemetría como prueba de seguridad.

Empiece por el fabricante y siga después la ruta de distribución

Para Claude Code, Anthropic documenta como identidad oficial en npm @anthropic-ai/claude-code y ofrece además canales de instalación nativos. Un paquete de instalación con un nombre parecido no hereda esa relación. Es un método aplicable a cualquier herramienta de programación: parta de la página de instalación documentada por el fabricante y siga el canal exacto para su plataforma, en lugar de elegir un paquete en un resultado de búsqueda. [4]

El proceso de la empresa debería hacer que la elección verificada sea fácil de repetir. Mantenga un breve registro de herramientas aprobadas con la URL de la documentación, el canal de distribución, el editor esperado, la versión elegida y el responsable de las actualizaciones. Fijar la versión del paquete hace repetibles los bytes o la versión elegidos; no demuestra que la elección inicial fuera legítima. Revise también la vía de actualización, porque la instalación de mañana puede llegar sin que nadie vuelva a copiar un comando.

Proposed approved-tool record

Vendor documentation URL -> exact distribution identity
Version + platform        -> expected artifact
Publisher / signing key   -> trust anchor
Artifact hash             -> recorded bytes
Update mechanism          -> owner and review policy
Runtime permissions       -> separately approved access

Un checksum necesita una fuente de comparación de confianza

Un checksum demuestra que unos bytes coinciden con un resumen esperado. Si un distribuidor no fiable proporciona ambas cosas, la coincidencia no establece quién los produjo. Anthropic documenta manifiestos de versión firmados a partir de Claude Code 2.1.89; los manifiestos anteriores incluyen checksums sin esa firma independiente. Verifique el manifiesto con la huella de la clave de firma documentada y compare después el binario de la plataforma elegida con el manifiesto autenticado. [4]

En Windows, los binarios nativos documentados llevan además una firma Authenticode. Los comandos de inspección siguientes no ejecutan el programa. Compruebe tanto la validez de la firma como la identidad del editor esperado, Anthropic, PBC; un firmante válido cualquiera no es suficiente. Son pasos de verificación documentados, no el informe de que se descargara o verificara un binario para este artículo. [4]

# Inspect an already-downloaded binary; do not execute it
Get-AuthenticodeSignature -LiteralPath .\claude.exe |
  Select-Object Status, SignerCertificate
Get-FileHash -LiteralPath .\claude.exe -Algorithm SHA256

# Compare signer and hash with the vendor's documented trust chain.

Un origen verificado sigue necesitando una decisión sobre permisos

Las comprobaciones de firma y procedencia responden a preguntas sobre el origen. No demuestran que el código esté libre de comportamiento malicioso o de vulnerabilidades. npm lo dice expresamente sobre la procedencia: vincula un paquete con información de su código fuente y de su compilación para que pueda revisarse, no certifica que sea inofensivo. Trate el resultado como una evidencia más sobre el artefacto, no como un motivo para darle todas las credenciales del equipo. [5]

Mi siguiente pregunta es a qué puede acceder el programa instalado. En una herramienta de programación aprobada, revise el contenido del repositorio, las variables de entorno, los almacenes de credenciales y el acceso a red que quedan expuestos a su proceso. Separe el acceso de desarrollo de las credenciales de producción y haga que cualquier permiso adicional sea deliberado. Esta recomendación se refiere a la autoridad de ejecución en general; no afirma que los paquetes retirados usaran una técnica de recolección concreta.

¿Omitir los scripts de instalación hace segura una CLI?

La opción ignore-scripts de npm suprime los scripts de package.json durante la instalación, pero la documentación indica expresamente que los scripts solicitados de forma explícita, como npm run, siguen ejecutando su comando. No es un sandbox para un programa que se lanza después. Un equipo que bloquea los scripts del ciclo de vida y luego ejecuta una CLI sin verificar ha tomado otra decisión de ejecución. Evalúe esa decisión por separado. [6]

También hay un coste práctico de compatibilidad: algunos paquetes legítimos necesitan pasos de instalación. La respuesta es una excepción explícita, revisada y justificada, no desactivar el control de forma global porque una herramienta falla. Distinga en el registro de aprobación la inspección de metadatos, la instalación y la ejecución. Cada paso aporta una evidencia distinta y puede exponer capacidades diferentes; ninguno debería sustituir en silencio al siguiente.

Si instaló un paquete señalado, conserve las evidencias

Los avisos de malware recomiendan tratar como comprometido el equipo en el que se instaló el paquete y rotar los secretos expuestos desde otro ordenador. Siga esas indicaciones con su equipo de respuesta a incidentes: aísle el entorno afectado, conserve los registros de instalación y de procesos, y determine a qué credenciales podía acceder. Eliminar el paquete no basta para demostrar que desaparecieron el acceso o la persistencia resultantes. [1][2]

Esto es deliberadamente distinto de afirmar un payload concreto. Puede tomarse en serio la contención y, al mismo tiempo, ser preciso sobre lo que se desconoce. Conserve en el expediente los identificadores y las versiones de los paquetes, junto con las evidencias de ejecución y las credenciales revisadas. No pegue valores de secretos activos en un ticket ni utilice un equipo no fiable para generar sus sustitutos.

Convierta la instalación en una decisión de ingeniería

Pediría a un equipo que demostrara una cadena completa para una herramienta aprobada: el fabricante remite a este canal, el artefacto coincide con esta versión autenticada y el proceso recibe este acceso documentado. Otro ingeniero puede revisar esa cadena. Una captura de un logotipo conocido o un contador de descargas no pueden sustituirla.

Es un trabajo de ingeniería de software seguro porque estas decisiones pasan a formar parte de la incorporación de nuevos miembros, de la CI y de la automatización de actualizaciones. Si cada desarrollador tiene que reconstruir solo la decisión de confianza, la organización ha delegado un control de seguridad repetible en un resultado de búsqueda. Construya una vez la ruta verificada, asígnele un responsable y mantenga sus permisos de ejecución lo bastante acotados como para poder defenderlos.