T09 · Insecure Skill Coding Practices
- Location
SKILL.md:139- Finding
Overprivileged npm token creation and destructive plaintext configuration write
- Content
View full analysis
{ const res = await fetch('/-/npm/v1/tokens', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ password: '', readonly: false, cidr_whitelist: [] }), }); return res.json(); }); if (tokenResult && tokenResult.token) { const npmrcPath = join(homedir(), '.npmrc'); writeFileSync(npmrcPath, `//registry.npmjs.org/:_authToken=${tokenResult.token}\n`); console.log('Token written to .npmrc!'); } ``` ### Technical Analysis The browser-side request is a same-origin request after navigation to npmjs.com, so the evidence does not indicate transmission to an unrelated third party. Nevertheless, the workflow creates a write-capable npm token with no CIDR restriction and stores it in plaintext in the user's global `~/.npmrc`. The use of `writeFileSync()` without append or merge behavior replaces the complete contents of the existing file. This may erase unrelated registry settings, scoped registry mappings, proxy configuration, or existing authentication configuration. Creating a broadly write-capable token is not necessary for every npm publication. A granular token restricted to the intended package or scope and limited to the minimum required publishing permissions would better satisfy least privilege. Native `npm login` may also establish sufficient authentication without this custom token-creation operation. ### Attack Path 1. The user or Agent follows the optional browser automation workflow. 2. The authenticated npm browser session sends the account password to the npm token API. 3. The API creates a write-capable token with an empty CIDR allowlist. 4. The Skill writes the token in plaintext to the global `~/.npmrc`. 5. A local malicious proces ...[truncated 905 chars]- Remediation
View remediation
