T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:5- Finding
Excessive Tool Permissions for a Markdown-Only Skill
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 5 and 18–21; supporting contradictory statements at lines 274 and 283
Vulnerability Type: Least-privilege violation through unnecessary command execution and filesystem permissions
Risk Level: MediumVulnerable Code
yaml allowed-tools: read execyaml tools: - exec - read - writeThe skill later states that it is a pure Markdown skill whose core functionality does not require command execution. Its error-handling guidance nevertheless recommends executing
pingfor network diagnostics.Technical Analysis
The skill provides creative consultation, brainstorming, proposal evaluation, and creative-brief generation using the agent's built-in language model. These text-generation functions do not legitimately require shell execution or filesystem read/write access.
Despite that limited purpose, the metadata requests:
exec, which can run local operating-system commands.read, which can access files available to the agent.write, which can modify files available to the agent.
The declarations are internally inconsistent because
writeappears undertoolsbut not underallowed-tools. Depending on how the host platform interprets these fields, it may grant the broader set, reject the skill, or produce unpredictable authorization behavior.This finding is a capability exposure rather than evidence of active malicious use. The reviewed skill contains no instruction that directly reads sensitive files, modifies local data, or executes a malicious command. Nevertheless, granting these capabilities creates an avoidable security boundary violation: later untrusted input, prompt injection, or future changes to the skill could use permissions that its advertised functionality does not need.
Attack Path
- A user or administrator installs or loads the skill.
- The host interprets the metadata and grants
exec,read, and potentiallywrite. - The ...[truncated 1270 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove
exec,read, andwritebecause the documented core workflow is fully language-model based. - Use one authoritative tool declaration rather than conflicting
allowed-toolsandtoolsfields. - If the platform requires explicit metadata, declare an empty tool set using the platform's supported syntax.
- Remove the recommendation to execute
ping; replace it with non-executable guidance to verify platform or model availability. - If a future feature genuinely requires a tool, grant only that tool for the shortest possible scope and require explicit user approval for sensitive operations.
- Enforce host-side sandboxing, filesystem allowlists, command allowlists, and per-call authorization rather than relying only on skill metadata.
- Add validation that rejects inconsistent capability declarations during packaging or installation.
A hardened configuration should conceptually contain no tool permissions:
yaml allowed-tools: [] tools: []The exact empty-list syntax should follow the host platform's schema.
- Remove