Back to skill

Security audit

Arise Browser

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent browser automation tool, but it exposes powerful local browser-control and viewing interfaces with optional or weak authentication.

Install only if you are comfortable running a local browser-control service. Set ARISE_BROWSER_TOKEN before use, keep it bound to localhost, avoid exposing either port through containers or tunnels, do not use your daily browser profile, and prefer a pinned package version or reviewed release.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:24
Finding
Unpinned Global npm Package Installation Creates a Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md:24-28` **Vulnerability Type**: Unpinned third-party dependency installed globally **Risk Level**: Medium ### Vulnerable Code ```markdown ## Install ```bash npm install -g arise-browser ``` ``` ### Technical Analysis The installation instructions retrieve the latest version of `arise-browser` from the npm registry and install it globally. No exact version, lockfile, package integrity hash, or verified artifact is specified. Consequently, the code installed by users may differ from the version that was reviewed. A compromised maintainer account, malicious package release, or upstream registry compromise could introduce arbitrary code. npm installation may also execute package lifecycle scripts with the privileges of the user performing the installation. This finding establishes an unsafe dependency acquisition pattern; it does not establish that the current npm package is malicious. ### Attack Path 1. An attacker compromises the npm package, its publisher account, or its release process. 2. The attacker publishes a malicious version under the legitimate package name. 3. A user follows the documented `npm install -g arise-browser` instruction. 4. npm downloads the attacker-controlled current version without checking it against an audited version or integrity value. 5. Malicious lifecycle or runtime code executes with the installing user's privileges. 6. Because the installation is global, the compromised executable remains available to later sessions and projects. ### Impact Assessment Successful exploitation could provide code execution under the installing user's account. Depending on that account's privileges, the malicious package could access user files, environment variables, browser data, credentials, and network resources. A global installation also increases the affected scope because subsequent invocations from unrelated directories may execute t ...[truncated 23 chars]
Remediation
## Remediation Suggestions - Pin the package to a specifically audited version, for example `arise-browser@X.Y.Z`. - Publish and verify cryptographic integrity information for the approved artifact. - Use a project-local dependency and lockfile rather than a global installation where practical. - Run `npm ci` against a committed lockfile in controlled deployments. - Review package provenance, publisher controls, and release signatures. - Disable npm lifecycle scripts during installation where they are unnecessary, then explicitly perform any required trusted build step. - Execute the browser service in a dedicated, least-privileged account or container. - Establish an update process in which new versions are reviewed before changing the pinned version.

T09 · Insecure Skill Coding Practices

