xvfb-chrome

• Outcome: Review
• Latest audit: Sep 11, 2026 · 12:07 AM UTC
• Version: 1.0.2

Overview

The skill is a coherent Chrome/Xvfb automation guide, but it uses unsafe browser and process-management defaults that deserve review before installation.

Install only if you are comfortable managing Chrome automation security yourself. Run it under a dedicated unprivileged account, avoid personal or production-authenticated browser profiles, bind DevTools explicitly to 127.0.0.1, use a unique temporary profile directory, avoid --no-sandbox unless your isolated environment truly requires it, and replace killall/pkill examples with PID-scoped cleanup.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:20
• Finding: Chrome Is Launched with Its Security Sandbox Disabled<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 20-31; the unsafe option also recurs at lines 44-46, 76-78, 128, 131, and 157-159 **Vulnerability Type**: Unsafe browser security configuration **Risk Level**: Medium ### Vulnerable Code ```bash ### 1. Headless mode (general automation) google-chrome --headless=new --no-sandbox --disable-gpu --user-data-dir=/tmp/chrome-data ### 2. Headed mode + Xvfb + DevTools (recommended for MCP users) xvfb-run -a google-chrome --no-sandbox \ --disable-gpu --remote-debugging-port=9222 \ --user-data-dir=/tmp/chrome-profile ``` The documentation also characterizes `--no-sandbox` as mandatory for servers: ```text | `--no-sandbox` | Skip the sandbox (required on servers) | ``` ### Technical Analysis The instructions consistently launch Chrome with `--no-sandbox`, disabling a principal browser isolation boundary. Chrome normally uses process sandboxing to restrict renderer and other low-privilege browser processes after they process untrusted web content. Browser automation routinely opens externally controlled pages. If such a page exploits a renderer or browser-component vulnerability, disabling the sandbox can make it substantially easier for the exploit to access resources available to the Chrome operating-system account. Presenting this option as universally required on servers encourages an unsafe default even where the Chrome sandbox is supported. This finding does not by itself provide code execution; exploitation requires a separate browser vulnerability or another method of executing code in a normally sandboxed Chrome process. ### Attack Path 1. An operator launches Chrome using one of the documented commands containing `--no-sandbox`. 2. The automation session navigates to an attacker-controlled or compromised website. 3. The page exploits a suitable Chrome renderer or browser-component vulnerability. 4. Because the normal Chrome sandbox is disabled, the malicious process has fewe ...[truncated 667 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove `--no-sandbox` from all default command examples. - Run Chrome as a dedicated, unprivileged operating-system user with its standard sandbox enabled. - Do not claim that disabling the sandbox is universally required on servers. - If a narrowly defined container environment cannot support Chrome's sandbox, document the exception rather than making it the default. - For exceptional unsandboxed deployments, use a hardened container or virtual machine with: - No host filesystem mounts beyond strictly required paths. - A read-only root filesystem where practical. - Dropped Linux capabilities. - `no-new-privileges`. - Seccomp and mandatory access-control profiles. - Restricted outbound and local-network access. - No sensitive credentials in the process environment. - Never run unsandboxed Chrome as `root`. - Use a temporary, minimally permissioned profile and delete it securely after the session. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:27
• Finding: Unauthenticated Chrome DevTools Control Is Enabled for a Reusable Browser Profile<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 27-36; equivalent commands recur at lines 44-46, 76-82, and 157-159 **Vulnerability Type**: Exposed privileged browser-control interface **Risk Level**: Medium ### Vulnerable Code ```bash ### 2. Headed + xvfb + DevTools (recommended for MCP users) xvfb-run -a google-chrome --no-sandbox \ --disable-gpu --remote-debugging-port=9222 \ --user-data-dir=/tmp/chrome-profile ``` The documented endpoint is: ```text DevTools listens at `ws://127.0.0.1:9222/devtools/browser/xxx` ``` A later example confirms direct access to the endpoint: ```bash curl -s http://127.0.0.1:9222/json/version ``` ### Technical Analysis Chrome DevTools provides extensive control over the browser, including page navigation, JavaScript execution, DOM inspection, screenshots, and access to browser-visible network activity. The interface does not provide ordinary application-level authentication. The commands enable a fixed DevTools TCP port but do not explicitly set `--remote-debugging-address=127.0.0.1`. Although the documentation describes a loopback URL and Chrome commonly restricts this listener by default, the secure binding is left implicit rather than enforced by the example. The use of the fixed, reusable directory `/tmp/chrome-profile` can also preserve browser state between runs. A process capable of connecting to the DevTools endpoint while Chrome is active could control tabs and inspect information available within authenticated browser sessions. Exploitation requires network or local-process access to the debugging endpoint; the documentation does not itself expose the port publicly. ### Attack Path 1. An operator launches Chrome with `--remote-debugging-port=9222` and the reusable `/tmp/chrome-profile`. 2. The browser opens authenticated or otherwise sensitive pages. 3. An untrusted local process, compromised co-tenant, container peer, or remotely positioned attacker with access to port 9222 con ...[truncated 1188 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Explicitly bind the debugging listener to loopback: ```bash --remote-debugging-address=127.0.0.1 \ --remote-debugging-port=9222 ``` - Enforce host firewall rules preventing access to port 9222 from external interfaces, containers, and untrusted local network namespaces. - Do not expose the endpoint through public port forwarding, reverse proxies, or broadly accessible SSH tunnels. - Run the automation browser under a dedicated, unprivileged account so unrelated local users cannot interact with its runtime resources. - Replace the fixed profile with a unique temporary directory created with restrictive permissions, for example through `mktemp -d`, and remove it after use. - Avoid placing unrelated personal, administrative, or production-authenticated sessions in the automation profile. - Prefer a Unix-domain-socket proxy or authenticated local broker where the automation architecture permits it. - Start the debugging endpoint only when MCP control is needed and terminate it immediately afterward. - Monitor the host for unexpected connections to the DevTools port. ]]>

