Is jfrux/browser-use-api safe?
https://github.com/openclaw/skills/tree/main/skills/jfrux/browser-use-api
The jfrux/browser-use-api skill is a straightforward cloud browser automation wrapper with no prompt injection, no malicious code, and a clean installation. The primary risks are operational and privacy-related rather than adversarial: all web browsing tasks are routed through the third-party Browser Use cloud service which retains full visibility into browsed content, and web page content returned by the cloud browser creates an indirect prompt injection attack surface. Canary file reads observed in monitoring are attributable to the audit infrastructure's own setup and teardown phases, not to the skill itself.
Category Scores
Findings (7)
MEDIUM All web tasks transmitted to third-party cloud service -20 ▶
Every task submitted through this skill — including the full task description and any results returned — is sent to api.browser-use.com, a third-party cloud browser service. If the agent uses this skill to browse sensitive resources (banking portals, internal tools, email, authenticated pages), the content of those pages is visible to and potentially logged by the Browser Use service. Users should be aware that this skill routes all browsing through an external SaaS provider.
MEDIUM Indirect prompt injection via cloud browser web content -18 ▶
The cloud browser returns raw page content (including 'output' and 'steps' fields) back to the agent. A malicious web page could embed adversarial LLM instructions in its content (e.g., in a page heading or hidden div), which the agent would then process as returned task output. This is an indirect prompt injection attack vector that bypasses SKILL.md-level scanning.
LOW Shell script executes with no sandboxing or input validation beyond JSON encoding -8 ▶
The browser-use.sh script passes user-provided task text through python3 JSON encoding before embedding it in the curl POST body, which prevents shell injection. However, the task string itself is transmitted verbatim to the remote API with no content filtering. The script has no timeout enforcement beyond the MAX_WAIT polling loop, and no validation of the task content itself.
LOW No cost controls — unbounded API call potential -10 ▶
The script enforces a MAX_WAIT=300s polling timeout but does not limit the number of tasks submitted per session. An agent confused by a prompt injection attack, or a skill chaining scenario, could submit repeated API calls to api.browser-use.com at $0.01-0.05 per task, potentially draining the user's Browser Use credit balance without user awareness.
LOW API key transmitted to external service on every request -5 ▶
BROWSER_USE_API_KEY is required as an environment variable and transmitted as X-Browser-Use-API-Key header on every API call. This is standard practice for API-based skills, but the key is necessarily visible to the Browser Use service and would be exposed in any network capture or proxy logs.
INFO Canary file reads attributable to audit infrastructure, not the skill 0 ▶
Filesystem monitoring detected reads of .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and .config/gcloud/application_default_credentials.json. These reads occurred at audit timestamps 1771936421 (before skill installation at 1771936427) and 1771936439 (post-install integrity check phase). The skill's files contain no code capable of reading these paths. All canary files were confirmed intact by the monitoring system.
INFO Clean installation — only expected GitHub network activity 0 ▶
The installation cloned only from github.com (140.82.121.4:443) using sparse checkout. No unexpected network destinations were contacted during install. The connection diff shows no new persistent listening services after installation. /tmp/monorepo-clone was cleaned up post-install.