Trust Assessment
frame-builder received a trust score of 65/100, placing it in the Caution category. This skill has some security considerations that users should review before deployment.
SkillShield's automated analysis identified 4 findings: 1 critical, 2 high, 1 medium, and 0 low severity. Key findings include Untrusted content attempts to instruct host LLM, Potential command injection through user-defined arguments, Automatic `npm install` without dependency pinning.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 33/100, indicating areas for improvement.
Last analyzed on February 13, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings4
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| CRITICAL | Untrusted content attempts to instruct host LLM The `SKILL.md` document, which is explicitly marked as untrusted input, contains extensive instructions for the host LLM within the 'OpenClaw Heartbeat Integration' and 'Auto-Update' sections. These instructions dictate specific actions, shell commands to execute (`node`, `git`, `npm`), and logical conditions for the LLM to follow. This directly attempts to manipulate the LLM's behavior using untrusted data, which is a critical prompt injection vulnerability. The LLM is being instructed to run shell commands like `git pull origin main` and `npm install` based on this untrusted input, violating the rule to treat all content within untrusted delimiters as data, not instructions. The host LLM should never interpret content within untrusted delimiters as instructions. Skill definitions and operational logic for the LLM should be defined in trusted configuration files or code, not within user-provided markdown. If the skill needs to define agent behavior, it should do so through a structured, trusted manifest or API, not by embedding instructions in untrusted documentation. | LLM | SKILL.md:108 | |
| HIGH | Automatic `npm install` without dependency pinning The skill's auto-update mechanism includes `npm install` within the `src` directory. If the `package.json` or `package-lock.json` files are not strictly pinned to specific versions (e.g., using exact versions instead of ranges like `^1.0.0`), or if a dependency itself is compromised, this automatic update process could introduce malicious code. Without inspecting the `package.json` file, it's a significant risk that `npm install` could fetch compromised or vulnerable dependencies. Ensure all dependencies in `package.json` are strictly pinned to exact versions. Use `npm ci` instead of `npm install` if a `package-lock.json` is present and trusted, as `npm ci` guarantees exact reproducibility. Regularly audit dependencies for known vulnerabilities. | LLM | SKILL.md:124 | |
| HIGH | Skill manages and accesses sensitive private keys The skill explicitly states it creates and uses `~/.evm-wallet.json`, which contains the user's private key. While it advises `chmod 600`, the fact that the skill's scripts (`setup.js`, `balance.js`, `claims.js`, `heartbeat.js`) directly interact with this highly sensitive file means any vulnerability in these scripts (e.g., a bug, a malicious dependency, or a command injection) could lead to the exfiltration of the private key. This represents a critical target for attackers, posing both data exfiltration and credential harvesting risks. Implement robust security practices for handling private keys. Consider using hardware security modules (HSMs) or secure enclaves if available. If not, ensure the scripts handling the private key are minimal, thoroughly audited, and operate in a highly isolated environment. Access to the private key file should be strictly controlled and logged. Avoid passing the private key directly as a command-line argument or environment variable if possible. | LLM | SKILL.md:37 | |
| MEDIUM | Potential command injection through user-defined arguments The skill's quick start guide suggests setting `TOKEN_IMAGE` and then running `node {baseDir}/src/upload.js --image "$TOKEN_IMAGE"`. Similarly, `node {baseDir}/src/claims.js vesting --token=0x...` takes a user-provided token address. If the `upload.js` or `claims.js` scripts do not properly sanitize or escape these user-provided arguments before using them in a shell context (e.g., if they pass them to another shell command without proper quoting), a malicious user could inject arbitrary commands. While the examples show benign inputs, the mechanism allows for user-controlled input to be passed to a shell command. The `upload.js` and `claims.js` scripts must rigorously sanitize and escape all user-provided arguments before using them in any shell command or subprocess call. Ideally, arguments should be passed as distinct parameters to subprocesses rather than concatenated into a single shell string. | LLM | SKILL.md:48 |
Scan History
Embed Code
[](https://skillshield.io/report/4b9e76558a0d632d)
Powered by SkillShield