T05 · Unauthorized Access and Privilege Escalation
- Location
references/loop.md:48- Finding
Browser-specific tool permission exposes arbitrary operating-system command execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a powerful browser automation package, but it exposes broad browser, credential/session, shell, persistence, and skill-management capabilities that need careful review before use.
Install only if you trust the Browser4 CLI and need this full power. Use a dedicated automation browser profile, avoid importing your everyday browser profile, avoid state-save/profile-import for sensitive accounts, do not use loop --shell unless you intentionally want local shell execution, prefer localhost or authenticated tunnels over remote HTTP endpoints, review external installer scripts, and clean up auth-state files, profile copies, HARs, logs, and caches after use.
references/loop.md:48Browser-specific tool permission exposes arbitrary operating-system command execution
references/storage-state.md:25Live authentication tokens are exported to unencrypted JSON files
references/attach.md:82Remote browser backend may be controlled over unauthenticated plaintext HTTP
The documented profile-import capability explicitly supports importing passwords, cookies, and other browser state from local Chrome/Edge/Safari profiles. In the context of an agent skill, this is credential-access functionality that could be abused to extract secrets or hijack authenticated sessions beyond the user's intended browser task.
| `network requests`, `network request <id>`, `network har start`, `network har stop`, `network route`, `network unroute` | Network request inspection, HAR recording & request routing | Inspect what the page loaded (XHR/fetch/status/headers), debug API calls, record a `.har` file (Chrome DevTools importable), or mock/abort matching requests (Fetch interception). `network requests --filter api --status 2xx`; `network har start --content text` then `network har stop ./capture.har`; `network route "**/api/users" --body '{"users":[]}'` | [network.md](references/network.md) |
| `profiler start`, `profiler stop` | V8 CPU profiling via CDP | Profile page interactions and save `.cpuprofile` (Chrome DevTools / speedscope compatible) | — |
| `profiles list` | List browser profile directories | See what profiles exist under `~/.browser4/browser/chrome` before `open --profile` | — |
| `profile-import` | Import bookmarks/history/passwords/cookies/extensions from system Chrome/Edge/Safari (requires the browser4-profile-import plugin) | `profile-import --list-sources` to discover browsers; `profile-import --source chrome --data bookmarks,cookies` copies a whole profile snapshot to `~/.browser4/imports/`; `--into prototype|default` seeds a managed profile dir; then `open --profile <dir>` mounts it | [browser-state-import.md](references/browser-state-import.md) |
| `config` | Persistent CLI defaults (server, timeout, proxy, session) | Set default server URL, timeout, proxy, or session name | [config.md](references/config.md) |
| `status`, `doctor`, `doctor log`, `doctor metrics`, `doctor status` | Server health & diagnostics | `doctor status` prints the aggregated status report (health, build, runtime, LLM, sessions, browsers, swarm, plugins, skills, metrics, logs) in layers: summary by default, `--verbose` for full detail, `--section <name>` for one report, `--json` for machine-readable output. `status` prints the web status panel URL (`http://<server>:8182/status`) — a live dashbo
...[truncated 24 chars]
The skill claims a web automation/extraction purpose but documents profile import from local browsers, including sensitive state such as cookies and passwords. This is a substantial hidden capability increase because it can access credentials and authenticated browser state unrelated to ordinary website interaction.
Importing profiles from system browsers is context-inappropriate for a general browser automation skill because it reaches into local user data stores rather than interacting with a target website. In an agent setting, that creates a path to harvest or reuse existing authenticated sessions and other secrets under the guise of routine automation.
The YARA hit is substantiated by the explicit browser profile import functionality for cookies, passwords, and extensions from system browsers. In a browser automation skill, that capability materially resembles information-stealer behavior because it can collect or reuse sensitive local browser data unrelated to the immediate browsing task.
work.md](references/network.md) |
| `profiler start`, `profiler stop` | V8 CPU profiling via CDP | Profile page interactions and save `.cpuprofile` (Chrome DevTools / speedscope compatible) | — |
| `profiles list` | List browser profile directories | See what profiles exist under `~/.browser4/browser/chrome` before `open --profile` | — |
| `profile-import` | Import bookmarks/history/passwords/cookies/extensions from system Chrome/Edge/Safari (requires the browser4-profile-import plugin) | `profile-import --list-sources` to discover browsers; `profile-import --source chrome --data bookmarks,cookies` copies a whole profile snapshot to `~/.browser4/imports/`; `--into prototype|default` seeds a managed profile dir; then `open --profile <dir>` mounts it | [browser-state-import.md](references/browser-state-import.md) |
| `config` | Persistent CLI defaults (server, timeout, proxy, session) | Set default server URL, timeout, proxy, or session name | [config.md](references/config.md) |
| `s
The YARA hit is not merely lexical noise here: the file explicitly describes exporting and reusing cookies, localStorage, and even entire system browser profiles. Those are classic information-stealer targets because they can be used to hijack authenticated sessions and extract sensitive user data, especially when sourced from the user's primary browser.
browser4-cli state-save my-state.json # save the current session's web state (cookies + localStorage)
browser4-cli open --fresh https://example.com # launch a Browser4-managed browser
browser4-cli state-load my-state.json # restore cookies + localStorage into it
The documented capability allows copying sensitive local browser profile data from the user's system into another browser context, which can expose live sessions, persistent authentication material, browsing history, and installed extension data. In an agent setting, this is especially dangerous because it crosses the boundary from web automation into local sensitive-data collection without strong necessity or containment.
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).
Notes:
- Unlike local keys, these are not stored in `config.json` — they route to the running server's unified REST config interface (`GET/PUT/DELETE /api/config/{key}`, `GET /api/config` to list all), so the server must be up.
- The override is runtime-only — lost on server restart, which falls back to the key's value in the server configuration.
- Accepted values: a non-negative integer, `0`, or `unlimited` (= 0, disables enforcement). Unknown keys and invalid values are rejected server-side with 404/400.
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).
rm -rf ./snapshots/baseline
cp -r ./snapshots/current ./snapshots/baseline
git add ./snapshots/baseline
git commit -m "chore: update HTML snapshot baselines"
--shell explicitly executes arbitrary OS shell commands via sh -c or cmd /C, which is a direct arbitrary command execution capability. In an agent skill presented as browser automation, this can be abused to run destructive local commands, access local files, install tooling, or pivot beyond intended browser-only operations.
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.
When a loop finishes normally (count reached or timeout expired), the
persisted state is automatically cleared. Use --stop to clear state
before normal completion if needed.
Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.
# Edit SKILL.md in your skill directory, then:
browser4-cli skill-reload my-skill
browser4-cli skill-info my-skill # verify changes took effect
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.
- Never commit storage state files containing auth tokens
- Add `*.auth-state.json` to `.gitignore`
- Delete state files after automation completes
- Use environment variables for sensitive data
The skill metadata presents this as a browser automation/testing tool, but the documented command set also includes backend skill-management and agent-instruction management operations. That scope expansion can let a caller modify installed skills or refresh agent instructions through a capability that appears, from its manifest, to only browse and extract web content.
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.
> **Warning:** `htmlsnapshot` captures the **current live DOM** at capture time. Re-capture (run `htmlsnapshot`) after any interaction or navigation to reflect JS updates — a previously captured snapshot is stale only if you do not re-capture. The auto-captured snapshot after `goto` is an earlier capture and does not include later interactions. For one-off live reads without a capture step, use `eval`. The `htmlsnapshot inspect` command reads the stored snapshot — re-capture first to inspect the updated DOM.
> **Warning — backend startup fails in sandboxed/restricted environments:** The Browser4 backend (Spring Boot/JVM) writes its log files to a `logs/` directory inside the runtime bundle — `BROWSER4_RUNTIME_DIR` (default `%APPDATA%/browser4` on Windows, `~/.local/share/browser4` on Linux). In sandboxes that only allow writes to the workspace, this write is denied and the server never becomes ready: `goto`/`open` hang until the startup timeout with `FileNotFoundException … Access denied` (or `拒绝访问`) in the startup log.
>
> **Diagnose:** the failed command prints a startup-log path under `🧾 Details` — look for a `logs\*.log` (or `logs/*.log`) write failure there.
>
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.
> **Warning:** `htmlsnapshot` captures the **current live DOM** at capture time. Re-capture (run `htmlsnapshot`) after any interaction or navigation to reflect JS updates — a previously captured snapshot is stale only if you do not re-capture. The auto-captured snapshot after `goto` is an earlier capture and does not include later interactions. For one-off live reads without a capture step, use `eval`. The `htmlsnapshot inspect` command reads the stored snapshot — re-capture first to inspect the updated DOM.
> **Warning — backend startup fails in sandboxed/restricted environments:** The Browser4 backend (Spring Boot/JVM) writes its log files to a `logs/` directory inside the runtime bundle — `BROWSER4_RUNTIME_DIR` (default `%APPDATA%/browser4` on Windows, `~/.local/share/browser4` on Linux). In sandboxes that only allow writes to the workspace, this write is denied and the server never becomes ready: `goto`/`open` hang until the startup timeout with `FileNotFoundException ... Access denied` (or `拒绝访问`) in the startup log.
>
> **Diagnose:** the failed command prints a startup-log path under `🧾 Details` — look for a `logs\*.log` (or `logs/*.log`) write failure there.
>
The installation section points users to remote installer scripts without any warning about verifying provenance, integrity, or the risks of executing downloaded code. That can normalize unsafe install behavior and expose users to supply-chain compromise if the hosting location or script content is tampered with.
The documentation clearly states that natural-language tasks are sent to a backend server and processed by an LLM, but it does not prominently warn users that submitted page content, prompts, extracted data, and possibly sensitive workflow context may be transmitted to third-party model providers. In a browser automation skill, this is especially important because users may run tasks against authenticated sessions, internal apps, or pages containing personal or confidential data, creating a real privacy and data-handling risk through omission.
The documentation encourages attaching to an already-running browser and reusing authenticated state, but it does not clearly warn that the CLI will gain visibility and control over existing tabs, cookies, session state, and page content. In the context of a browser automation skill, that omission can lead users to expose sensitive authenticated data to automation without understanding the security boundary they are crossing.
The instructions tell users to enable remote debugging and connect over CDP, but omit a security warning that a reachable debugging endpoint can allow full browser control by other local processes or remote hosts if exposed beyond localhost. Because CDP commonly permits navigation, script execution, and data extraction, accidental exposure of the endpoint can result in compromise of authenticated browser sessions.
The auto-approval token feature allows unattended attachment, but the documentation does not warn that storing the token in an environment variable may let other local processes or users reuse it to connect without manual approval. In a browser-attachment workflow, that can weaken the intended consent step and enable unauthorized access to the active browser session.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
$env:BROWSER4_EXTENSION_TOKEN = ""
When the env var is set, the CLI appends `&token=...` to the connect page URL — the extension validates the token against its stored copy and auto-approves the connection. If you regenerate the token from the extension UI, update your env var to match.
**Troubleshooting:**
- Navigating to `chrome://` internal pages (e.g., `chrome://version/`) may disconnect the extension WebSocket. If the session goes stale, run `close` first, then re-attach with `attach --extension`.
This documentation materially expands a browser automation skill into importing full local browser profiles, including highly sensitive artifacts such as cookies, history, extensions, and potentially passwords. Even though presented as a convenience feature, enabling profile copying from a user's daily browser creates a direct pathway for credential/session theft and lateral access to authenticated services.
The form-discovery and form-filling examples explicitly target sensitive workflows such as tax filing, insurance applications, and loan origination, and they show extracting full form HTML and filling personal fields without any warning about handling PII or secrets. In an automation skill, that omission can normalize unsafe collection, logging, or transmission of sensitive user data to snapshots, shell variables, and LLMs, increasing the risk of privacy breaches and regulatory violations.
This markdown file instructs users to query competitor product pages repeatedly and even set up cron-based monitoring, but it does not include any user-facing warning about respecting robots.txt, terms of service, rate limits, or legal restrictions around competitive monitoring. Because the document operationalizes recurring access to third-party sites, a brief disclosure about these risks would materially improve user safety and compliance awareness.
The audit-trail export example advises storing exported HTML snapshots in a versioned S3 bucket without warning that snapshots can contain secrets, session data, personal information, or regulated content rendered in the page. Archiving such data into external or long-retention storage can expand exposure, violate data-handling requirements, and create a durable leak if the bucket or downstream access controls are misconfigured.