Back to skill

Security audit

Ensure Docs

Security checks for vulnerabilities and agentic risk

Overview

This documentation skill is coherent and user-directed, with one optional lint command users should run only through project-local dependencies.

Install only for projects where you want documentation coverage checks. Use `--report-only` if you only want findings, review the generated-file choices before allowing edits, and run JavaScript lint verification through a project script or local locked ESLint dependency rather than allowing `npx` to download packages implicitly.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
references/workflow.md:421
Finding
Unpinned ESLint Package May Be Downloaded and Executed Through npx## Vulnerability Details **File Location**: `references/workflow.md:421` **Vulnerability Type**: Unpinned third-party package execution **Risk Level**: Medium **Vulnerable code:** ```bash npx eslint . --rule 'jsdoc/require-jsdoc: error' --rule 'jsdoc/require-param: error' --rule 'jsdoc/require-returns: error' ``` ### Technical Analysis The post-generation verification workflow recommends invoking ESLint through `npx` without specifying a pinned version or requiring an existing, lockfile-managed local installation. When ESLint is not already installed in the project, `npx` may resolve and download a package from the configured npm registry before executing it. Consequently, the code ultimately executed is not fully represented by the audited Skill and may change after the audit. Its integrity depends on mutable registry state, package-manager configuration, and the security of ESLint's transitive dependency chain. User approval to run the linter limits automatic invocation but does not establish package provenance or integrity. ### Attack Path 1. The Skill generates or modifies documentation for a JavaScript or TypeScript project. 2. The Skill offers to run documentation linters, and the user approves. 3. The Agent executes the documented `npx eslint` command. 4. If no suitable local ESLint executable is installed, `npx` resolves the package through the configured npm registry. 5. A compromised registry, package release, transitive dependency, or malicious package-resolution configuration supplies attacker-controlled code. 6. Package installation hooks or the resolved CLI execute under the current Agent or user account. ### Impact Assessment Successful exploitation could run arbitrary code with the permissions of the account executing the Skill. This may permit access to project source code, environment variables, credentials readable by that account, and writable files in the project or user profile. It could also ...[truncated 287 chars]
Remediation
## Remediation Suggestions 1. Require ESLint to be declared at an exact or appropriately constrained version in the project's development dependencies and committed lockfile. 2. Require a frozen or immutable lockfile installation, such as `npm ci`, before verification. 3. Invoke the verified local executable directly: ```bash ./node_modules/.bin/eslint . --rule 'jsdoc/require-jsdoc: error' --rule 'jsdoc/require-param: error' --rule 'jsdoc/require-returns: error' ``` Alternatively, use a project-defined package script whose dependencies are controlled by the lockfile. 4. Configure `npx` to reject implicit package installation, for example: ```bash npx --no-install eslint . --rule 'jsdoc/require-jsdoc: error' --rule 'jsdoc/require-param: error' --rule 'jsdoc/require-returns: error' ``` 5. If installation is necessary, display the exact package name and pinned version and obtain separate user approval before downloading or executing it. 6. Use trusted registry configuration and dependency-integrity or provenance checks where available.
Vulnerability Patterns
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The skill explicitly directs the agent to read implementations and apply edits to source files, but it does not provide an upfront warning that user code will be modified or require explicit confirmation before making changes. In an agent setting, this increases the risk of unexpected mass edits across a codebase, including inaccurate documentation changes that could disrupt workflows or overwrite user intent.

Rp1

Medium
Category
MCP Rug Pull
Confidence
93% confidence
Finding
The workflow instructs running `npx eslint` without pinning an exact package version or requiring a locally installed dependency. In environments where `eslint` or related plugins are fetched dynamically, this can lead to execution of unexpected or malicious code from the registry, especially if a compromised package, typo-squat, or version drift is involved.

Static analysis

No suspicious patterns detected.