Prompt injection via Claude Code skills: how to vet a plugin before installing it

In July 2026, a developer on Habr published a practical guide to the security of open-source skills for AI tools. The guide explains why a malicious skill is more dangerous than standard prompt injection: it runs with the user's privileges and without any isolation.

Why is a skill more than just a prompt?

A popular misconception holds that a skill for Claude Code or a similar AI tool is a text config and therefore safe by definition. You open SKILL.md, read the instructions and assume everything is under control.

In practice, the line between a "config" and "executable code" has long been blurred. Modern skills include:

• Python or Bash scripts executed via `tool_call`
• Instructions for working with the local file system and environment variables
• Calls to external APIs and webhook endpoints
• Multi-step agent pipelines with extended access rights

All of this runs with the current user's privileges, with no sandbox isolation by default. A malicious skill gets access to files, API tokens, SSH keys and chat history: not something abstract, but whatever is sitting on your disk right now.

This is what makes a skill-based attack vector fundamentally different from, say, a browser vulnerability: the skill does not bypass protection, it uses the permissions it has been given. From the system's point of view, these are fully legitimate actions.

How an attacker uses a skill as an attack vector

Classic prompt injection hides malicious instructions in data the model processes: the text of a web page, a document or an email. The agent "reads" the content and executes the hidden commands. With skills that contain executable code, the attack works differently and is harder to detect.

A typical attack chain through an open-source skill:

• The attacker publishes a skill with a genuinely useful function: an editor, a converter, a search tool
• The first commits are clean, and the skill collects stars and gains users
• After several updates, malicious logic appears, collecting `.env` files, API tokens and chat history
• The user updates the skill without checking the diff, and the data goes to an external server

"A skill is not a config and not just a prompt in SKILL.md.

It can literally be executable code with your privileges"

Unlike a vulnerability in an npm package, which `npm audit` catches, a malicious skill leaves no CVE record. Nobody scans skills automatically.

What to check before installing a skill

A minimal checklist before adding someone else's skill:

• Read all the code, not just SKILL.md: Python, Bash and PowerShell files in the skill directory need manual review
• Look for external requests: `curl`, `fetch` or `requests.get` to unfamiliar URLs without a clear need are a red flag
• Check access to sensitive paths: `~/.ssh/`, `~/.env` and `.credentials` are unacceptable without the user's explicit permission
• Study the commit history: malicious code often appears several weeks after a clean release
• Look for obfuscation: base64 strings, dynamic `eval()`, unusual variable names
• Audit dependencies: the malicious logic may sit in a helper library rather than in SKILL.md itself

Test unfamiliar skills in an isolated environment: a separate profile with no real API keys and no access to work files. The best option is a dedicated test account without production tokens.

What this means

The open-source skill ecosystem for AI assistants is repeating npm's path from a decade ago: rapid growth, weak centralized verification and a habit of installing without an audit. The difference is fundamental: a skill does not run in an isolated Node environment but directly in the user's working environment, with the user's privileges. Auditing skills before installation is not paranoia. It is the same security hygiene as running `npm audit` before deploying.