T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:25- Finding
Privileged execution of a mutable remote shell script
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This browser automation skill is coherent, but it asks for broad control of logged-in Chrome and uses mutable privileged install commands that need careful review before use.
Install only in a trusted, isolated environment. Prefer a dedicated Chrome profile and low-privilege OS account, pin and inspect any setup script or npm package before running it, avoid sudo unless you have reviewed the exact commands, enable domain/action restrictions, and treat saved auth state, recordings, screenshots, and traces as secrets.
SKILL.md:25Privileged execution of a mutable remote shell script
SKILL.md:65Unpinned global installation of a third-party npm package
SKILL.md:137CDP exposes unrestricted control of authenticated personal browser sessions
references/session-management.md:75Authentication tokens are saved in plaintext and may use a predictable shared temporary path
The documentation recommends privileged remote-script execution for install/reinstall/uninstall without a strong, prominent warning about the security implications. Users may be led to execute unaudited code as root, which is especially dangerous because the commands are presented as a normal prerequisite for using the skill.
The skill documents exporting authenticated browser state to auth.json without a clear privacy and credential-handling warning. Session state and cookies can grant account access comparable to passwords, so saving them to disk for later reuse creates a high-value credential artifact that may be copied, exfiltrated, or accidentally committed to source control.
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
ication](#restoring-authentication)
The fastest way to authenticate is to reuse cookies from a Chrome session you are already logged into.
Step 1: Start Chrome with remote debugging
# macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --remote-debugging-port=9222
# Linux
google-chrome --remote-debugging-port=9222
# Windows
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222
Log in to your target site(s) in this Chrome window as you normally would.
Security note:
--remote-debugging-portexposes full browser control on localhost. Any local process can connect and read cookies, execute JS, etc.
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).
Clean up after automation
agent-browser cookies clear
rm -f ./auth-state.json
Use short-lived sessions for CI/CD
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).
echo "*.auth-state.json" >> .gitignore
rm /tmp/auth-state.json
### 4. Timeout Long Sessions
This is effectively the same underlying issue reflected at the manifest level: the skill metadata authorizes npx agent-browser:* without a version pin. In a tool that automates an authenticated browser session, executing an unpinned package materially increases risk because any upstream compromise could gain access to sensitive browsing context and local files reachable by the CLI.
The manifest allows execution of npx agent-browser:* without pinning a specific package version. npx may resolve and execute whatever version is currently published or otherwise available in the environment, which creates a supply-chain risk where a malicious or compromised package update could be run with the skill's granted tool permissions.
The skill documentation instructs users to run a remote script fetched via curl and piped directly to bash, including --install, --reinstall, and --uninstall flows that require sudo and make system-wide changes. This goes beyond browser automation and creates a high-risk remote code execution path where compromise of the upstream repository, network path, or script content can lead to full host takeover.
The skill instructs starting Chrome by running a remote script that kills existing Chrome processes on the host and launches Chrome with a remote debugging port. This broad host-side process manipulation exceeds narrow browser-task scope and can disrupt user activity, terminate unrelated sessions, and expose the browser to automation control if the debug port is reachable or misconfigured.
The startup instructions mention that the script kills existing Chrome processes, but they do not clearly foreground the operational and security consequences such as loss of active work, interruption of other sessions, and unintended exposure of a debug-enabled browser. In an authenticated-browser automation skill, disrupting the user's primary browser context is a meaningful safety issue.
The command reference explicitly documents saving and restoring cookies, storage, and auth state, which enables persistence of authenticated sessions and other sensitive browser data. In this skill's context—automation against websites using existing login sessions—omitting warnings or handling guidance increases the risk of credential/session token leakage, accidental reuse, and insecure storage of authentication material.
Restoring saved browser state allows replay of previously captured authentication context, including cookies and storage-backed session data. In a browser automation skill designed to leverage existing logged-in sessions, this materially increases the risk of account compromise if state files are exfiltrated, shared, or reused across users or environments.
agent-browser state save auth.json # Save cookies, storage, auth state
agent-browser state load auth.json # Restore saved state
This documentation instructs users to capture and save Chrome performance traces but omits any warning that trace files can contain sensitive browsing metadata, URLs, timing data, user interaction details, and potentially information related to authenticated sessions. In the context of a browser automation skill that explicitly uses existing login sessions, saved traces are more likely to expose private application behavior or user activity if they are shared, archived, or stored insecurely.
The authenticated proxy example places username and password directly in the proxy URL without warning that command history, process listings, logs, screenshots, and copied shell snippets can expose secrets. Because this skill is intended for agent-driven browser automation, users may paste these examples into shared or instrumented environments where credential leakage risk is elevated.
The SOCKS5 authentication example similarly includes credentials inline and omits any caution about secret handling. This can lead users to store or reuse proxy credentials insecurely, and in an automation setting those secrets may be captured by telemetry, CI logs, shell history, or shared scripts.
The documentation explicitly recommends rotating proxies 'to avoid rate limiting' for scraping, which normalizes evasive behavior that can be used to bypass service controls. In the context of a browser-automation skill that operates with existing login sessions, this guidance increases the risk of abuse against third-party sites and may facilitate policy or anti-abuse circumvention.
The documentation explicitly instructs saving and reloading authenticated browser state from a JSON file containing cookies and storage data. In the context of a browser automation skill that reuses existing login sessions, this creates a real risk of credential/session token exposure, persistence beyond intended lifetime, and account hijacking if the file is read, copied, or mishandled.
# Restore saved state
agent-browser state load /path/to/auth-state.json
# Continue with authenticated session
The documentation includes concrete examples of entering passwords and payment card data directly through the browser automation tool without any warning, masking guidance, or requirement for explicit user consent. In a skill explicitly designed to operate within a user's existing logged-in browser session, this normalizes high-risk handling of secrets and financial data and can encourage unsafe agent behavior or accidental disclosure via logs, screenshots, command history, or model context.
The documentation encourages recording browser sessions and capturing screenshots but does not warn that videos and images may include sensitive on-screen data such as active login sessions, personal information, tokens, account details, or internal application content. In this skill's context, the browser is explicitly used with existing authenticated sessions, which makes silent retention or sharing of recordings materially riskier than generic browser automation documentation.
This markdown file includes command examples that place usernames and passwords directly on the command line as literal strings. While the file later recommends environment variables in Security Best Practices, these earlier examples omit an immediate warning that hardcoded credentials in commands can expose secrets in shell history, logs, or copied documentation.
The Basic Auth section shows agent-browser set credentials username password without any adjacent warning about handling secrets safely. Because this behavior affects sensitive credentials, the markdown description should disclose the risk of exposing them via terminal history, process inspection, or copied scripts.
The example shows entering a full payment card number into a browser automation flow without any caution that real cardholder data should not be used casually in demos, logs, screenshots, traces, or recordings. Because this tool also supports screenshots, video recording, tracing, and session persistence, the example can normalize unsafe handling of regulated payment data and increase accidental exposure risk.
No suspicious patterns detected.