T09 · Insecure Skill Coding Practices
- Location
main.py:68- Finding
User-Controlled Output Path Allows Directory Traversal and File Overwrite
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill mostly does what it claims, but a crafted journal name can make it write outside its disclosed output folder and overwrite local files.
Install only if you trust the publisher and can run it in a constrained environment. Use normal journal names only, avoid passing untrusted or generated journal strings, and prefer a fixed output directory plus filename sanitization before broad use.
main.py:68User-Controlled Output Path Allows Directory Traversal and File Overwrite
requirements.txt:1Third-Party Dependencies Are Not Version-Pinned
The skill declares an executable Python entrypoint that performs network access and writes files locally, but the manifest does not define any permission scope or allowed-tools boundary. This creates an unnecessary trust gap: a host may execute the skill with broader capabilities than users expect, increasing the risk of data exfiltration, unsafe filesystem writes, or future code changes silently expanding behavior.
The user-facing description and operational guidance are entirely in Chinese, which imposes a specific language/locale on users without any opt-in or alternative. Under the stated policy, locale constraints should either be optional or clearly justified as region-specific; neither is present here.
The description suggests a tool that supports major journals directly, but the implementation performs a PubMed search filtered by journal name and publication type. This is a narrower behavior than implied, because the actual data source is PubMed pages rather than direct support for each named journal platform.
The stated purpose emphasizes automated retrieval and extraction as a data source, but does not disclose persistent local file output. Saving results to ~/Documents/Journal_Intel is additional behavior beyond mere extraction and may matter for user expectations about side effects.
The dependency 'requests' is not version-pinned, which makes builds non-reproducible and can cause the environment to resolve to a vulnerable or incompatible release over time. In a network-scraping skill that fetches external content, this increases supply-chain uncertainty and makes it harder to verify whether known fixes for Requests CVEs are present.
requests
beautifulsoup4
lxml
Requests has multiple published advisories, and because no version is pinned, there is no way to verify from this manifest whether a safe or vulnerable release will be installed. In a tool that performs outbound HTTP requests to retrieve journal content, this uncertainty is meaningful because HTTP client flaws can affect credential handling, TLS verification behavior, or request routing.
The dependency 'beautifulsoup4' is unpinned, so installations may pull different versions at different times, reducing reproducibility and increasing supply-chain risk. While not inherently exploitable by itself, leaving parsing libraries floating can expose the skill to future vulnerable releases or breaking changes during automated deployment.
requests
beautifulsoup4
lxml
The dependency 'lxml' is unpinned, which is risky because lxml is a complex parser with a history of security advisories. Given this skill processes scraped journal content from external sites, an uncontrolled lxml version raises the chance of deploying a release with parser-related vulnerabilities or unexpected behavior.
requests
beautifulsoup4
lxml
lxml has a notable advisory history, and the manifest does not pin a version, so the deployed parser could be an affected release without visibility. This is more relevant in this skill because it ingests and parses remotely fetched HTML/XML from journal sites, making parser security and version control important.
No suspicious patterns detected.