PhantomSkill: hiding a malicious payload as an ordinary-looking bug

What is this?

On June 17, 2026, Yu-Ting Lin and Chia-Mu Yu (National Yang Ming Chiao Tung University) published PhantomSkill: Malicious Code Injection in Agent Skill Ecosystems on arXiv. It describes a supply-chain attack against the agent-skill package format — the directories, each holding a SKILL.md file plus optional helper scripts and templates, that coding agents such as Claude Code, OpenAI Codex, Cursor, and Gemini CLI import to gain reusable capabilities.

Most published attacks on agent skills so far live in the text of the skill: a hidden instruction inside SKILL.md, or a helper script that is plainly malicious once you open it. Both are catchable, because modern agents and marketplace scanners increasingly inspect skill resources before running them. PhantomSkill targets the gap those defenses leave open: what happens when the malicious behavior is written to look like an ordinary, exploitable bug rather than like malware. This is published academic research on a class of weakness, not an operational how-to, and the authors frame it as a case for hardening skill review and containment.

How it works

The technique is called VulMask, and it rests on a single observation the authors make explicit: reviewers — human and automated — tend to be far more sensitive to obvious malware than to run-of-the-mill insecure code. VulMask converts the first into the second.

Kept deliberately abstract, the pipeline looks like this:

overt malicious script
        |
  pick CWE-style weakness classes (e.g. information exposure,
  command/code injection, unsafe dependency handling)
        |
  LLM rewrites payload  --->  "vulnerability-shaped" implementation
        |                      (looks like an ordinary exploitable bug)
        |
  embed into the ORIGINAL helper script, keeping its name, path,
  and benign input/output when no trigger is present
        |
  validate in a sandbox: host skill still works normally, and the
  side effect only fires under the attacker-controlled trigger
        |
  ship skill  --->  SKILL.md, name, description all unchanged

Two design choices make it slippery. First, the skill’s advertised surface is untouched — the name, the description, and the SKILL.md workflow are identical to a benign skill, so anything that only scans SKILL.md sees nothing. Second, the payload is dormant: absent the attacker’s trigger condition, the script produces its normal, benign output, so dynamic checks on ordinary inputs also pass. The malicious effect is present but expressed as a weakness that “happens” to be exploitable rather than as explicit malicious logic. The authors report that, across host skills, attack goals, coding agents, generation models, and automated reviewers, this rewriting keeps the skill functional while lowering both warning-level and malware-level detection compared with the original overt script. The full method and evaluation are in the paper; no working payload is reproduced here.

Why it matters

The uncomfortable point is that in an agent setting, “merely vulnerable” and “malicious” can collapse into the same thing. A helper script with a plain injection or information-exposure flaw is only dangerous if something feeds it hostile input. But that is exactly what a coding agent does: it supplies file paths, project context, credentials, and its own execution authority to the scripts a skill ships. A weakness a human developer would triage as low-priority becomes a reliable payload once an autonomous agent is the one holding the trigger.

This lands on an ecosystem that is already leaky. Snyk’s ToxicSkills study of public skill marketplaces found prompt-injection and other critical issues across a large fraction of skills, and OWASP has stood up an Agentic Skills Top 10 precisely because installable capabilities are a growing attack surface. PhantomSkill sharpens the threat: it shows that raising the bar on obvious malware does not close the door, because a determined author can restyle the same behavior as a bug. It generalizes the lesson from agent-skill supply-chain malware and SKILL.md registry poisoning: the danger is not only what the skill says, but what its shipped resources do when an agent runs them.

Defenses

Treat auxiliary resources as first-class, not as afterthoughts. The paper’s central finding is that scanning SKILL.md is not enough — the payload never touches it.

Review the whole package, at the resource level. Marketplaces and internal review gates should inspect scripts, dependency manifests, templates, and any generated artifacts, not just the skill’s description. Static analysis that flags injection sinks, unsafe deserialization, and unvetted dependency handling should run against every executable file a skill ships.

Do not downgrade exploitable bugs inside skills. The authors argue directly that in agent ecosystems a triggerable vulnerability can be functionally equivalent to a malicious payload. A code review that would rate a command-injection sink as “low, needs hostile input” is mispriced when the consumer is an autonomous agent that routinely supplies exactly that.

Contain execution, assume the script is hostile. The most robust control is runtime: least-privilege file access, network egress restrictions, and explicit approval for sensitive operations (shell, credential access, outbound connections). If a skill’s helper script cannot reach secrets or the network without a policy check, a dormant payload has far less to work with. This is the same posture that helps against shell-injection in coding agents and underpins skill-permission systems.

Assume detection is partial and log accordingly. Because the technique is built to slip past reviewers, keep execution telemetry — file, process, and network activity per skill invocation — so a trigger that fires in production can be caught and reconstructed after the fact rather than only at install time.

Status

Item	Detail
Disclosure	arXiv preprint 2606.19191, published June 17, 2026 (CC BY 4.0)
Class	Supply-chain code injection in agent skills via “vulnerability-shaped” payloads (VulMask)
Core idea	Rewrite an overt malicious script into ordinary-looking insecure code that only acts under an attacker-controlled trigger
Key property	Skill name, description, and SKILL.md are unchanged; benign behavior preserved when the trigger is absent
Reported impact	Lower warning- and malware-level detection than overt payloads while retaining attack success (per authors, incl. tests on a GPT-5.5-class agent)
Not covered	No public in-the-wild exploitation; this is a research framework, and success depends on the review/sandbox stack in place