T09 · Insecure Skill Coding Practices

Note

• Location: SKILL.md:146
• Finding: Global Process-Kill Commands Can Terminate Unrelated Chrome and Xvfb Sessions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 146-155 **Vulnerability Type**: Overbroad process management **Risk Level**: Low ### Vulnerable Code ```bash # View currently running Xvfb processes ps aux | grep Xvfb | grep -v grep # Kill all Chrome processes killall chrome # Kill all Xvfb processes pkill Xvfb # Restart Chrome (bound to :99) killall chrome 2>/dev/null ``` ### Technical Analysis `killall chrome` and `pkill Xvfb` select processes globally by executable or process name. They do not verify that a process was created by this Skill, belongs to the intended automation session, uses the expected profile, or is attached to the relevant display. On a shared host—or under an account running multiple browser workloads—the commands can terminate unrelated browser and virtual-display sessions. This violates least-scope process management and creates an avoidable availability risk. The practical scope remains constrained by operating-system permissions: an unprivileged user ordinarily cannot signal processes owned by other users. However, all matching processes owned by the same account may be terminated. Running these commands with elevated privileges can expand the effect to system-wide matching processes. ### Attack Path 1. Multiple Chrome or Xvfb sessions run on the same host or under the same service account. 2. An operator follows the documented “kill all” or restart procedure. 3. `killall` or `pkill` matches every accessible process with the corresponding name. 4. The operating system sends termination signals to both the intended session and unrelated sessions. 5. Other automation jobs, interactive browser sessions, screenshots, or in-progress transactions are interrupted. ### Impact Assessment The primary impact is denial of service and loss of in-progress work. Affected scope includes all matching processes that the invoking account is permitted to signal. Under a shared service account, this can disrupt parallel ...[truncated 362 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Capture the PID of each process when it is started: ```bash xvfb-run -a google-chrome ... & chrome_pid=$! printf '%s\n' "$chrome_pid" > "$runtime_dir/chrome.pid" ``` - Store PID files in a private runtime directory owned by the dedicated service account. - Before signaling a recorded PID: - Confirm that it still exists. - Confirm process ownership. - Validate `/proc/<pid>/cmdline` against the expected executable, profile, debugging port, and display. - Terminate only the validated PID, initially with `SIGTERM`, and use `SIGKILL` only after a bounded timeout. - Use a service manager such as systemd to place each automation instance in a dedicated service or control group and stop only that unit. - Avoid `killall`, unrestricted `pkill`, and broad regular-expression process matching in operational instructions. - Run separate automation workloads under separate unprivileged accounts where process isolation is required. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Natural-Language Policy Violations

Medium

• Confidence: 94% confidence
• Finding: The natural-language instructions and descriptions in this skill are presented in Chinese only, which can amount to a language-policy violation when no user opt-in or alternative language is offered. The file does not state that the skill is intentionally limited to Chinese-speaking users or a specific region.

Missing User Warnings

Low

• Confidence: 80% confidence
• Finding: This markdown file includes an example command that saves a screenshot to `/root/screenshot.png`, which affects user/system data by creating or overwriting a file. The surrounding skill description does not provide any warning about where files are written or the need to choose a safe output path.

Context-Inappropriate Capability

Low

• Confidence: 76% confidence
• Finding: The manifest describes running Chrome with Xvfb for browser automation and DevTools MCP connectivity. The guidance to kill all Chrome processes and all Xvfb processes system-wide (`killall chrome`, `pkill Xvfb`) is a broader host-management capability than is necessary for that purpose and could impact unrelated workloads on the server.

Static analysis

No suspicious patterns detected.