T08 · Insecure Dependencies
- Location
SKILL.md:8- Finding
Unpinned Third-Party Dependencies Create a Supply-Chain Risk
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This web-scraping gateway is mostly purpose-aligned, but it includes powerful remote browser/code execution plus unsafe credential and dependency practices that need review before installation.
Review this skill before installing. Use it only in an isolated environment with a pinned, reviewed dependency set and your own scoped gateway key. Avoid submitting sensitive internal URLs, private page content, credentials, or logged-in browser sessions unless you understand that payloads are sent through an external gateway and browser actions may affect real sites.
SKILL.md:8Unpinned Third-Party Dependencies Create a Supply-Chain Risk
scripts/firecrawl_agent.py:9Public Hard-Coded Fallback Gateway Credential Causes Shared-Identity Use
The skill includes a browser execution primitive that can run bash, Python, or Node code against live browser sessions, far exceeding the stated gateway/scraping purpose. This creates a strong capability-escalation path: an agent using the skill can navigate sites, interact with authenticated sessions, and execute arbitrary automation with limited user awareness.
The skill declares environment-variable use and file-reading related capability but does not define any explicit permission or allowed-tools boundary. In a skill that also documents networked scraping, autonomous browsing, and browser/code-execution features, missing scope declarations weakens least-privilege controls and makes it easier for an agent runtime to over-grant access.
The manifest describes the skill as merely an auto-generated gateway wrapper, but the body exposes materially more powerful capabilities including autonomous agent behavior, persistent browser sessions, and direct code execution. This understatement can cause operators or upstream policy engines to misclassify the skill's risk and grant it in contexts where such capabilities are inappropriate.
The skill sends user prompts, URLs, and scraped page content to external services for search, scraping, crawling, extraction, and agent workflows, but it does not clearly warn about privacy and data-handling implications. This can lead users to submit sensitive internal URLs, credentials-bearing pages, or proprietary text to third-party infrastructure unintentionally.
Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.
**Best for:** Extracting content from multiple related pages, when you need comprehensive coverage.
**Not recommended for:** Extracting content from a single page (use scrape); when token limits are a concern (use map + batch_scrape); when you need fast results (crawling can be slow).
**Warning:** Crawl responses can be very large and may exceed token limits. Limit the crawl depth and number of pages, or use map + batch_scrape for better control.
**Common mistakes:** Setting limit or maxDiscoveryDepth too high (causes token overflow) or too low (causes missing pages); using crawl for a single page (use scrape instead). Using a /* wildcard is not recommended.
**Prompt Example:** "Get all blog posts from the first two levels of example.com/blog."
**Usage Example:**
The autonomous research agent capability goes beyond a generic gateway description by allowing independent browsing, searching, and data gathering across the web. That mismatch increases the chance that users or orchestrators invoke the skill without understanding that it can trigger broader outbound activity and content collection than simple scraping.
The browser execution and action features can click, type, run code, and otherwise act on third-party sites, but the documentation lacks a clear warning that these actions may affect live user sessions or perform impactful operations. Without that warning, users may invoke the skill in authenticated contexts and unintentionally authorize destructive or privacy-impacting actions.
Using npx onekey without pinning an exact package version allows the latest published package to be fetched and executed at runtime. This creates a supply-chain execution risk where a malicious or compromised upstream release could run arbitrary code in the user's environment.
The CLI examples use argument names and shapes that differ from the documented interfaces, such as mismatched IDs and parameter names. In security-sensitive tooling, these inconsistencies can mislead wrappers, encourage unsafe trial-and-error, and cause users to invoke the wrong operations or rely on undocumented fallback behavior.
This example invokes npx onekey without a pinned version, which permits execution of whatever package version is currently resolved from the registry. That expands supply-chain risk and can lead to arbitrary code execution if the package or dependency tree is compromised.
The unpinned npx onekey command executes remote package code with no version constraint. In a skill intended to be copied by users, that creates repeatable supply-chain exposure across every invocation.
Because npx onekey is unversioned here, users may unknowingly execute a newly published or tampered package version. This is especially risky because the skill also handles API keys and remote browsing workflows.
This command uses an unpinned npx package invocation, exposing users to arbitrary upstream changes at execution time. The impact is amplified because the surrounding skill can access secrets and remote content, making a compromised CLI more dangerous.
Running npx onekey without version pinning introduces a classic supply-chain risk: the package resolved today may differ from the one reviewed when the skill was authored. That can result in arbitrary code execution on the client host.
An unpinned npx invocation means the executed implementation is not reproducible and may change between runs. For a toolchain that can launch browser sessions and process user-supplied prompts, this materially increases compromise risk.
The example's npx onekey call is not pinned, allowing registry-side changes to affect what code executes. This is a real supply-chain weakness rather than a documentation-only nit because users are encouraged to run the command directly.
Here again, the skill instructs users to execute an unpinned package through npx, which trusts the live registry at runtime. If upstream publication is compromised, attackers could gain code execution in user environments.
This example normalizes unpinned npx execution, creating unnecessary supply-chain exposure. Because the skill is positioned as a gateway to multiple external APIs and browser automation features, compromise of the invoked CLI could have broad downstream impact.
The command fetches and runs npx onekey without an immutable version, so the trusted codebase is effectively undefined. This is dangerous in practice because users are likely to copy-paste the example into real environments containing credentials.
The unpinned npx onekey invocation leaves execution dependent on mutable upstream state. In combination with documented browser and network capabilities, a compromised package could exfiltrate secrets or perform arbitrary actions.
The script reads an access credential from an environment variable and even falls back to a hardcoded default token-like value, which creates a real secret-management risk. In an auto-generated wrapper context, this is more dangerous because the skill is expected to be a thin tool adapter, yet it silently introduces authentication behavior that could enable unauthorized third-party API access or accidental credential exposure.
The code sends the full user-supplied payload to a remote router without any disclosure, filtering, or consent boundary. This is dangerous because prompts or attached data may contain secrets, internal URLs, or sensitive content that users may not realize will be transmitted off-host to an external service.
The script embeds a usable default access credential in code via a fallback value for the router token. Hardcoded default credentials are dangerous because anyone with the file can invoke the upstream service if the environment variable is unset, and shared default secrets often spread into logs, forks, and packaged artifacts.
This code invokes an external router with the full user-supplied payload, which may transmit user or system data over the network. The file contains no confirmation prompt, user-facing disclosure, or explanatory comment/docstring warning that input data will be sent to an external service.
The router credential is sourced from an environment variable but falls back to a hard-coded default key string when the variable is absent. Embedding a usable default credential in code is dangerous because it can enable unauthorized service access, accidental credential reuse across environments, and disclosure of a secret to anyone with source access.
No suspicious patterns detected.