Why this format is different
A classic web XSS needs a page to execute someone else’s script. A Claude skill already has permission to fetch, write, and shell when the installer grants those tools.
So the interesting attack is not “break out of the sandbox.” It is “put instructions in an issue, PR, or page the skill was told to read, then let the skill act on them.” That is prompt injection aimed at the agent’s tool loop.
The pattern to reject on sight
Read or fetch untrusted content (a URL the user pastes, a GitHub issue body, a comment thread, a webhook payload).
Then run Bash, Write, Edit, git push, or send a network payload based on that text.
AuditHQ’s Claude plugin security scan flags that combination as a prompt-injection surface on published skills — without running the plugin.
What a safer skill looks like
Separate “summarize this issue” from “apply a patch.” Require an explicit human confirm before Write or Bash.
Prefer constrained tools (read-only) when the input is remote. Do not let issue text decide which files to edit.
Document the trust boundary in the skill: what is treated as data, and what never becomes an instruction.
Run the check on AuditHQ
Create a Claude plugin project, run a security scan, and open findings for prompt-injection and related packaging rules.
Copy the section AI fix prompt for Security when you want an agent to rewrite the skill without inventing new tool grants.