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

A developer on Habr published a practical security guide in July 2026 for open-source skills for AI tools — and explained why a malicious skill is more dangerous than standard prompt-injection: it runs with user privileges without any isolation.

Why a skill is not just a prompt?

A common misconception: a skill for Claude Code or a similar AI tool is a text config, safe by definition. Opened SKILL.md, read the instructions — and confident that everything is under control.

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

• Python or Bash scripts executed through `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 expanded access rights

All of this runs with the rights of the current user — without sandbox isolation by default. A malicious skill gains access to files, API tokens, SSH keys, and chat history: not to something abstract, but to what lies on the disk right now.

This is exactly what makes the attack vector through a skill fundamentally different from, for example, a browser vulnerability: the skill doesn't bypass protection, it uses the provided permissions. From the system's perspective — these are completely legitimate actions.

How an attacker uses a skill as an attack vector

Classic prompt-injection: malicious instructions are hidden in data processed by the model — in web page text, a document, an email. An agent "reads" the content and executes hidden commands. In the case of skills containing executable code, the attack is arranged differently and harder to detect.

A typical attack chain through an OSS skill:

• The attacker publishes a skill with genuinely useful functionality — an editor, converter, search tool
• The first commits are clean, the skill gains stars and gets installed by users
• After several updates, malicious logic is added — collection of `.env` files, API tokens, chat history
• The user updates the skill without checking the diff — data goes to an external server

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

This can literally be executable code with your rights"

Unlike a vulnerability in an npm package that `npm audit` catches, a malicious skill leaves no CVE record — nobody scans it automatically.

What to check before installing a skill

Minimum checklist before adding someone else's skill:

• Read all the code, not just SKILL.md — Python, Bash, PowerShell in the skill directory require manual review
• Look for external requests — `curl`, `fetch`, `requests.get` to unfamiliar URLs without explicit necessity — a red flag
• Check access to sensitive paths — `~/.ssh/`, `~/.env`, `.credentials` without explicit user permission is unacceptable
• Study commit history — malicious code often appears several weeks after a clean release
• Look for obfuscation — base64 strings, dynamic `eval()`, non-standard variable names
• Audit dependencies — malicious logic can be in a helper library, not in SKILL.md itself

Unknown skills should be tested in an isolated environment: a separate profile without real API keys, without access to production files. The optimal option is a dedicated test account without production tokens.

What this means

The OSS ecosystem of skills for AI assistants repeats the path of npm from a decade ago: rapid growth, weak centralized verification, the habit of installing without audit. The difference is fundamental: a skill runs not in an isolated Node environment, but directly in the user's working environment with their rights. Auditing skills before installation is not paranoia, but the same security hygiene as `npm audit` before deploy.