test safe agent-browser

• Outcome: Review
• Latest audit: Sep 16, 2026 · 3:46 AM UTC
• Version: 1.0.0

Overview

This skill is a powerful browser automation wrapper presented as restricted and safe, but its documented defaults and templates allow broad navigation, authentication, session persistence, file access, and page scripting without enforced guardrails.

Review this as a high-trust browser automation skill, not a read-only browser helper. Install only if you are comfortable with an unpinned npm tool controlling browser sessions, interacting with authenticated sites, saving cookies/session data, writing capture files, and running page JavaScript; use strict domain allowlists, content boundaries, output limits, a pinned package version, encrypted state, and avoid reusing saved auth state unless explicitly needed.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (5)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:4
• Finding: Unpinned third-party browser package execution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:4` **Vulnerability Type**: Unpinned third-party dependency execution **Risk Level**: Medium ### Vulnerable Code ```yaml allowed-tools: Bash(npx agent-browser:*) ``` ### Technical Analysis The Skill authorizes execution of `agent-browser` through `npx` without identifying an exact package version, integrity hash, lockfile, or trusted package source. Consequently, the implementation retrieved and executed by `npx` can change after the Skill has been reviewed. If the package name is compromised, transferred, replaced, or resolved from an untrusted registry, the package installation lifecycle or executable can run arbitrary code with the privileges of the Agent process. The repository does not include dependency metadata that pins and verifies the expected implementation. ### Attack Path 1. An attacker compromises the npm package, package owner, or configured npm registry. 2. A malicious version is published under the package name accepted by the tool rule. 3. The Agent invokes the allowed `npx agent-browser` command. 4. `npx` resolves and executes the malicious package version. 5. The package gains the filesystem, network, and process privileges available to the Agent. ### Impact Assessment Successful exploitation could result in arbitrary local code execution under the Agent's operating-system account. This may expose project files, environment variables, browser state, authentication artifacts, and any other resources accessible to that account. No privilege escalation beyond the Agent account is demonstrated by the audited files. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin `agent-browser` to a reviewed, exact version rather than accepting any current registry version. 2. Use a lockfile and verify package integrity hashes before execution. 3. Install the audited package in a controlled build step instead of resolving it dynamically on every invocation. 4. Restrict npm to a trusted registry and disable unexpected lifecycle scripts where operationally possible. 5. Record the expected package owner, version, source repository, and integrity value in the Skill metadata. 6. Periodically review the pinned version before upgrading it. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:10
• Finding: Mandatory browser safety controls are documented but not enforced<![CDATA[ ## Vulnerability Details **File Locations**: - `SKILL.md:10-14` - `SKILL.md:292-307` - `templates/form-automation.sh:16-21` - `templates/capture-workflow.sh:16-27` - `templates/authenticated-session.sh:27-58` **Vulnerability Type**: Fail-open browser security configuration **Risk Level**: High ### Vulnerable Code The main instructions describe content boundaries as mandatory but only recommend a domain allowlist: ```bash export AGENT_BROWSER_CONTENT_BOUNDARIES=1 export AGENT_BROWSER_MAX_OUTPUT=20000 ``` ```markdown 3. **網域白名單**：建議設定 `AGENT_BROWSER_ALLOWED_DOMAINS` 僅限於工作相關網域。 ``` The action policy is presented as an optional environment setting: ```bash export AGENT_BROWSER_ACTION_POLICY=./policy.json ``` The supplied templates then open caller-controlled URLs without setting or validating any of these controls: ```bash FORM_URL="${1:?Usage: $0 <form-url>}" echo "Form automation: $FORM_URL" # Step 1: Navigate to form agent-browser open "$FORM_URL" agent-browser wait --load networkidle ``` ```bash TARGET_URL="${1:?Usage: $0 <url> [output-dir]}" OUTPUT_DIR="${2:-.}" echo "Capturing: $TARGET_URL" mkdir -p "$OUTPUT_DIR" # Navigate to target agent-browser open "$TARGET_URL" agent-browser wait --load networkidle ``` ```bash LOGIN_URL="${1:?Usage: $0 <login-url> [state-file]}" STATE_FILE="${2:-./auth-state.json}" echo "Authentication workflow: $LOGIN_URL" ... agent-browser open "$LOGIN_URL" agent-browser wait --load networkidle ``` ### Technical Analysis The repository includes a restrictive `policy.json`, but the policy is inactive unless `AGENT_BROWSER_ACTION_POLICY` points to it. None of the ready-to-use templates activates that policy or verifies that the variable is already set. Likewise, the templates do not enforce content-boundary markers, output limits, or a domain allowlist. They accept arbitrary URL arguments and pass them directly to the browser. This conflicts with the Skill's claim that hardened operation is mandatory and caus ...[truncated 1427 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Set the following controls inside every executable template before opening a URL: ```bash export AGENT_BROWSER_CONTENT_BOUNDARIES=1 export AGENT_BROWSER_MAX_OUTPUT="${AGENT_BROWSER_MAX_OUTPUT:-20000}" export AGENT_BROWSER_ACTION_POLICY="/absolute/path/to/policy.json" ``` 2. Require `AGENT_BROWSER_ALLOWED_DOMAINS` and terminate if it is empty. 3. Parse and validate every URL, allowing only `https://` and explicitly approved `http://` destinations. 4. Reject `file:`, `data:`, `about:`, loopback, link-local, private-network, and metadata-service destinations unless a separately authorized workflow requires them. 5. Resolve the policy path relative to the template's trusted installation directory, not the caller's working directory. 6. Fail closed if any required control is missing or the policy cannot be loaded. 7. Re-snapshot and validate the current origin after redirects before any interaction. 8. Keep dangerous actions such as authentication, upload, JavaScript evaluation, and state loading denied unless explicitly approved for the current task. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: templates/authenticated-session.sh:28
• Finding: Caller-controlled state path can cause arbitrary file deletion<![CDATA[ ## Vulnerability Details **File Location**: `templates/authenticated-session.sh:28-51` **Vulnerability Type**: Unsafe file deletion using a caller-controlled path **Risk Level**: Medium ### Vulnerable Code ```bash LOGIN_URL="${1:?Usage: $0 <login-url> [state-file]}" STATE_FILE="${2:-./auth-state.json}" echo "Authentication workflow: $LOGIN_URL" # ================================================================ # SAVED STATE: Skip login if valid saved state exists # ================================================================ if [[ -f "$STATE_FILE" ]]; then echo "Loading saved state from $STATE_FILE..." if agent-browser --state "$STATE_FILE" open "$LOGIN_URL" 2>/dev/null; then agent-browser wait --load networkidle CURRENT_URL=$(agent-browser get url) if [[ "$CURRENT_URL" != *"login"* ]] && [[ "$CURRENT_URL" != *"signin"* ]]; then echo "Session restored successfully" agent-browser snapshot -i exit 0 fi echo "Session expired, performing fresh login..." agent-browser close 2>/dev/null || true else echo "Failed to load state, re-authenticating..." fi rm -f "$STATE_FILE" fi ``` ### Technical Analysis The second positional argument completely controls `STATE_FILE`. The script checks only whether the path refers to a regular file. If state loading fails, or if the resulting URL appears to be a login page, the script unconditionally executes `rm -f "$STATE_FILE"`. There is no canonical-path validation, ownership check, dedicated state directory, expected file-format verification before deletion, or proof that the script originally created the target. Shell quoting prevents command injection, but it does not prevent deletion of an unintended file. ### Attack Path 1. The script is invoked with the path of an existing user-writable file as its second argument. 2. The file satisfies `[[ -f "$STATE_FILE" ]]`. 3. The browser cannot load it a ...[truncated 516 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Store all state under a dedicated private directory created by the script: ```bash STATE_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/agent-browser-safe" install -d -m 700 "$STATE_DIR" ``` 2. Accept a state identifier rather than an arbitrary filesystem path. 3. Canonicalize the resolved path and verify that it remains beneath `STATE_DIR`. 4. Reject symlinks and verify file ownership before loading or deleting state. 5. Delete only files created and tracked by the script. 6. Replace unconditional deletion with quarantine or an explicit user-confirmed cleanup operation. 7. Validate the state file's expected format before treating it as managed browser state. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: templates/authenticated-session.sh:29
• Finding: Authentication state is persisted without enforced confidentiality or safe temporary-file handling<![CDATA[ ## Vulnerability Details **File Locations**: - `templates/authenticated-session.sh:29,101-103` - `references/authentication.md:43-56` - `references/session-management.md:43-73` - `references/session-management.md:77-100` **Vulnerability Type**: Insecure storage of session tokens and browser state **Risk Level**: High ### Vulnerable Code The template uses a normal relative file and saves authenticated state without establishing restrictive permissions: ```bash STATE_FILE="${2:-./auth-state.json}" ``` ```bash # Save state for future runs # echo "Saving state to $STATE_FILE" # agent-browser state save "$STATE_FILE" # echo "Login successful" ``` The session-management documentation recommends a predictable global temporary path: ```bash STATE_FILE="/tmp/auth-state.json" # Check if we have saved state if [[ -f "$STATE_FILE" ]]; then agent-browser state load "$STATE_FILE" agent-browser open https://app.example.com/dashboard else # Perform login agent-browser open https://app.example.com/login agent-browser snapshot -i agent-browser fill @e1 "$USERNAME" agent-browser fill @e2 "$PASSWORD" agent-browser click @e3 agent-browser wait --load networkidle # Save for future use agent-browser state save "$STATE_FILE" fi ``` The same documentation states that the saved file contains sensitive browser material: ```json { "cookies": [...], "localStorage": {...}, "sessionStorage": {...}, "origins": [...] } ``` ### Technical Analysis Saved browser state can contain reusable session cookies, bearer tokens, local-storage credentials, and origin-specific application data. The examples do not set a restrictive `umask`, pre-create the file with mode `0600`, encrypt the state, verify file ownership before loading, or use an unpredictable private temporary directory. The predictable `/tmp/auth-state.json` example also creates collision and replacement risks on multi-user systems. Depending on the behavior of `agen ...[truncated 1221 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Prefer the encrypted authentication vault described by the Skill instead of raw state files. 2. If state files are unavoidable, create a private directory with mode `0700` and set `umask 077` before saving. 3. Pre-create state files securely with mode `0600`, or verify that the browser tool guarantees equivalent permissions. 4. Do not use fixed names in shared `/tmp`; use `mktemp -d` and verify ownership. 5. Encrypt state at rest with a securely managed key. 6. Verify canonical path, owner, mode, and absence of symlinks before loading state. 7. Add an `EXIT` trap for cleanup when persistence is not explicitly required. 8. Prevent state files from entering source control, logs, build artifacts, backups, or broadly readable output directories. 9. Use short-lived sessions and server-side revocation where possible. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/proxy-support.md:40
• Finding: Proxy examples expose credentials and permit TLS verification bypass<![CDATA[ ## Vulnerability Details **File Location**: `references/proxy-support.md:40-59,172-179` **Vulnerability Type**: Insecure proxy credential handling and disabled certificate verification **Risk Level**: Medium ### Vulnerable Code The documentation places proxy credentials directly in environment-variable URLs: ```bash # Include credentials in URL export HTTP_PROXY="http://username:[e-mail]:8080" agent-browser open https://example.com ``` ```bash # SOCKS5 with auth export ALL_PROXY="socks5://user:[e-mail]:1080" agent-browser open https://example.com ``` It also documents disabling TLS verification: ```bash ### SSL/TLS Errors Through Proxy Some proxies perform SSL inspection. If you encounter certificate errors: ```bash # For testing only - not recommended for production agent-browser open https://example.com --ignore-https-errors ``` ``` ### Technical Analysis Proxy URLs containing cleartext credentials can be exposed through inherited process environments, diagnostic output, crash reports, shell-session capture, or accidental logging. The environment variable may also be inherited by unrelated child processes. The `--ignore-https-errors` option disables server-certificate validation. If used with an untrusted or compromised proxy, it allows forged certificates to be accepted, removing a principal defense against man-in-the-middle interception. The documentation labels this as testing-only, which reduces but does not eliminate the risk of the example being copied into operational automation. ### Attack Path 1. A user configures proxy credentials in `HTTP_PROXY` or `ALL_PROXY` as documented. 2. Another local process, diagnostic system, or log collector obtains the environment value. 3. The attacker recovers the proxy username and password. For the TLS path: 1. A user encounters certificate errors through a proxy and enables `--ignore-https-errors`. 2. An attacker controls or intercepts the proxy connection. ...[truncated 584 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Avoid embedding proxy credentials in command lines or broadly inherited environment variables. 2. Use a protected credential store, restricted configuration file, or proxy-specific secret-injection mechanism. 3. Redact user information from proxy URLs before logging or displaying configuration. 4. Scope proxy variables to only the required process and unset them immediately afterward. 5. Configure the organization's trusted inspection CA rather than disabling TLS validation. 6. Remove the TLS-bypass example from general troubleshooting or require an explicit isolated-test guard. 7. Prohibit TLS bypass for authentication, production, financial, administrative, and other sensitive workflows. 8. Add automated checks that reject `--ignore-https-errors` unless a dedicated test-mode flag is active. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence

Findings (48)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The skill is presented as restricted navigation, screenshots, and public-data extraction, but it also supports interactive state-changing actions such as form filling, clicking, and submission. That discrepancy increases the chance of unintended writes, account changes, or other destructive browser-side actions under a falsely narrow safety label.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The skill is presented as restricted navigation, screenshots, and public-data extraction, but it also supports interactive state-changing actions such as form filling, clicking, and submission. That discrepancy increases the chance of unintended writes, account changes, or other destructive browser-side actions under a falsely narrow safety label.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The file says execution is forbidden without safety boundaries, but later admits that all security features are opt-in and unrestricted behavior is the default. This contradiction is dangerous because users may rely on the earlier assurance while the actual runtime defaults permit unsafe navigation, output, and action behavior.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The skill claims to be restricted, yet it exposes capabilities such as credential vaulting, authenticated login, persistent state storage, downloads, local file interaction, proxy support, and arbitrary JavaScript evaluation. This is a broad privilege surface that can access sensitive data, alter sessions, and create local artifacts beyond the stated purpose.

Missing User Warnings

High

• Confidence: 96% confidence
• Finding: The documentation encourages saving authentication state to disk but does not clearly warn that the saved state can include sensitive cookies, bearer tokens, and session identifiers. If those files are exposed, copied, or reused improperly, an attacker could hijack authenticated sessions.

Missing User Warnings

High

• Confidence: 96% confidence
• Finding: Auto-saved session persistence retains cookies and localStorage across runs without a prominent warning about the sensitivity of that data. Persistent browser state can silently carry authentication across tasks, increasing the risk of cross-task data leakage, unauthorized reuse, or session theft.

Context Leakage

High

• Category: Data Exfiltration

Content

```bash
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)
```

• Confidence: 89% confidence
• Finding: Session recording can capture credentials, tokens, personal data, and other sensitive page contents visible during browsing. In this skill, recording is normalized as a debugging feature without guardrails, so artifacts like `.webm` files may become durable context leaks if stored or shared.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: Allowing `file://` access exposes local filesystem contents to the browser automation flow, yet the section lacks a strong warning about that risk. In an agent setting, this can bridge web automation into local file disclosure, especially if combined with extraction, screenshots, or script execution.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The file documents login flows, session persistence, OAuth, 2FA, cookies, and credential handling even though the skill is described as a restricted browser for navigation, screenshots, public-data extraction, and testing. This expands the effective capability boundary into authenticated-session handling, which can enable account access, token capture, and reuse of privileged browser state beyond the declared safe scope.

Context-Inappropriate Capability

High

• Confidence: 98% confidence
• Finding: The examples directly handle usernames, passwords, auth cookies, HTTP Basic credentials, and persistent state files. In a supposedly restricted 'safe' browser skill, this materially increases risk by normalizing storage and replay of live authentication artifacts that could be abused for unauthorized access or lateral movement if exposed.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

3. **Clean up after automation**
   ```bash
   agent-browser cookies clear
   rm -f ./auth-state.json
   ```

4. **Use short-lived sessions for CI/CD**

• Confidence: 85% confidence
• Finding: 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).

Intent-Code Divergence

High

• Confidence: 98% confidence
• Finding: The documentation presents the tool as restricted and safe, yet the reference exposes broad code execution, persistence, authentication, and state-changing features. This mismatch is dangerous because operators and downstream agents may rely on the safety framing while unknowingly invoking much more powerful capabilities.

Description-Behavior Mismatch

High

• Confidence: 95% confidence
• Finding: The command reference includes request interception and response mocking features that materially exceed a 'restricted browser automation' tool intended only for navigation, screenshots, and public-data extraction. These capabilities can alter application behavior, bypass intended workflows, and facilitate unauthorized testing or manipulation if exposed to an agent without strong policy enforcement.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The documented support for credentials, cookies, localStorage manipulation, and request routing expands the tool from passive browsing into persistent authenticated session control and browser state modification. In the context of a supposedly limited safe browser skill, this creates a path to retain secrets, impersonate users, and alter execution context beyond public-data extraction.

Description-Behavior Mismatch

High

• Confidence: 99% confidence
• Finding: Arbitrary JavaScript execution via eval, base64 input, or stdin directly contradicts the skill's stated safety-bounded purpose. It enables inspection and modification of page state, extraction of sensitive DOM data, and execution of complex logic that bypasses higher-level safety constraints normally imposed by limited browser commands.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

echo "*.auth-state.json" >> .gitignore

# Delete after use
rm /tmp/auth-state.json
```

### 4. Timeout Long Sessions

• Confidence: 85% confidence
• Finding: 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).

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The template explicitly supports authenticated login and session reuse, which expands the skill beyond its declared restricted browsing scope of navigation, screenshots, public data extraction, and testing. Even though much of the actual login flow is commented out, the file is a ready-made workflow for handling authenticated access and persistent session state, creating a capability/policy mismatch that can enable access to non-public data.

Context-Inappropriate Capability

High

• Confidence: 97% confidence
• Finding: The template introduces credential ingestion via environment variables and persistent authenticated state storage, neither of which is necessary for a tool described as limited to public-data browsing and testing. This increases the risk of credential misuse, accidental secret exposure, and unauthorized replay of authenticated sessions through the saved state file.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The template enables active form filling, submission, and post-submit verification, which exceeds the stated skill scope of navigation, screenshots, extraction of public data, and testing under constrained boundaries. In practice, this can be used to perform unauthorized actions on third-party sites, submit sensitive data, or drive workflows that materially change remote state, making the mismatch between declared purpose and actual capability security-relevant.

Context-Inappropriate Capability

High

• Confidence: 97% confidence
• Finding: Including a file upload example introduces a path for local file exfiltration or accidental disclosure of sensitive host data, especially if operators reuse the template without understanding the trust boundary. Because the skill's stated purpose does not justify local file access, this capability is unusually dangerous in context and can be abused to transmit arbitrary files to remote forms.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 91% confidence
• Finding: The skill allows execution via `npx agent-browser:*` without pinning a specific package version. That creates supply-chain risk because future package updates or a compromised upstream release could change behavior or introduce malicious code while retaining the same invocation path.

Intent-Code Divergence

Medium

• Confidence: 90% confidence
• Finding: Early text frames snapshots as a way to avoid reading sensitive full-page content, but later sections document unrestricted full-page text extraction and arbitrary JS execution in the browser context. This inconsistency can cause operators to underestimate the amount of untrusted or sensitive content the skill can ingest and expose.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The download and file output examples write artifacts to the local filesystem without clearly warning about that side effect. This can lead to unreviewed persistence of untrusted files, storage of sensitive content, or accidental overwriting/exfiltration paths in agent workflows.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The example `get text body > page.txt` writes full-page contents to disk without warning that the page may contain secrets, personal data, or copyrighted material. In a browser automation context, this can create unexpected local data residues and broaden exposure beyond the live browsing session.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Configuration File

Create `agent-browser.json` in the project root for persistent settings:

```json
{

• Confidence: 82% confidence
• Finding: Persistent configuration and profile storage can retain browsing data, cookies, history, and other state across runs. In a supposedly restricted browser skill, this increases cross-task contamination risk and can preserve sensitive state longer than users expect.

Static analysis

No suspicious patterns detected.