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.
