browser-use-terminal

Likely benign in stated purpose, but high-impact by design. The main risks are autonomous web actions, use of stored credentials/session state, and prompt-injection exposure from arbitrary web content and transitive site playbooks; overall this is a powerful browser agent skill that should be treated as medium-to-high risk rather than malware.

This fragment does not itself contain explicit malicious payloads (no obvious credential theft, exfiltration logic, or obfuscation). The main security concern is supply-chain exposure from the installer bootstrap method (executing a remotely fetched script via curl ... | sh without visible integrity checks) combined with the tool’s powerful capability to automate an authenticated browser session (local remote debugging) and to operate via a cloud service using an API key. Review/verify the installer integrity and inspect the installed package/daemon behavior to determine whether malicious activity is present in code not shown here.

No direct evidence of stealthy malware, credential theft, or external exfiltration is present in this fragment: all network activity is confined to localhost (CDP readiness and CDP-driven automation), and the test content uses data: URLs. However, the script has meaningful security risks typical of automation harnesses: it can execute an arbitrary binary if CHROME_PATH is attacker-controlled, and it performs rm -rf on a directory path derived from LLM_BROWSER_LIVE_STATE_DIR (potential for unintended deletion). The overall supply-chain risk comes primarily from indirect trust in the invoked automation tooling and from configuration-driven impact, rather than from malicious logic within this snippet itself.