Trust Assessment
muninn 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, 1 high, 1 medium, and 0 low severity. Key findings include Unsanitized user input passed to external `cxp` binary, Unsanitized `category` and `title` in `add_memory` leading to path traversal, Skill allows arbitrary `project_path` leading to broad filesystem access.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 48/100, indicating areas for improvement.
Last analyzed on February 14, 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 | Unsanitized `category` and `title` in `add_memory` leading to path traversal The `add_memory` tool accepts `title`, `content`, and `category` as user input. The `SKILL.md` claims input sanitization, but no sanitization is applied to these arguments before they are passed to `projectManager.addMemory`. It is highly probable that `category` is used to construct a subdirectory path (e.g., `path.join(muninnPath, MEMORIES_DIR, category)`) and `title` for the filename. An attacker could provide `category: "../../../etc"` or `title: "../../../etc/passwd"` to write arbitrary files to arbitrary locations on the filesystem, potentially overwriting critical system files or exfiltrating data by writing it to an accessible location. This is a direct violation of the stated security claim and a high-risk vulnerability. Sanitize `args.title` and `args.category` using a strict whitelist regex (e.g., allowing only alphanumeric characters, hyphens, and underscores) before using them to construct file paths. Ensure `path.normalize` or `path.resolve` is used correctly to prevent directory traversal, or better, validate that the resulting path is strictly within the intended `.muninn/memories` directory. | LLM | server/dist/tool_executor.js:102 | |
| HIGH | Unsanitized user input passed to external `cxp` binary The skill claims to sanitize all queries via a strict whitelist regex. However, user-provided `query` arguments for the `search_context` tool are passed directly to `projectManager.searchContext`, which then passes them to `CxpWrapper.query` or `CxpWrapper.search`. These methods use `child_process.execFile` to execute the `cxp` binary, passing the user `query` as a direct argument. While `execFile` prevents shell injection, the absence of sanitization in the Node.js layer means that if the `cxp` binary itself has vulnerabilities in parsing arbitrary arguments (e.g., interpreting specific characters as flags or commands), it could lead to argument injection or unexpected behavior. This directly contradicts the stated security measure in `SKILL.md`. Implement the promised input sanitization (using the specified whitelist regex or a more robust one) on `args.query` within `handleSearchContext` or `projectManager.searchContext` *before* passing it to the `cxp` binary. | LLM | server/dist/tool_executor.js:106 | |
| MEDIUM | Skill allows arbitrary `project_path` leading to broad filesystem access The skill's manifest declares permissions for `~/.muninn/` and `./.muninn/`. However, tools like `init_project`, `reindex_context`, and `enforce_rules` accept a `project_path` argument which is resolved using `path.resolve(projectPath)`. This allows an agent to specify *any* directory on the filesystem as the 'project root'. The skill then performs read/write operations, creates directories, and sets up file watchers (`chokidar.watch`) within this arbitrary `project_path`. This grants the skill broader filesystem access than implied by its manifest, allowing it to operate on sensitive directories outside the intended project or home scope if the Node.js process has the necessary permissions. While the tool's function requires filesystem interaction, the lack of scope restriction for `project_path` is an excessive permission. Restrict `project_path` to be within the current working directory or a predefined safe directory (e.g., `~/.muninn/projects/`). If arbitrary paths are truly necessary, implement robust validation to ensure the path is not a system-critical directory and clearly document the broad filesystem access in the manifest. | LLM | server/dist/tool_executor.js:86 | |
| INFO | Dependencies use caret ranges instead of exact pinning The `package.json` specifies dependencies using caret (`^`) ranges (e.g., `^1.25.3`). While this allows for non-breaking updates, it means that minor or patch versions of these dependencies could be installed without explicit review. For critical security applications, exact pinning of dependencies is often preferred to ensure deterministic builds and prevent the introduction of vulnerabilities through updated sub-dependencies. Pin all dependencies to exact versions (e.g., `1.25.3` instead of `^1.25.3`). Use a lock file (`package-lock.json`) to ensure deterministic dependency resolution. Regularly audit dependencies for known vulnerabilities. | LLM | server/package.json:21 |
Scan History
Embed Code
[](https://skillshield.io/report/fb82091ba91e20c4)
Powered by SkillShield