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.
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
The Skill generates or modifies documentation for a JavaScript or TypeScript project.
The Skill offers to run documentation linters, and the user approves.
The Agent executes the documented npx eslint command.
If no suitable local ESLint executable is installed, npx resolves the package through the configured npm registry.
A compromised registry, package release, transitive dependency, or malicious package-resolution configuration supplies attacker-controlled code.
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
View remediation
Remediation Suggestions
Require ESLint to be declared at an exact or appropriately constrained version in the project's development dependencies and committed lockfile.
Require a frozen or immutable lockfile installation, such as npm ci, before verification.
Invoke the verified local executable directly:
bash
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.
Content
No source excerpt is available for this finding.
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.
