T08 · Insecure Dependencies
- Location
SKILL.md:1- Finding
Unpinned npx Package Execution Creates a Supply-Chain Risk
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This browser automation skill is mostly purpose-aligned, but it needs review because it can run an unpinned npm package and encourages reusable authenticated browser state without strong handling controls.
Install only if you are comfortable with a powerful browser automation tool. Prefer a pinned, reviewed agent-browser version instead of unpinned npx; avoid real credentials in examples; store auth-state, screenshots, videos, profiles, and traces outside shared or version-controlled locations with restrictive permissions; clear sessions after use; and avoid using saved sessions on sensitive accounts unless explicitly needed.
SKILL.md:1Unpinned npx Package Execution Creates a Supply-Chain Risk
templates/authenticated-session.sh:22Authentication State Is Persisted Without Enforced Access Controls
templates/form-automation.sh:54Predictable Screenshot File in Shared Temporary Directory
Session recording can capture page contents, typed inputs, authentication flows, tokens visible in URLs, and other sensitive contextual data. In a browser automation skill that may be used for login and application testing, recording materially increases the risk of secret leakage through saved video artifacts.
agent-browser --headed open https://example.com
agent-browser highlight @e1 # Highlight element
agent-browser record start demo.webm # Record session
agent-browser profiler start # Start Chrome DevTools profiling
agent-browser profiler stop trace.json # Stop and save profile (path optional)
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Clean up after automation
agent-browser cookies clear
rm -f ./auth-state.json
Use short-lived sessions for CI/CD
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
echo "*.auth-state.json" >> .gitignore
rm /tmp/auth-state.json
### 4. Timeout Long Sessions
Referencing npx agent-browser in the manifest without an exact version permits fetching whatever version is current at execution time. In an agent skill, this creates a direct path for remote code execution through package substitution, malicious updates, or dependency compromise.
The invocation description is broad enough that the skill may activate for many generic browsing, login, scraping, or testing requests, causing the agent to use a powerful browser automation capability more often than necessary. In practice, overbroad triggering expands the attack surface and raises the chance of the agent being steered into handling credentials, session tokens, or untrusted web content without sufficient user confirmation.
The skill allows execution of npx agent-browser without pinning an exact package version, which means the resolved code can change over time or be replaced by a compromised upstream release. Because this skill is explicitly designed for browser automation with access to websites, sessions, local state, and potentially credentials, an unpinned package materially increases supply-chain risk.
The authentication and state-persistence examples encourage saving and reusing browser state that may contain cookies, tokens, and other login artifacts, but they do not prominently warn that this data is sensitive and may grant account access. In an agent context, normalized reuse of saved auth state can lead to account takeover risk if the files are exposed, reused across tasks, or handled in shared environments.
The configuration example encourages persistent browser profiles in the project directory, which can retain cookies, local storage, cached tokens, and browsing history across runs. In multi-user workspaces, repositories, or shared agent environments, this persistence can leak session data or cause unintended reuse of privileged state.
Create agent-browser.json in the project root for persistent settings:
{
The documentation includes hardcoded example credentials such as email addresses and plaintext passwords in authentication flows without placing an immediate warning near the examples. In a browser automation skill, users may copy these patterns directly into scripts or prompts, normalizing unsafe secret handling and increasing the chance that real credentials are exposed in shell history, logs, screenshots, or version control.
The state-saving section instructs users to persist authenticated browser state to a JSON file before any explicit warning that the file contains reusable session secrets. In this skill context, saved browser state can effectively function as a bearer token, so normalizing its storage without an upfront caution increases the risk of credential theft, accidental sharing, or repository leakage.
Passing usernames and passwords directly on the command line can expose secrets through shell history, process listings, CI logs, and telemetry. Because this command reference presents the pattern without any warning or safer alternative, it promotes an unsafe secret-handling practice.
The manifest describes navigation, form filling, clicking, screenshots, extraction, testing, login, and general browser interaction. While some scripting can support automation, documenting eval with base64 and stdin explicitly enables arbitrary code execution inside webpages, which is a broader capability than the core user-facing purpose described in the manifest.
The state save/load commands explicitly persist cookies, storage, and auth state, which can contain active session tokens and credentials. Documenting this without warning encourages unsafe handling of highly sensitive artifacts that could be copied, committed, or reused for account takeover.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
agent-browser state save auth.json # Save cookies, storage, auth state
agent-browser state load auth.json # Restore saved state
The manifest focuses on interacting with websites and automating browser tasks, but --extension <path> adds the ability to run extra extension code with its own privileges and behaviors. That materially broadens the skill beyond straightforward browser automation and is not disclosed in the stated purpose.
The profiling documentation repeatedly instructs users to capture and save Chrome trace files but does not warn that these traces can contain sensitive data such as visited URLs, timing of authenticated actions, page structure details, and potentially application-specific markers or identifiers. In an agent-driven browser automation context, users may profile login flows, internal apps, or CI runs and then store or share the resulting JSON artifacts, increasing the chance of unintentional data exposure.
The documentation shows proxy credentials embedded directly in an environment-variable URL, but does not warn that secrets placed this way may be exposed through shell history, process listings, logs, CI output, or copied examples. In a browser automation skill, users are likely to paste these commands into real environments, increasing the chance of credential leakage to local observers or operational tooling.
The SOCKS proxy example includes username and password in the proxy URL without any guidance on secret-handling risks. This can lead users to expose proxy credentials via shell history, scripts, logs, screenshots, or environment inspection, which is especially relevant for an automation tool that may run in shared developer machines or CI systems.
The documentation explicitly shows loading a previously saved browser auth-state file, which can contain cookies and other authenticated session artifacts. In a browser automation skill, this is security-relevant because reuse of state files can enable credential/session hijacking if the file is stolen, shared across tasks, or loaded into the wrong context.
# Restore saved state
agent-browser state load /path/to/auth-state.json
# Continue with authenticated session
The documentation encourages recording browser sessions for debugging and verification but does not warn that videos can capture sensitive on-screen data such as credentials, session tokens, personal information, or internal application content. In the context of a browser automation skill that may be used for logins, form filling, and web app testing, this omission increases the risk of accidental collection and retention of sensitive data in artifacts.
The template instructs users to place login credentials in environment variables but does not mention safe handling practices or the risk of exposing secrets through shell history, process inspection in some environments, CI logs, or inherited subprocess environments. While environment variables are common for automation, omitting any warning in a reusable auth template increases the chance that users will handle credentials insecurely.
The script saves authenticated browser session state to a JSON file and reuses it later, but provides no warning that this file may contain cookies, tokens, or other bearer credentials that can grant account access if copied. In a browser automation skill, this is particularly sensitive because the saved state is explicitly intended to bypass re-authentication, so accidental exposure of the file can directly enable session hijacking.
Cookie and localStorage inspection/manipulation commands can expose authentication tokens, personal data, and application secrets stored in the browser. In an agent-oriented browser skill, these commands are especially sensitive because they make it easy to extract or alter state without any privacy or handling guidance.
Viewing tracked network requests may reveal authorization headers, cookies, CSRF tokens, query secrets, and sensitive request/response bodies. The omission of a warning is risky because operators may capture or store this data inadvertently during routine automation tasks.
This markdown file demonstrates entering an email and password and submitting a login form, which affects user privacy and sensitive data handling. The surrounding documentation does not include any warning or disclosure about using real credentials, test accounts, or exercising caution with sensitive information.
No suspicious patterns detected.