Security Audit
mrdulasolutions/exchekskills:exchek-encryption
github.com/mrdulasolutions/exchekskillsTrust Assessment
mrdulasolutions/exchekskills:exchek-encryption received a trust score of 60/100, placing it in the Caution category. This skill has some security considerations that users should review before deployment.
SkillShield's automated analysis identified 5 findings: 0 critical, 2 high, 1 medium, and 2 low severity. Key findings include Unpinned npm dependency version, Node lockfile missing, LLM constructs and executes shell command with user-influenced path.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 68/100, indicating areas for improvement.
Last analyzed on March 18, 2026 (commit c49adb39). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings5
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| HIGH | LLM constructs and executes shell command with user-influenced path The skill instructs the LLM to execute a local Node.js script via a shell command: `node exchek-docx/scripts/report-to-docx.mjs <full-path-to-temp.md>`. The `<full-path-to-temp.md>` argument is constructed by the LLM based on a directory path provided by the user (from 'Flow' step 1: 'Ask where to save'). If a malicious user provides a directory path containing shell metacharacters (e.g., `my_reports; rm -rf /`), the LLM might construct a command string that leads to arbitrary shell command execution on the host system. Even with LLM-based sanitization, securely handling user-influenced strings in shell commands is complex and prone to errors, posing a significant command injection risk. The LLM must strictly validate and sanitize any user-provided path components before constructing shell commands. A safer approach would be to use a dedicated API for file conversion that handles paths securely, or to pass the file content via stdin, rather than constructing and executing a shell command with user-influenced arguments. If shell execution is unavoidable, the LLM must ensure the path is properly quoted and escaped for the target shell, and ideally, only allow paths within a designated, restricted directory. | LLM | SKILL.md:60 | |
| HIGH | Skill allows arbitrary file read/write via user-controlled path to local script The `report-to-docx.mjs` script reads an input markdown file and writes a DOCX file. The path to this markdown file is passed as a command-line argument, which is derived from a temporary file created by the LLM in a user-specified directory ('Ask where to save' in 'Flow' step 1). A malicious user could provide a path like `/etc/` or `../../../../etc/` as the save location. The LLM would then create a temporary file (e.g., `/etc/.ExChek-Encryption-temp.md`) and pass this path to the script. The script would then attempt to read this file and write a `.docx` version to the same location (e.g., `/etc/.ExChek-Encryption-temp.docx`). This allows for arbitrary file write (within the LLM's permissions) to sensitive system directories. Similarly, if the user can influence the *name* of the temporary file, they could attempt to read or overwrite other files. The `path.resolve` function used in the script does not fully prevent path traversal if the base path (`process.cwd()`) or the input path (`mdPath`) contains `..` segments or absolute paths. The LLM must strictly validate and sanitize user-provided paths to ensure they are confined to a designated, non-sensitive directory (e.g., a temporary user-specific sandbox directory). Absolute paths and path traversal sequences (`..`) should be rejected or normalized to stay within the sandbox. The `report-to-docx.mjs` script itself should also implement robust path validation to ensure it only operates within an expected, secure directory. | LLM | SKILL.md:50 | |
| MEDIUM | Unpinned npm dependency version Dependency 'docx' is not pinned to an exact version ('^9.6.1'). Pin dependencies to exact versions to reduce drift and supply-chain risk. | Dependencies | exchek-encryption/scripts/package.json | |
| LOW | Node lockfile missing package.json is present but no lockfile was found (package-lock.json, pnpm-lock.yaml, or yarn.lock). Commit a lockfile for deterministic dependency resolution. | Dependencies | exchek-encryption/scripts/package.json | |
| LOW | Unpinned major version dependency in `package.json` The `scripts/package.json` file specifies the `docx` dependency with a caret (`^`) prefix (`"docx": "^9.6.1"`). This allows npm to install any `9.x.x` version that is compatible with `9.6.1`. While common, this introduces a minor supply chain risk where a future patch or minor release of `docx` could introduce a vulnerability or malicious code without explicit review, potentially affecting the security of the skill. Pin dependencies to exact versions (e.g., `"docx": "9.6.1"`) to ensure deterministic builds and prevent unexpected updates. Regularly audit and manually update dependencies to incorporate security fixes. | LLM | scripts/package.json:8 |
Scan History
Embed Code
[](https://skillshield.io/report/df48400f7e16ea45)
Powered by SkillShield