Security audit

Amazon Scraper

Security checks for vulnerabilities and agentic risk

Overview

The skill appears purpose-built for Amazon product scraping, but it needs review because it uses a paid third-party API key with unsafe credential guidance and weak crawl scoping.

Install only if you are comfortable using your own Apify account for Amazon scraping. Keep the API key in an environment variable or secret manager, do not hardcode it, use a virtual environment, review Apify cost limits, and avoid enabling cron until you have bounded the crawl and fixed the report-generation bug.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (8)

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: generate_report returns unique_products[:max_products], but max_products is not defined in that function scope. This causes a runtime NameError, producing a denial of service for the script and preventing report generation whenever the function executes successfully to that point.

Vague Triggers

Medium

Confidence: 82% confidence
Finding: The invocation examples use a broad natural-language trigger phrase that could cause accidental activation in ordinary conversation. In an agent environment, this raises the risk of unintended web scraping, external API use, and local file creation without sufficiently explicit user confirmation.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The skill description says it scrapes Amazon data and generates reports, but does not clearly disclose that user queries/data may be sent to Apify and that files will be written locally. This weakens informed consent and can lead to unintended third-party data exposure, API spend, or workspace side effects when the skill is invoked.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The guide explicitly suggests either exporting the Apify API key as an environment variable or hardcoding it directly into `amazon_scraper.py`, but it does not warn about secret leakage risks such as committing credentials to source control, sharing screenshots, or leaving keys in shell history and files. Hardcoding an API key is especially risky because it can persist in the codebase and be exposed to collaborators or public repositories.

Unpinned Dependencies

Low

Category: Supply Chain
Content: openpyxl>=3.0.0 requests>=2.28.0
Confidence: 94% confidence
Finding: The dependency is specified with only a lower bound, which permits installation of any newer version and makes builds non-reproducible. This can unexpectedly introduce vulnerable or breaking releases into the environment and increases supply-chain risk, especially because the package also has historical security advisories.

Unpinned Dependencies

Low

Category: Supply Chain
Content: openpyxl>=3.0.0 requests>=2.28.0
Confidence: 96% confidence
Finding: Using an unpinned requests version allows dependency drift, so different installs may resolve to different releases with different security properties. Given that requests has multiple published advisories, failing to pin and regularly audit the chosen version increases the chance of pulling a vulnerable release into production.

Known Vulnerable Dependency: openpyxl — 2 advisory(ies): CVE-2017-5992 (Improper Restriction of XML External Entity Reference in Openpyxl); CVE-2017-5992 (Openpyxl 2.4.1 resolves external entities by default, which allows remote attack)

High

Category: Supply Chain
Confidence: 88% confidence
Finding: The requirement allows installation of openpyxl versions starting at 3.0.0, while the static finding references historical CVEs in older 2.4.x releases. As written, this exact constraint does not appear to include the cited vulnerable versions, but because the dependency is not pinned and the package processes spreadsheet/XML content, dependency selection and transitive environment differences still create meaningful attack surface; this is therefore better treated as a real supply-chain hygiene issue, though the cited CVE match may be stale or overbroad.

Known Vulnerable Dependency: requests — 10 advisory(ies): CVE-2014-1830 (Exposure of Sensitive Information to an Unauthorized Actor in Requests); CVE-2024-47081 (Requests vulnerable to .netrc credentials leak via malicious URLs); CVE-2024-35195 (Requests `Session` object does not verify requests after making first request wi) +7 more

High

Category: Supply Chain
Confidence: 93% confidence
Finding: The requests dependency has numerous published advisories, and the loose constraint permits a broad range of versions, potentially including affected releases. Because requests commonly handles outbound network communication and authentication context, exploitation could lead to credential leakage, SSRF-adjacent issues, or TLS/verification weaknesses depending on the resolved version and usage.

Static analysis

No suspicious patterns detected.