Para saber si un plugin de Claude Code es seguro, revisa lo que va a ejecutar antes de instalarlo: sus hooks, sus mods, sus servidores MCP y su carpeta bin/, porque todo eso corre en tu máquina con tus permisos de usuario. ModVet, un escáner de seguridad open source publicado en PyPI esta semana, automatiza la primera pasada de esa revisión: funciona offline, sin LLM, y reporta cada línea sospechosa con su código del OWASP MCP Top 10. Lo probamos junto al validador que ya trae Claude Code, sobre plugins y mods oficiales de Anthropic. Detecta bien las primitivas de ataque clásicas, hace ruido con código legítimo y no puede decirte qué intención tiene un fragmento de código.
yoDEV Tested · 20 de octubre de 2026 Ejecutamos ModVet 0.2.2 y
claude plugin validate(Claude Code 2.1.304) en Linux con Python 3.13 sobre 13 plugins y 4 mods oficiales de Anthropic, los fixtures del propio ModVet y el repositoriodsh-our-free-model. Los resultados que reportamos como nuestros salen de esa prueba.
Cómo lo probamos. Escaneamos los fixtures de prueba limpio y malicioso que vienen en el repositorio de ModVet; los 13 plugins de plugins/ y los cuatro mods integrados de mods/ del repositorio anthropics/claude-code, en el commit a6e289a (19 de octubre de 2026); y el repositorio dsh-our-free-model en el commit 49171b9, que ya habíamos revisado a mano. Ninguna de las dos herramientas ejecuta lo que analiza, y nosotros tampoco: no instalamos nada de lo escaneado ni escribimos código malicioso para la prueba. El fixture malicioso es del autor y es inerte: su URL de descarga usa el dominio reservado evil.example y su payload en base64 se decodifica como echo "bad".
¿Por qué hay que revisar un plugin de Claude Code antes de instalarlo?
Porque la propia documentación de Anthropic dice que un plugin que instalas puede ejecutar código arbitrario en tu máquina con tus privilegios de usuario. Un plugin puede traer:
- Hooks: comandos de shell que se ejecutan en distintos momentos del ciclo de vida de Claude Code, por ejemplo antes o después de una llamada a una herramienta.
- Monitores: comandos de shell en segundo plano que Claude Code inicia por su cuenta.
- Mods: código JavaScript que se ejecuta dentro de Claude Code con tus permisos.
- Servidores MCP y LSP: un servidor MCP stdio corre como un proceso que Claude Code inicia en tu máquina.
- Una carpeta
bin/: se agrega alPATHde la shell de la herramienta Bash. - Skills, comandos y agentes: entran al contexto de Claude como instrucciones.
Lo más importante es lo que no queda cubierto. Las reglas de permisos y el sandbox de Claude Code se aplican a las llamadas a herramientas que hace Claude, no al código que el plugin ejecuta por su cuenta: los hooks, los monitores, los servidores MCP y LSP y los procesos que inicia un mod corren fuera del sandbox. Y si la actualización automática está activada para el marketplace, los archivos que revisaste pueden cambiar en disco después de la instalación.
¿Qué es un mod de Claude Code?
Un mod es un plugin que cambia la apariencia y el comportamiento de Claude Code mediante controladores de eventos escritos en JavaScript o TypeScript. Claude Code los llama cuando ocurre un evento, como una llamada a herramienta, un prompt enviado o una parte de la interfaz que se está dibujando, y el controlador puede observar el evento, modificarlo o responderlo por sí mismo. Los mods requieren Claude Code v2.1.287 o posterior y vienen activados por defecto; algunas funciones del propio Claude Code, como /diff, son mods.
Por eso son el componente que más conviene revisar. Según la documentación, una vez cargado un mod puede leer y escribir archivos donde pueda hacerlo tu usuario, leer tus variables de entorno y API keys, ver cada prompt y cada llamada a herramienta, reescribirlos, aprobar una llamada a herramienta antes de que se te pregunte y llamar a un modelo con tu plan. No se ejecuta en un sandbox.
Ese es exactamente el terreno de ModVet, cuyo README se presenta como la forma de revisar tus mods de Claude Code antes de instalarlos. Varios de sus detectores apuntan a lo que solo un mod puede hacer, como reescribir el prompt antes de enviarlo o los argumentos de una llamada a herramienta.
¿Cómo revisar un plugin de Claude Code sin instalarlo?
Claude Code ya incluye un camino de revisión manual, y vale la pena recorrerlo antes de recurrir a cualquier herramienta de terceros:
- Ejecuta
claude plugin marketplace listen tu shell para ver de dónde viene cada marketplace. - En una sesión, ejecuta
/pluginy selecciona el plugin. El panel de detalles muestra, en Will install, sus comandos, agentes, skills, hooks y servidores MCP y LSP. - El panel indica que existe un hook, pero no qué ejecuta. Para eso, lee
hooks/hooks.json,.mcp.jsony cada archivo debin/. - Con el repositorio clonado,
claude --plugin-dir <directorio del plugin> plugin details <nombre del plugin>imprime unComponent inventorysin iniciar una sesión. - Si el plugin trae un mod,
claude plugin validate <directorio del plugin>lista, sin ejecutarlo, qué eventos maneja y qué le pide hacer a Claude Code.
El paso 5 es el más revelador. En el mod integrado diff, la salida incluye estas líneas (recortadas):
> ./register.ts hooks: session.start, ui.render{component=PromptHint}, ui.render{component=Pane}, command.run{command=diff}, ... tool.call{tool=?|?}, prompt.submit
> ./register.ts calls: $.clock.after, ... $.env.get, $.fs.list, $.fs.read, $.fs.stat, $.process.run, $.session.id, $.session.messages, ...
> ./register.ts env writes: nothing
> ./register.ts env reads: CLAUDE_CODE_DISABLE_FILE_CHECKPOINTING
Un mod solo puede leer archivos, iniciar procesos o hacer solicitudes de red a través de la API de mods, y por eso Claude Code puede listar esas llamadas antes de que lo instales. Si un mod que dice dibujar un panel aparece llamando a $.process.run y leyendo variables de entorno, ya sabes qué preguntar.
Solo los marketplaces que vienen de github.com/anthropics/ pueden usar los nombres oficiales o de comunidad, así que un catálogo de terceros no puede hacerse pasar por uno de Anthropic. Pero el nombre de un marketplace te dice quién publica el catálogo, no qué hace cada plugin.
¿Qué es ModVet?
ModVet es un escáner de seguridad determinista para revisar mods y plugins de Claude Code antes de instalarlos. Está escrito en Python por Jörg Michno, tiene licencia Apache-2.0, no tiene dependencias y su motor viene de un proyecto anterior del mismo autor, ClawGuard. Recorre el directorio de un plugin y busca tres tipos de problema:
- Prompt injection e instrucciones que intentan anular las del agente: unos 400 patrones en inglés y alemán, con normalización de homoglifos, leetspeak, base64, caracteres de ancho cero y texto invertido.
- Capacidades peligrosas en combinación: un
fetcho una lectura deprocess.envpor sí solos son trabajo normal de un plugin, así que solo reporta combinaciones en la misma expresión, como leer variables de entorno y además enviar un POST. También marca directamente primitivas de ataque: descargas encadenadas a una shell, base64 decodificado hacia una shell, reverse shells, hooks que elevan permisos, reescritura de configuración, archivos.envincluidos en el repositorio y scripts de ciclo de vida de npm. - Secretos hardcodeados: patrones de API keys y tokens.
Cada hallazgo lleva una referencia del OWASP MCP Top 10 (de MCP01 a MCP10) en el campo owasp_mcp del reporte JSON. La salida puede ser legible, JSON o SARIF 2.1.0 para GitHub Code Scanning, y los códigos de salida permiten usarlo en CI.
Sin cuenta, sin red y sin LLM. Es la decisión de diseño que tiene sentido aquí: lo que escaneas no es de confianza, y pedirle a un modelo que lo juzgue le da al plugin la oportunidad de hablarle al juez.
¿Cómo se instala y se usa ModVet?
Se instala desde PyPI (requiere Python 3.9 o superior):
pip install modvet
Para escanear el directorio de un plugin:
modvet scan ./mi-plugin # reporte legible
modvet scan ./mi-plugin --json # reporte para máquinas
modvet scan ./mi-plugin --format sarif # para GitHub Code Scanning
modvet scan ./mi-plugin --fail-on CRITICAL # fallar solo con hallazgos CRITICAL
Códigos de salida: 0 limpio, 1 hallazgos iguales o superiores a --fail-on (por defecto HIGH), 2 error de uso.
Para escanear un plugin que ya instalaste, apúntalo a la copia instalada, que Claude Code guarda en ~/.claude/plugins/cache/<marketplace>/<plugin>/<versión>/.
Para las actualizaciones, ModVet tiene dos comandos más: modvet snapshot ./mi-plugin registra una línea base después de una instalación limpia, y modvet diff ./mi-plugin --against .modvet-snapshot.json vuelve a auditar solo lo que cambió. Como la actualización automática puede cambiar archivos después de que los revisaste, es la idea más útil de la herramienta. El autor lo resume en una frase: “the update is the attack”.
¿Qué detecta ModVet? Prompt injection, secretos y comandos peligrosos
En el fixture malicioso del autor, todo lo que esperábamos. El fixture limpio devuelve 0 hallazgos y código de salida 0. El malicioso devuelve 9 hallazgos, un puntaje de riesgo de 10/10 y código de salida 1:
| Hallazgo | Severidad | OWASP MCP |
|---|---|---|
Ignore previous instructions en un system prompt |
CRITICAL | MCP01 |
Clave sk-… hardcodeada |
CRITICAL | MCP03 |
| Lectura de variables de entorno + HTTP POST (ruta de exfiltración) | HIGH | MCP03 |
curl … | sh |
CRITICAL | MCP05 |
base64 -d | sh |
CRITICAL | MCP03 |
mcpServers declarado en .mcp.json |
MEDIUM | MCP08 |
Para cada uno, el reporte muestra el texto detectado, la línea y una acción recomendada. En un plugin construido para activar las reglas, las activa todas.
Un matiz: ese fixture es sintético y no sigue el formato documentado de un mod de Claude Code. claude plugin validate lo rechaza porque no tiene .claude-plugin/plugin.json. Eso no le resta valor a los detectores, que buscan patrones en cualquier archivo, pero significa que la demostración del autor no dice nada sobre cómo se comporta ModVet con mods reales. Para eso hicimos la siguiente prueba.
¿ModVet marca como peligrosos los plugins y mods oficiales de Claude Code?
Sí, a una parte. De los 13 plugins oficiales, nueve salieron limpios, entre ellos code-review, feature-dev y pr-review-toolkit. De los cuatro mods integrados, dos salieron limpios: agents-md y telemetry. Estos fallan con el umbral por defecto:
| Plugin o mod | Hallazgos | Máxima severidad |
|---|---|---|
hookify (plugin) |
5 | HIGH |
ralph-wiggum (plugin) |
4 | HIGH |
plugin-dev (plugin) |
11 | CRITICAL |
security-guidance (plugin) |
83 | CRITICAL |
diff (mod integrado) |
4 | HIGH |
sec-default (mod integrado) |
5 | CRITICAL |
Los hallazgos HIGH y CRITICAL que revisamos eran falsos positivos:
- En
plugin-devyralph-wiggum, líneas de shell comoecho "$SYSTEM_PROMPT"se interpretan como “instruction replay”, y un encabezado Markdown**Critical rules:**activa una regla de “instruction header injection”. - En los mods
diffysec-default, todas las alertas salen de comentarios de código y de archivos de prueba: una frase sobre una regla de git, la descripción de una herramienta mencionada en un comentario, un fixture de pruebas. security-guidancees el caso extremo: documenta patrones peligrosos (eval(),verify=False,!!python/object) para advertir sobre ellos, y el escáner no distingue entre la documentación de un riesgo y el riesgo mismo.
Es el costo de la detección por patrones deterministas, y conviene saberlo antes de poner ModVet en CI: con el --fail-on HIGH por defecto, habría bloqueado cuatro plugins y dos mods de Anthropic. El autor reporta que los falsos positivos en 12 repositorios bajaron de 1.815 a menos de 300 entre el motor v0.1 y el actual. Es su propio benchmark, sobre repositorios que él eligió, y es coherente con lo que vimos: hace ruido, pero ya no es inutilizable.
¿ModVet o claude plugin validate?
Los dos, porque responden preguntas distintas. claude plugin validate es un inventario de capacidades: te dice qué eventos maneja un mod y qué le pedirá a Claude Code, como leer archivos, iniciar procesos o leer variables de entorno, y no te da una opinión sobre si eso es malicioso. ModVet es un detector de patrones: busca en el texto formas de ataque conocidas, como curl | sh o una instrucción para ignorar el system prompt, pero no hace un inventario de las llamadas a la API de mods.
En nuestra prueba se complementaron bien. El validador mostró que el mod diff llama a $.process.run y lee variables de entorno, algo que tiene sentido para un panel que muestra cambios de git y que ModVet no mencionó. ModVet, a su vez, juzga lo que el validador no pretende juzgar: si hay secretos hardcodeados, comandos de shell peligrosos o texto de prompt injection en cualquier archivo del plugin.
¿Qué no puede ver un escáner de seguridad como ModVet?
La intención. A principios de esta semana leímos a mano el código de dsh-our-free-model, un plugin para DeepSeek Harness, y encontramos que su index.js importa un “channel pack” empaquetado en cada arranque, sin ningún ajuste para desactivarlo. Esa importación fue el hallazgo central de nuestra revisión.
ModVet no la marca. En ese mismo index.js reporta tres hallazgos, dos de ellos CRITICAL de tipo “Secret Assignment” sobre plantillas de texto en ejemplos de código (api_key="${shownKey}"), que son falsos positivos. La importación importante es una línea de JavaScript completamente normal. Una aclaración justa: ese plugin no es de Claude Code, así que queda fuera del alcance declarado de ModVet. Pero la limitación es general. Un escáner por patrones reconoce formas de ataque conocidas; no puede decirte que una importación de apariencia legítima carga 2,9 MB de código que opera pools de cuentas contra otros proveedores.
También aparecieron dos límites prácticos:
- La velocidad depende del tamaño. El “en milisegundos” del README no se cumplió en nuestra máquina.
code-reviewtardó unos 0,6 segundos incluyendo el arranque de Python, los mods integrados entre 3 y 26 segundos, ysecurity-guidanceunos 11 segundos. Un solo archivo JavaScript de 500 KB tardó 15 segundos, y el repositorio completo dedsh-our-free-model, de 25 MB, no había terminado tras 10 minutos, así que lo detuvimos. - Parte de la salida está en alemán. Las líneas “Context” y “Action” de muchos hallazgos, y la mitad del README, están en alemán. La severidad, el nombre del patrón y el código OWASP se entienden en cualquier idioma, pero puede que necesites un traductor para la explicación.
¿ModVet o Snyk?
Según la tabla comparativa del propio README de ModVet, la diferencia es de modelo: Snyk escanea servidores MCP y skills dentro de una plataforma DevSecOps más amplia, con cuenta en la nube y precios SaaS, mientras que ModVet corre local y offline, sin cuenta, y cada regla es visible en el código abierto. ModVet suma snapshot y diff para auditar solo los cambios de cada actualización. No probamos Snyk para esta nota, así que tómalo como la comparación del autor, no como la nuestra.
¿ModVet escanea skills y servidores MCP?
Todavía no de forma específica, al 20 de octubre de 2026. La versión 0.2.2 escanea directorios de mods y plugins; sus patrones de prompt injection leen cualquier archivo de texto, pero el README presenta el escaneo dedicado de SKILL.md y de servidores MCP como el próximo paso, y menciona una posible oferta Pro o de auditoría “después de la tracción”, sin más detalles. El proyecto tiene días: subió tres versiones a PyPI el 19 de octubre, no tiene releases en GitHub y no hay documentación más allá del README y la carpeta specs/. Si lo que necesitas revisar son skills, SkillSpector de NVIDIA ataca ese problema: SkillSpector: NVIDIA Quiere Escanear tus Skills Antes de que los Instales.
Entonces, ¿cómo decides si un plugin de Claude Code es seguro?
Usa ModVet como primer filtro, no como veredicto:
- Revisa de dónde viene con
claude plugin marketplace listy el panel de detalles de/plugin. - Si trae un mod, ejecuta
claude plugin validatey compara las llamadas que lista con lo que el plugin dice hacer. - Ejecuta
modvet scansobre el plugin clonado. Un resultado limpio significa que no encontró ninguna de las primitivas de ataque conocidas. Un CRITICAL porcurl | sh,base64 -d | sho lectura de entorno más POST merece una revisión detenida. - Lee cada hallazgo en su contexto. Muchos serán comentarios, documentación, ejemplos o archivos de prueba.
- Lee tú mismo los hooks,
.mcp.json,bin/y el código del mod de todos modos. Ahí es donde ninguna de las dos herramientas puede juzgar la intención. - Toma un snapshot después de instalar con
modvet snapshoty ejecutamodvet diffdespués de cada actualización, o desactiva la actualización automática para ese marketplace.
En CI, considera usar --fail-on CRITICAL en lugar del valor por defecto, para que un plugin que documenta riesgos no bloquee tu pipeline.
¿Y tú? ¿Qué es lo primero que revisas antes de instalar un plugin de Claude Code?
- Lo instalo si el marketplace parece confiable
- Leo los hooks, los scripts y el código del mod
- Lo paso por un validador o un escáner
- Hago otra cosa (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: ¿Es seguro dsh-our-free-model? Lo que encontramos al leer el código del plugin “gratis” para DeepSeek Harness