T09 · Insecure Skill Coding Practices
- Location
skill.md:3- Finding
Unredacted Source Code and Embedded Secrets May Be Submitted to a Third-Party Service
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a real code-audit service, but it sends submitted source code to an external paid endpoint without enough privacy, scoping, or reliability safeguards.
Review before installing or invoking this skill on private repositories. Only submit code you are authorized to send to the listed external service, remove secrets first, and do not treat a clean confidence score as a strong security gate unless the service is hardened for privacy, deterministic dependencies, verified payment, reliable scanner failure handling, and safe temporary-file cleanup.
skill.md:3Unredacted Source Code and Embedded Secrets May Be Submitted to a Third-Party Service
index.js:12Payment Authorization Can Be Bypassed with Any Nonempty Attacker-Controlled Value
audit.js:13Sensitive Temporary Source Files Are Not Reliably Deleted
audit.js:13Bandit Failures and Finding Exit Statuses Can Produce False-Clean Audit Results
package.json:6Unused and Loosely Pinned Production Dependencies Expand Supply-Chain Exposure
The trigger list includes very generic phrases such as 'code review' and 'security scan', which are likely to overlap with normal user requests and other skills. This can cause the skill to activate unexpectedly or too often, potentially routing sensitive code-review or security-analysis requests to a paid third-party service without clear user intent.
The skill invokes external commands via execSync without any disclosure or isolation controls, including running bandit against user-provided content. While the command string here is not directly built from user input, spawning subprocesses expands the attack surface and may execute attacker-influenced tooling from PATH or process untrusted files in a less controlled environment.
The function writes user-supplied source code to a predictable file under /tmp before scanning it. This can expose sensitive code to other local users or processes on the same host, and the file may persist if an error occurs before cleanup, increasing confidentiality risk.
The skill explicitly instructs users to send source code to a third-party remote endpoint, but it does not disclose any privacy, retention, logging, training, or data-handling practices. Because source code commonly contains proprietary logic, credentials, internal URLs, or embedded secrets, users may unintentionally exfiltrate sensitive material to an external service without informed consent.
The /audit handler accepts arbitrary source code from the request body and passes it into the audit routine, meaning user code is transmitted to and processed by this service. In this code file there is no confirmation prompt, user-facing warning, or explanatory comment/docstring near the endpoint indicating that submitted code leaves the user context and is analyzed server-side.
The dependency uses a caret range instead of an exact pinned version, which allows npm to resolve newer minor or patch releases over time. This creates supply-chain and reproducibility risk because different installations may pull different code, including a vulnerable or malicious upstream release.
"audit": "node audit.js"
},
"dependencies": {
"express": "^4.18.2",
"bandit": "^1.7.6",
"eslint": "^8.57.0",
"python-shell": "^5.0.0"
The manifest references express with a non-exact version, and known advisories exist for some express releases. Because the version is not pinned, it is not possible to verify from this file alone whether installations will resolve to an affected version, so the project carries uncertainty and potential exposure.
Using an unpinned version for bandit means the installed package may change between environments or over time without explicit review. Even for tooling, this can introduce unexpected vulnerable code or compromised package updates into the build or audit workflow.
},
"dependencies": {
"express": "^4.18.2",
"bandit": "^1.7.6",
"eslint": "^8.57.0",
"python-shell": "^5.0.0"
}
The eslint dependency is not strictly pinned, so builds may consume different package contents across installations. This weakens build integrity and can expose the project to supply-chain issues if a later allowed release contains a vulnerability or malicious change.
"dependencies": {
"express": "^4.18.2",
"bandit": "^1.7.6",
"eslint": "^8.57.0",
"python-shell": "^5.0.0"
}
}
The python-shell package is allowed to float within the caret range, which can silently introduce behavioral changes or vulnerable code. Because this package bridges Node.js and Python execution, supply-chain uncertainty around it is somewhat more sensitive than a purely passive library.
"express": "^4.18.2",
"bandit": "^1.7.6",
"eslint": "^8.57.0",
"python-shell": "^5.0.0"
}
}