Error
Location
TRUST.md:12
Finding
Browser-Control API Authentication Is Optional Despite Sensitive Endpoints## Vulnerability Details **File Location**: `TRUST.md:12-16`, `TRUST.md:29-34`, `references/api.md:3`, `references/api.md:94-99`, `references/api.md:136-143`, and `SKILL.md:31-34` **Vulnerability Type**: Insecure default access control for a privileged local API **Risk Level**: High ### Vulnerable Configuration and API Surface `SKILL.md:31-34` starts the service without configuring authentication: ```markdown ## Start ```bash arise-browser start --virtual-display # → "Server ready on port 16473" ``` ``` `TRUST.md:12-16` describes authentication as optional: ```markdown ### Network - Binds to 127.0.0.1 by default (local only) - Optional Bearer token authentication (`ARISE_BROWSER_TOKEN`) - No TLS built-in (use reverse proxy for remote access) ``` `TRUST.md:29-34` acknowledges the need for additional protection: ```markdown ## Recommendations 1. **Always set `ARISE_BROWSER_TOKEN`** when the API is accessible to other processes 2. **Never use `--profile` with your daily browser profile** — create a dedicated one 3. **Never bind to 0.0.0.0** without token authentication 4. **Review `/evaluate` usage** — it executes arbitrary JavaScript in the page context ``` The sensitive endpoints include arbitrary page-context JavaScript execution: ```markdown ### POST /evaluate Execute JavaScript in page context. Body: ```json {"expression": "document.title", "tabId": "tab-001", "owner": "agent-1"} ``` ``` They also include unrestricted cookie retrieval and modification: ```markdown ## Cookies ### GET /cookies Get all cookies. ### POST /cookies Set cookies. Body: ```json {"cookies": [{"name": "session", "value": "abc123", "url": "https://example.com"}]} ``` ``` ### Technical Analysis Binding to `127.0.0.1` limits remote network access but does not establish an authorization boundary between processes on the same host. Authentication is optional, and the document ...[truncated 2461 chars]
Remediation
## Remediation Suggestions - Require authentication by default and refuse to start sensitive API routes without a generated or explicitly supplied token. - Generate a cryptographically random, per-installation or per-session token instead of relying on operators to configure one. - Ensure every endpoint, including health, tabs, cookies, screenshots, recordings, and evaluation, has an explicit access-control policy. - Disable `/evaluate`, cookie access, profile mode, recording export, and other high-risk capabilities by default; require explicit opt-in for each. - Keep the service bound to loopback and reject non-loopback binding unless authentication and transport security are configured. - Use TLS through a correctly configured local proxy when traffic can cross an untrusted network. - Apply origin and request protections where browser-based access to the local API is possible. - Run the service under a dedicated least-privileged operating-system account and isolate it from unrelated local processes where feasible. - Use a fresh, dedicated browser profile without personal credentials or daily browsing data. - Add rate limiting, security event logging, token rotation, and short token lifetimes. - Update the documented startup procedure so secure authentication is part of the default command rather than an optional recommendation.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:39
Finding
Live Browser Interface Uses a Publicly Documented Fixed Password## Vulnerability Details **File Location**: `SKILL.md:39` **Vulnerability Type**: Hardcoded and predictable authentication credential **Risk Level**: Medium ### Vulnerable Code ```markdown **Watch the browser:** Open `http://localhost:6090` in your browser, password: `neko` ``` ### Technical Analysis The live browser interface uses the fixed password `neko`, which is disclosed in the project documentation. A shared, predictable password provides little protection against any party that can reach the interface. Loopback-only accessibility may reduce exposure, but it does not protect against untrusted local processes or users. The interface may also become remotely reachable through container port publication, network forwarding, reverse proxies, or configuration changes. Because the same credential is documented for all installations, attackers do not need to guess or steal it. The reviewed files do not specify the exact permissions available through the live-view interface. Therefore, direct interactive control through that interface cannot be confirmed from the available evidence. At minimum, the documentation identifies it as a mechanism to watch the browser, creating a potential confidentiality exposure. ### Attack Path 1. A user starts the virtual-display browser service. 2. Port 6090 is reachable by another local user or process, or is unintentionally exposed through forwarding or container/network configuration. 3. The attacker opens `http://<reachable-host>:6090`. 4. The attacker enters the publicly documented password `neko`. 5. The attacker observes the browser display and any sensitive information shown in active pages. 6. If the deployed interface permits input in addition to viewing, the attacker may also interact with the browser; that capability is deployment-dependent and is not confirmed by the reviewed documentation. ### Impact Assessment Confirmed potential impact is unauthorized observati ...[truncated 371 chars]
Remediation
## Remediation Suggestions - Remove the universal default password. - Generate a unique, cryptographically random password or access token on every installation or service start. - Deliver the generated credential through a restricted local channel and avoid printing it to shared logs. - Bind the live-view interface strictly to loopback by default. - Require explicit authenticated configuration before allowing non-loopback exposure. - Place remotely accessed deployments behind TLS and strong authentication. - Disable the live-view interface unless it is explicitly requested. - Where supported, separate view-only and interactive permissions and default to view-only access. - Add session expiration, credential rotation, connection auditing, and failed-login rate limiting.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill explicitly exposes a live browser view at `http://localhost:6090` and even publishes the password (`neko`) in the skill instructions, but it does not clearly warn that this grants visual access to the active browser session. In agent/browser automation contexts, the browser may display sensitive data such as authenticated sessions, tokens, personal information, or internal pages, so undocumented remote viewing meaningfully increases exposure risk.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The API reference exposes powerful browser-state endpoints for reading and mutating cookies and exporting recorded workflows, but the documentation shows no authentication, authorization, consent, or warning requirements. In the context of an agent-controlled browser with persistent sessions, these endpoints can enable theft of session cookies, account takeover, replay of authenticated activity, and exfiltration of sensitive browsing behavior if any local process or connected agent can access the service.

Static analysis

No suspicious patterns detected.