En este artículo
Malware en ZIP enlazado desde README: revisa qué instalas
Has aprobado una skill de IA. Tiempo después, su README apunta a un archivo que nunca revisaste, aunque SKILL.md sigue igual. La comprobación anterior continúa dando el mismo resultado. Tu decisión de instalar se apoya ahora en un elemento que aquella revisión no cubría.
Un señuelo con malware en un ZIP enlazado desde README puede redirigir la instalación sin modificar las instrucciones de la skill. Revisa conjuntamente el repositorio, el commit exacto, el destino del enlace, el contenido del archivo y los privilegios solicitados. Conserva un registro fiable y repite la revisión si cambian el código, los bytes descargados, los archivos copiados o el alcance de ejecución.
Al revisar una instalación, decides qué componentes pueden usarse y con qué permisos. El ejercicio sin conexión que presentamos muestra los límites de esa decisión. Incluye un cambio de empaquetado inocuo que exige investigar la diferencia, sin justificar por ello un diagnóstico de malware.
Investigación verificada: 5 de noviembre de 2026. La descripción de la campaña se basa en pruebas publicadas por sus investigadores. Nuestra comparación utiliza archivos de texto generados, ZIP y commits locales de Git. No realiza solicitudes de red ni ejecuta ningún instalador candidato.
Independencia y marcas: Wavect publica esta página y es también un proveedor, así que tenemos un interés comercial en ella. No estamos afiliados a las demás empresas nombradas aquí, no contamos con su respaldo y no somos socios suyos, y todos los nombres de empresa, marcas y marcas registradas de terceros pertenecen a sus respectivos titulares. Las afirmaciones sobre otros proveedores proceden de fuentes públicamente accesibles, sobre todo de sus propias páginas publicadas, en la fecha de revisión indicada en esta página, y pueden haber cambiado desde entonces. Verifícalas directamente antes de decidir. Esta página se ha redactado según nuestro leal saber y entender, con la intención de mantenernos objetivos. Si crees que algo aquí es inexacto o injusto, escríbenos y lo corregimos: [email protected]
¿Qué demuestra el informe sobre los 73 repositorios?
El 4 de noviembre de 2026, Thomas Roccia, de SecurityBreak, publicó una lista de indicadores sobre 73 repositorios de GitHub que simulaban ofrecer herramientas para agentes de IA. Su comprobación de ese día registró 51 accesibles y 22 con respuesta 404. Son observaciones de repositorios, no infecciones ni disponibilidad actual.
Roccia describió copias de mcp-superset, hermes-agent y ContinuousClaude. Los archivos de skills y configuración examinados parecían limpios, pero el README dirigía a ZIP incluidos en el repositorio e indicaba omitir una advertencia de Windows. Uno estaba en .claude/hooks/config/. Los paquetes descritos combinaban un lanzador por lotes, LuaJIT y código Lua ofuscado presentado como texto.
El anuncio identifica SmartLoader, habitualmente asociado con StealC. No demuestra que todos los repositorios entregaran esa carga. La lista separa indicadores confirmados en muestras de otros de campaña, no confirmados en esas versiones. Siguen sin conocerse el número de víctimas y la identidad de todos los operadores. Tampoco demuestra que los proyectos legítimos originales fueran comprometidos.
¿Por qué un SKILL.md limpio no descarta malware en el ZIP del README?
Un resultado limpio de SKILL.md describe el archivo examinado. La instalación puede incluir otras instrucciones, scripts, archivos descargados y ajustes de arranque. Si la revisión termina en el archivo de la skill, no justifica ejecutar esos componentes adicionales. La pregunta pendiente es qué archivos y acciones cubre la aprobación.
La especificación de Agent Skills define cada skill como un directorio cuyo punto de entrada obligatorio es SKILL.md. Puede contener scripts, referencias, recursos y otros archivos. Esa estructura ayuda a delimitar la revisión: inventaría el directorio y sigue las dependencias que introduce la instalación. El archivo de entrada no representa por sí solo todo el paquete.
Imagina que alguien revisa unas instrucciones para dar formato a documentos, no encuentra comandos sospechosos y las aprueba. Otro README pide descargar un entorno de ejecución. Esa dependencia necesita su propia explicación: ¿por qué ese entorno, de ese proveedor, en esa revisión y con esos permisos? Que el primer archivo resulte familiar no responde a esas preguntas.
También importa cómo se ejecuta cada componente. En el análisis de Netskope sobre muestras relacionadas con SmartLoader, un lanzador por lotes entrega a un intérprete un archivo de texto que contiene Lua. Examinar solo la extensión no revela qué hace el comando con su contenido. Un archivo de texto puede aportar código que ejecute un intérprete legítimo.
Delimita la conclusión: «se revisaron estas instrucciones» aporta información útil. Extenderla a cualquier descarga o comando posterior deja elementos sin evaluar. La misma pregunta sobre el alcance surge cuando cambian las instrucciones compartidas de una skill, aunque ese otro flujo necesita sus propios controles de evaluación.
¿Qué debes revisar antes de instalar?
La revisión debe vincular al proveedor y la versión del código con los archivos, el arranque y los permisos que vas a habilitar. Recomendamos conservar un registro fuera del directorio donde pueda escribir el software candidato. Cada entrada debe precisar qué se comprobó y qué cambio exigiría una nueva decisión.
| Elemento revisado | Evidencia que debes conservar | Pregunta que responde |
|---|---|---|
| Proveedor y repositorio | Propietario/repositorio exactos y referencia independiente utilizada para identificarlos. | ¿Estamos revisando el proyecto previsto? |
| Versión del código | ID completo del commit y archivos de código incluidos en la revisión. | ¿Qué revisión se examinó? |
| Destino del README | Ruta resuelta del archivo o URL final de descarga, con las redirecciones relevantes. | ¿Qué selecciona la instrucción de instalación? |
| Archivo comprimido | SHA-256 del archivo, rutas internas y contenidos revisados. | ¿Son los bytes y archivos que se examinaron? |
| Copia instalada | Manifiesto de rutas y hashes esperados en la instalación. | ¿La copia o el empaquetado modificaron lo que se cargará? |
| Arranque | Comando exacto, argumentos, directorio de trabajo y configuración. | ¿Qué se ejecutará al habilitar la herramienta? |
| Permisos | Acceso necesario al sistema de archivos, destinos de red y credenciales. | ¿A qué podrá acceder esa ejecución? |
| Responsable de la decisión | Revisor, fecha, uso permitido y motivo de cada excepción. | ¿Quién puede aprobar un elemento modificado? |
Empieza por el recorrido real de la instalación. Un ZIP incorporado al repositorio forma parte de esa versión del código. Si el README te dirige a otro lugar, introduce un objeto que se obtiene por separado. Una etiqueta de versión, un botón de descarga o un nombre de archivo no bastan para demostrar que los bytes seleccionados entraban en la revisión.
Tu equipo debe controlar los valores de referencia. Comparar el archivo candidato con un checksum que publica a su lado el mismo proveedor desconocido puede demostrar coherencia entre ambos. No demuestra que tu revisor haya aprobado ninguno. Registra el hash esperado después de revisar el contenido y protege ese registro frente al software candidato y su instalador.
Nuestro analizador de riesgos de instalación MCP ayuda a examinar patrones en comandos o configuraciones pegados. No descarga repositorios ni inspecciona los bytes de un archivo comprimido. Utiliza su resultado para la parte que analiza y conserva aparte las pruebas que faltan.
¿Qué cambios invalidaron la revisión en nuestra prueba sin conexión?
La comparación de todos los datos registrados solo coincidió con el caso sin cambios de nuestra prueba de seis escenarios. Revisar únicamente SKILL.md dio coincidencia en todos. Comparar el commit detectó los dos cambios incorporados al repositorio, pero no los externos a esa versión. El resultado mide coherencia con un registro anterior, no presencia de malware.
El laboratorio completó 24 comprobaciones registradas con Python 3.12.14 y Git 2.51.1. Crea repositorios inocuos con un archivo de skill, un README y dos ZIP idénticos que solo contienen texto. También representa una descarga externa mediante un archivo local y copia un archivo de texto conocido en un directorio de instalación separado.
Cada escenario parte de la misma referencia y modifica un elemento. El registro contiene el commit, hashes del código, del archivo comprimido y sus miembros, y de los archivos instalados. La identidad del proveedor y los permisos de ejecución quedan fuera del laboratorio. «Coincide» significa igualdad con el registro de referencia. «Difiere» exige explicar el cambio antes de reutilizar la revisión anterior.
| Escenario independiente | Hash de SKILL.md | Commit de Git | Todos los datos del laboratorio | Qué cambió |
|---|---|---|---|---|
| Referencia sin cambios | Coincide | Coincide | Coincide | Nada. |
| El README apunta al otro ZIP del repositorio | Coincide | Difiere | Difiere | Solo el README y su nuevo commit; los dos ZIP ya contenían el mismo texto inocuo. |
| Cambia el contenido del ZIP del repositorio | Coincide | Difiere | Difiere | Los bytes del archivo y el contenido de sus miembros, incorporados en una nueva revisión. |
| La URL externa no cambia, pero sí la descarga simulada | Coincide | Coincide | Difiere | Los bytes del archivo externo y el contenido de sus miembros. |
| Cambia el archivo copiado a la instalación | Coincide | Coincide | Difiere | El archivo de texto instalado. |
| Se vuelve a empaquetar el ZIP externo sin cambios dañinos | Coincide | Coincide | Difiere | Solo el comentario del ZIP; el contenido de sus miembros sigue idéntico. |
El caso del README es sencillo a propósito. Redirige un enlace relativo real de Markdown entre dos archivos ya incorporados al repositorio. Ninguno contiene malware. Comprobar solo el archivo de la skill pasa por alto la instrucción modificada; comparar el commit sí la detecta. El ejercicio evita así sugerir que fijar correctamente un commit no cubre los archivos incorporados en él.
Los casos de descarga externa y nuevo empaquetado son extensiones hipotéticas del problema de revisión. No describen hallazgos adicionales sobre los repositorios de Roccia. No se solicita ninguna URL: un archivo local representa los bytes descargados.
El nuevo empaquetado sirve como control negativo. Cambia el hash del ZIP aunque su texto interno siga igual. Un procedimiento que lo clasifique inmediatamente como «malware» afirma más de lo que puede demostrar. Abre de nuevo la revisión, examina el cambio de empaquetado y decide si corresponde emitir un registro actualizado.
Cada escenario ejecuta cuatro comprobaciones: campos modificados exactos, resultados de las comparaciones, registro de referencia intacto y árbol de trabajo de Git limpio. Seis escenarios por cuatro comprobaciones son 24. Por tanto, las diferencias que no detecta la comparación del commit no se deben a modificaciones de código pendientes de incorporar.
¿Cómo puedes reproducir la comparación sin ejecutar un instalador?
Lee el código independiente del laboratorio y ejecuta después el ejercicio de datos generados con Python y Git. El script crea sus propios candidatos inocuos y escribe el resultado JSON bajo el directorio de trabajo elegido. No acepta un repositorio objetivo ni una URL de descarga, y nunca ejecuta los archivos generados.
Descarga el código legible del laboratorio en Python y el resultado registrado en JSON. Necesitas Python 3.10 o posterior y Git, sin paquetes adicionales de Python. Tras examinar el código, ejecuta estos comandos desde el directorio donde lo guardaste:
python3 readme-zip-review-lab.py \
--work-dir .agent-cache/readme-zip-review-lab
python3 -m json.tool \
.agent-cache/readme-zip-review-lab/results.jsonContrasta observed_controls con expected_controls en cada escenario. El resultado incluye los campos que cambiaron, los inventarios, las versiones de las herramientas y el SHA-256 del código del laboratorio. Una comprobación fallida detiene la ejecución; antes de iniciar otra, el script elimina cualquier archivo antiguo de resultados satisfactorios.
El registro de referencia se guarda fuera de los directorios del candidato y de la copia instalada. En un sistema desplegado también tendrías que impedir que esos procesos pudieran escribir en él. Este laboratorio solo comprueba que su propio registro permanece intacto durante el ejercicio.
Los inventarios cubren rutas y contenidos de archivos regulares. No evalúan permisos, enlaces simbólicos, extracción de archivos arbitrarios, firmas, comportamiento del agente ni cambios entre la comprobación y la ejecución. El caso de la copia instalada parte de copiar texto conocido de forma segura. No justifica ejecutar primero un instalador desconocido y evaluar después los daños.
¿Qué demuestran un commit fijo o un checksum coincidente?
Fijar un commit identifica la versión seleccionada del código; un checksum coincidente acredita que los bytes concuerdan con una referencia fiable. Su utilidad se limita a lo que revisaste y a los componentes que utiliza la instalación. Una coincidencia puede conservar una mala decisión; un cambio de empaquetado inocuo puede generar una diferencia que necesite explicación.
Distingue tres objetos: un ZIP guardado como archivo del repositorio, el archivo de código fuente que genera GitHub y una descarga obtenida de otro destino. El primero forma parte del commit seleccionado. El segundo empaqueta los contenidos del código. El tercero requiere sus propias pruebas sobre el artefacto descargado.
La documentación de GitHub sobre estabilidad de archivos indica que los generados a partir de un commit conservan el contenido mientras ese commit siga disponible y no cambie el nombre del repositorio. Las ramas y etiquetas pueden moverse. GitHub también distingue el contenido extraído de los bytes del archivo comprimido, que pueden variar al cambiar los ajustes de compresión.
Por eso el laboratorio guarda tanto el hash del ZIP como el inventario de sus miembros. Si el hash no coincide, no lo sustituyas sin más por el de la nueva descarga. Conserva el registro anterior, determina qué cambió y pide al responsable de la revisión que acepte o rechace la sustitución. De lo contrario, solo estarás registrando lo último que haya llegado.
La procedencia responde a otra parte de la revisión. La guía de GitHub sobre atestaciones de artefactos explica cómo una atestación verificada vincula un artefacto con su código y sus instrucciones de compilación. También aclara que no garantiza su seguridad. Te corresponde decidir si el proveedor, el proceso de compilación y el comportamiento del software cumplen tus requisitos.
Vincula la verificación al objeto que vas a arrancar. Si el lanzador vuelve a resolver una referencia variable después de la revisión, la comparación anterior ya no describe esa descarga. Recomendamos preparar los artefactos revisados bajo control del sistema e impedir su sustitución antes del arranque. El laboratorio sin conexión no prueba ese control.
¿Cómo haces cumplir la revisión fuera de las instrucciones del agente?
Aplica controles de descarga, modificación de archivos y ejecución que no dependan de las instrucciones del candidato. El descubrimiento debe producir una propuesta; una decisión protegida debe determinar qué componentes y permisos se habilitan. Mantén el verificador y el registro fuera del alcance de escritura del candidato, y prueba los rechazos en el sistema real.
Escribir «instala solo herramientas revisadas» en un archivo de instrucciones explica tu política. Para hacerla cumplir, el cliente o el entorno debe detener las acciones que la infrinjan. La documentación de permisos de Claude Code distingue expresamente las reglas que impone el cliente de los prompts y CLAUDE.md, que orientan al modelo sin cambiar los accesos concedidos.
Presta atención al campo allowed-tools de las skills de Claude Code. Preautoriza las herramientas enumeradas durante el turno que invoca la skill. No las convierte en las únicas disponibles: los permisos habituales siguen rigiendo las demás. Interpretarlo como una lista que excluye todas las herramientas restantes basaría tu revisión en un control que ese campo no ofrece.
Comprueba también qué procesos quedan aislados. La documentación del sandbox de Bash de Claude Code cubre comandos de shell y sus procesos hijos, pero señala que los hooks, servidores MCP locales y otros procesos auxiliares quedan fuera. Aislar el proceso completo requiere otra decisión de despliegue. Nuestra revisión de los mods y function hooks de Claude desarrolla esas capacidades de extensión.
En Codex, la política de aprobación y el modo de sandbox se configuran por separado. Suprimir las solicitudes de aprobación no desactiva por sí solo un sandbox activo; aprobar una acción tampoco demuestra que el artefacto sea seguro. Revisa la configuración efectiva del entorno que ejecutará la herramienta.
La referencia de configuración MCP de Codex también separa los filtros de herramientas y sus aprobaciones del comando, los argumentos, el entorno y el directorio de trabajo de un servidor local. Limitar los nombres de herramientas MCP invocables no evalúa ni aísla el arranque del servidor. Aprueba ese proceso antes de decidir qué métodos podrá llamar el agente.
La guía de seguridad MCP para configurar servidores locales con un clic exige mostrar el comando y los argumentos exactos y obtener consentimiento explícito. También recomienda aislamiento con privilegios mínimos. Son requisitos para los clientes que lo implementan, no pruebas de que cualquier vía de instalación ya los cumpla.
Estos límites proceden de la documentación; nuestro laboratorio Python no ha probado esas funciones de los proveedores. Utiliza la lista de comprobación de seguridad del sandbox de agentes para revisar por separado la contención durante la ejecución. Comparar archivos antes de instalar no sustituye esa evaluación.
¿Qué pruebas debe conservar tu equipo antes de habilitar la herramienta?
Conserva una decisión de instalación que identifique los componentes, el alcance de ejecución, el revisor y las condiciones para repetir la revisión. Adjunta las comparaciones y las pruebas de rechazo del sistema. Otro ingeniero debe poder justificar por qué la versión instalada está cubierta sin depender de lo que el agente diga haber aprobado.
Puedes empezar con un registro breve. Los siguientes campos describen pruebas que debes aportar; no son una configuración de producción ni valores generados por el laboratorio:
decision: reviewed-for-local-test
source: <owner/repository and full commit>
artifact: <reviewed relative path or final URL>
archive_sha256: <digest of reviewed archive bytes>
installed_inventory: <protected file-manifest reference>
launch: <exact command, arguments and working directory>
scope: <filesystem, network and credential policy>
reviewer: <responsible person and review date>
recheck_on: [source, artifact, installed-files, launch, scope]Después, comprueba la decisión en el entorno donde se instalará el software. Recomendamos estas pruebas de aceptación. Son comprobaciones propuestas para el despliegue, distintas de los resultados observados sin conexión.
| Comprobación propuesta | Evidencia que debes conservar |
|---|---|
| La versión revisada puede realizar la tarea prevista. | Un resultado satisfactorio utilizando únicamente los accesos acordados. |
| Un elemento modificado llega al control de instalación. | El sistema impide reutilizar la decisión anterior antes del arranque e identifica el campo modificado. |
| El candidato intenta sustituir el registro de referencia. | Un bloqueo de escritura impuesto de forma independiente, con el registro intacto. |
| El lanzador solicita un destino, una credencial o una ruta nuevos. | Un rechazo o una autorización separada, junto con la política efectiva que produjo esa decisión. |
| Los archivos cambian después de verificarlos y antes de ejecutarlos. | Pruebas de que el objeto preparado no puede sustituirse o de que otra comparación detiene el arranque. |
Asigna un responsable a cada fallo. Una diferencia de bytes puede requerir que un ingeniero examine el nuevo empaquetado. Una credencial adicional puede exigir que el responsable del sistema decida si acepta ese uso. Ninguno de los dos casos debería resolverse con un botón genérico de «continuar».
Si tu equipo necesita incorporar estos controles a su flujo de desarrollo, nuestro servicio de DevSecOps cubre repositorios, compilaciones y entregas. El criterio de aceptación sigue siendo concreto: habilita la instalación revisada dentro del alcance acordado y exige una nueva decisión cuando cambie cualquiera de los dos.