Browser Vps Setup Skill

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:59 PM UTC
• Version: 1.0.0

Overview

The skill matches its stated VPS browser setup purpose, but it needs Review because it combines root-level setup, disabled Chrome sandboxing, unsafe proxy credential handling, and broad firewall changes.

Use this only on an isolated VPS you can rebuild. Before installing, remove Chrome --no-sandbox/noSandbox=true, run the browser stack as an unprivileged user, explicitly bind noVNC/websockify/CDP to loopback, avoid inline proxy credentials, and review firewall changes manually instead of applying the provided UFW block unchanged.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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 (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:51
• Finding: Chrome Runs Without Its Security Sandbox<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 51-54 and 148-153 **Vulnerability Type**: Browser sandbox disabled in a privileged deployment **Risk Level**: High ### Vulnerable Code ```bash DISPLAY=:99 google-chrome-stable --no-sandbox --disable-gpu \ --remote-debugging-port=18800 \ --user-data-dir=~/.openclaw/browser/openclaw/user-data \ --window-size=1280,800 & ``` The proxy-enabled restart repeats the unsafe option: ```bash DISPLAY=:99 google-chrome-stable --no-sandbox --disable-gpu \ --remote-debugging-port=18800 \ --user-data-dir=~/.openclaw/browser/openclaw/user-data \ --window-size=1280,800 \ --proxy-server="http://127.0.0.1:18801" & ``` ### Technical Analysis The `--no-sandbox` option disables Chrome's operating-system-level process isolation. The Skill requires `sudo/root` access and demonstrates an SSH connection using `root@YOUR_VPS_IP`. If the browser stack is consequently launched as root, renderer processes handling untrusted websites can operate without the primary containment boundary intended to limit browser exploits. Disabling the sandbox is not inherently required to provide remote browser automation, noVNC access, or an authenticated proxy. Chrome can normally run with its sandbox enabled under a dedicated, unprivileged account. The instruction therefore exceeds the minimum privileges necessary for the declared functionality. The remote debugging service also controls the same browser that processes untrusted content. Although the documented invocation does not explicitly expose the debugging service on every interface, disabling the browser sandbox substantially raises the consequences of any browser, extension, or debugging-channel compromise. ### Attack Path 1. The administrator follows the Skill while logged in as root or otherwise starts Chrome with elevated privileges. 2. Chrome starts with `--no-sandbox`. 3. The automated browser visits an attacker-controlled or compromised website. 4. ...[truncated 943 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Create a dedicated, unprivileged operating-system account for the browser stack. 2. Remove `--no-sandbox` from both Chrome invocations. 3. Ensure Chrome's sandbox package and kernel features are available and correctly configured. 4. Give the browser account ownership only of its dedicated profile and runtime directories. 5. Do not start Chrome, Xvfb, x11vnc, or the proxy bridge as root. 6. Keep CDP bound to loopback explicitly where supported and restrict access through SSH tunneling or equivalent authenticated transport. 7. If a particular environment cannot support the Chrome sandbox, fail safely and explain the security limitation instead of disabling it by default. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:95
• Finding: Authenticated Proxy Credentials Are Embedded in Process Arguments and Transmitted Using Plaintext Basic Authentication<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 95-116 **Vulnerability Type**: Insecure secret handling and plaintext credential transmission **Risk Level**: High ### Vulnerable Code ```bash python3 -c " import socket, threading, base64, select UPSTREAM_HOST = 'PROXY_IP' # e.g. 87.236.22.82 UPSTREAM_PORT = PROXY_PORT # e.g. 19423 USERNAME = 'PROXY_USER' PASSWORD = 'PROXY_PASS' LOCAL_PORT = 18801 auth = base64.b64encode(f'{USERNAME}:{PASSWORD}'.encode()).decode() def handle(client): try: data = b'' while b'\r\n\r\n' not in data: data += client.recv(4096) upstream = socket.create_connection((UPSTREAM_HOST, UPSTREAM_PORT)) if b'Proxy-Authorization' not in data: data = data.replace(b'\r\n\r\n', f'\r\nProxy-Authorization: Basic {auth}\r\n\r\n'.encode(), 1) upstream.sendall(data) ``` ### Technical Analysis The instructions encourage users to replace `PROXY_USER` and `PROXY_PASS` directly inside a `python3 -c` command. The resulting credentials become part of the process command line and may also be retained in shell history, terminal logs, automation transcripts, or agent execution records. Depending on host configuration, other local users may inspect the command line through process-monitoring tools or `/proc`. The expression at line 107 applies Base64 encoding to `username:password`. Base64 is reversible encoding, not encryption. The pre-scan warning that this line directly outputs credentials to stdout is not supported by the code: `auth` is not printed. Nevertheless, it is inserted into the `Proxy-Authorization` header at line 116. The bridge connects to the upstream proxy using a plain TCP socket: ```python upstream = socket.create_connection((UPSTREAM_HOST, UPSTREAM_PORT)) ``` It then sends a Basic authorization header over that connection without TLS. Any party able to observe the network path can recover the Base64 value, decode it, and obtain the ...[truncated 1698 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not place secrets directly in an inline `python3 -c` command. 2. Load credentials at runtime from a root- or service-account-owned file with mode `0600`, a protected secret manager, or another non-logged secret source. 3. Avoid passing credentials through command-line arguments. If environment variables are used, account for environments where process environments can be inspected. 4. Use a TLS-protected upstream proxy connection, such as an HTTPS proxy supported by a maintained proxy client or bridge. 5. Prefer a mature, reviewed proxy client instead of a custom inline forwarding implementation. 6. Rotate any proxy credentials previously used with this command if command history, process metadata, or execution logs may have been accessible. 7. Replace broad `except: pass` handlers with narrow exception handling and sanitized error logging that never records authorization headers or passwords. 8. Document that Base64 does not protect the credential and must not be treated as encryption. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:160
• Finding: Skill Replaces Host-Wide Firewall Policy and Opens Unnecessary Inbound Ports<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 160-167 **Vulnerability Type**: Excessive system-level permissions and unsafe firewall reconfiguration **Risk Level**: Medium ### Vulnerable Code ```bash ufw default deny incoming ufw default allow outgoing ufw allow 22/tcp ufw allow 80/tcp ufw allow 443/tcp ufw --force enable ``` ### Technical Analysis The declared browser stack binds noVNC, VNC, and the proxy bridge to loopback, and remote visual access is provided through an SSH tunnel. The setup therefore does not require inbound ports 80 or 443. Opening those ports is unrelated to the Skill's declared functionality and exceeds least privilege. The commands also replace host-wide firewall defaults and force-enable UFW without confirming the existing network policy. This can interfere with previously configured firewall tooling, containers, management agents, services, or SSH running on a nonstandard port. Because the change is made at the host level, its scope is substantially broader than the browser stack. Opening ports 80 and 443 does not create a vulnerability by itself when nothing is listening. However, it permits any current or future service bound to those ports to become remotely reachable, potentially contrary to the administrator's intended policy. ### Attack Path **Unexpected exposure path:** 1. The administrator applies the recommended firewall commands. 2. UFW creates public inbound allowances for TCP ports 80 and 443. 3. An existing or subsequently installed service listens on one of those ports. 4. The service becomes reachable from untrusted networks without an explicit browser-related need. 5. An attacker scans the VPS, reaches the service, and exploits any authentication weakness or software vulnerability it contains. **Administrative lockout path:** 1. The VPS uses SSH on a port other than TCP 22 or relies on additional management ports. 2. The Skill changes the default incoming policy to deny and force-ena ...[truncated 645 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the inbound allowances for ports 80 and 443 because the documented browser stack does not require them. 2. Do not force-enable or replace host-wide firewall policy as part of the browser setup. 3. Present firewall changes as optional, individually reviewed commands requiring explicit administrator confirmation. 4. Inspect and preserve the current firewall configuration before proposing changes. 5. Detect the actual SSH listening port and source restrictions rather than assuming TCP 22. 6. Keep VNC, noVNC, CDP, and the local proxy bound to loopback, and access them only through an authenticated SSH tunnel. 7. If firewall automation is retained, create narrowly scoped rules, provide rollback instructions, and verify continued administrative access before ending the existing session. ]]>

SkillSpector

Vulnerability Patterns

• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

```bash
# Clean stale locks
rm -f /tmp/.X99-lock ~/.openclaw/browser/openclaw/user-data/SingletonLock 2>/dev/null

# Virtual display
Xvfb :99 -screen 0 1280x800x24 &

• 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).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

```bash
pkill -9 chrome
rm -f ~/.openclaw/browser/openclaw/user-data/SingletonLock
DISPLAY=:99 google-chrome-stable --no-sandbox --disable-gpu \
  --remote-debugging-port=18800 \
  --user-data-dir=~/.openclaw/browser/openclaw/user-data \

• 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).

Static analysis

No suspicious patterns detected.