The Skills you installed for Claude Code might be stealing your keys

You are writing code with Claude Code or Cursor, and you easily install a Skill that looks very practical.

Its SKILL.md is written in an orderly manner with no suspicious commands. You have also scanned the accompanying script and it is a normal tool code. Both sides have passed your check, so you let it go.

The problem is: it is indeed malicious.

The malicious logic is neither in that markdown nor in that script — it is hidden in the coordination between the two. The markdown is responsible for inducing the Agent to prepare a certain intermediate file, and the script then consumes it to complete the final step. If you look at them separately, each half is harmless.

This is not a hypothesis. A newly published academic paper has systematically brought this matter to the table for the first time.

Academia first established a ruler for "malicious Skills"

This paper is called "MalSkillBench" and was jointly released by Nanyang Technological University, Sichuan University, Nankai University, and other institutions.

The research team dismantled the malicious Skill into three orthogonal dimensions — where the malicious logic comes in, what it ultimately wants to do, and how the payload is embedded — summarizing 3 types of attack vectors, 15 types of malicious behavior, and 108 effective attack units, finally constructing a dataset containing 3,944 malicious samples and 4,000 benign samples.

Most notable is the third of the three attack vectors it defines.

The first type is Code Injection (CI): malicious logic is directly written in the code block of the script or markdown, which is closest to traditional malicious packages, where credential theft, remote execution, and reverse Shell are all in this category.

The second type is Prompt Injection (PI): malicious logic is hidden in the natural language instructions of SKILL.md, not necessarily with code, but to let the Agent perform dangerous actions on its own, and even change the Agent's identity and security boundary.

The third type is Mixed Attack (MIXED): the attack chain is split into two halves, with the markdown responsible for inducing the Agent to generate or download a certain intermediate object, and the script then consuming this object to complete the attack. The paper is very direct — this kind of attack only manifests when the Agent follows the markdown instructions and executes the coordination script at the same time.

In other words, its maliciousness is not in any single file, but in the relationship between the files.

Why your existing check methods are bypassed by it

Think about how you audit a third-party package, extension, or Skill: scanning code characteristics, comparing with known malicious patterns, and seeing if there are hard-coded credentials, suspicious domains, or dangerous system calls. Behind this are SAST, SCA, and virus database matching — all of which are static analysis.

Static analysis has an implicit premise that maliciousness is a feature that can be singled out in a piece of code. In the era of traditional malicious packages, this premise held true.

MIXED attacks specifically defeat it. The maliciousness is split into two inherently legitimate parts, and scanners cannot report problems no matter which half they scan. It's not that you didn't scan, but that you scanned and couldn't see it.

This is why the paper repeatedly emphasizes "runtime-verified" — only by letting the Skill actually run once in the Agent environment and seeing what behavior it actually triggers can it be determined whether it is malicious. Looking at static files does not give the answer.

And this happens to be the blind spot of most enterprises at present: developers casually pull Skills in AI programming tools every day, but the entry barrier either does not exist or still stops at the old logic of "scanning the code once".

Interception must happen "at the moment of entry", not scanning after installation

Even if you have the ability to identify malicious Skills, the timing of identification is also key.

Private artifact repositories and regular SCA scans can indeed find problems, but they find them too late. By the time the next round of scanning runs, the malicious package has already landed on the developer's workstation and entered the CI/CD pipeline. The intelligence is there, but the control has not kept up, leaving the intervening time wide open.

Another line of thought currently being adopted in the industry is to move the protection point directly to the supply chain entry: every pulled open-source component, third-party dependency, and AI toolkit must undergo intelligence verification before reaching the development environment. Hit known malicious files to block them on the spot, whitelist to release, and query unknown samples in real-time — malicious code is stuck "at the moment of entry" rather than checking what it did after entry.

The CyriGate, an intelligent gateway for software supply chain anti-poisoning developed by SecZone, is the implementation of this idea: deployed as an artifact repository proxy at the supply chain entry, setting developer workstations, CI/CD pipelines, and AI programming tools like Claude Code and Cursor as checkpoint gates, with a threat intelligence library covering traditional software packages and AI Skills in all categories.

But to clarify the boundary, the gateway blocks entry. For attacks like MIXED that are only exposed through runtime behavior, in addition to entry verification, the attack script must be run once in a real environment to verify whether the defense line can block it — this is the other loop that should be closed between supply chain intelligence and execution verification.

The first step is to prevent malicious Skills from entering the developer's machine without your knowledge.

Back to the scenario at the very beginning

You scanned the markdown, you scanned the script, both sides were clean, so you let it go.

This set of actions was fine three years ago. But when attackers learn to split maliciousness into the relationships between files, "checking each file separately" itself becomes an exploited vulnerability.

It's worth asking yourself: which era was your current method of auditing third-party Skills and extensions designed for? Is it from the last century?

How is the team you are in managing the package entry barrier for AI programming tools now? Leave a message to chat.

Reference source SecRSS, 2026-06-18 → https://www.secrss.com/articles/91472