Back to skill

Security audit

Selenium Automation

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent for Selenium browser automation, but its default Chrome setup disables the browser sandbox without a clear opt-in or warning.

Install only in an isolated, non-privileged environment. Prefer pinning Selenium and remove --no-sandbox unless you specifically need it for a disposable container and understand the reduced browser isolation.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:14
Finding
Unpinned Selenium Dependency Creates Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md`, lines 14-15 **Vulnerability Type**: Unpinned third-party dependency **Risk Level**: Medium **Vulnerable Code:** ```yaml install: | pip install selenium ``` ### Technical Analysis The installation command does not constrain Selenium to a reviewed version and does not verify the downloaded artifact with a cryptographic hash. Consequently, installations performed at different times can resolve to different package versions. Because Python packages can run installation or imported runtime code with the privileges of the installing process, a compromised upstream release, package-index account, or distribution path could introduce attacker-controlled behavior. This finding does not establish that the legitimate Selenium package is malicious; it identifies the absence of dependency integrity and reproducibility controls. ### Attack Path 1. An operator installs the skill's declared dependency by running `pip install selenium`. 2. `pip` resolves the mutable latest compatible release from the configured package index. 3. If that release or its distribution channel has been compromised, an attacker-controlled artifact is downloaded. 4. Package installation or subsequent import executes the compromised code with the Python process's privileges. 5. The code can access resources available to that process, including automation inputs, browser data, files, and network connectivity. ### Impact Assessment Successful exploitation could provide code execution with the privileges of the account or environment performing installation or running the automation. The accessible scope would depend on that environment and could include project files, environment variables, browser session data, and reachable network services. System-level privileges are not inherently obtained unless installation or execution occurs as a privileged user.
Remediation
## Remediation Suggestions - Pin Selenium to an exact, reviewed version, for example through a locked dependency file. - Require cryptographic hashes using a command such as `pip install --require-hashes -r requirements.txt`. - Generate and review a lock file that includes all transitive dependencies. - Install only from an explicitly trusted package index over authenticated TLS. - Perform dependency installation and browser automation as a non-root user in an isolated environment. - Add automated dependency vulnerability and provenance checks before updating the pinned version.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:36
Finding
Chrome Sandbox Disabled in Default Browser Configuration## Vulnerability Details **File Location**: `SKILL.md`, line 36 **Vulnerability Type**: Unsafe browser security configuration **Risk Level**: High **Vulnerable Code:** ```python chrome_options.add_argument("--no-sandbox") ``` ### Technical Analysis The default Selenium template starts Chrome with the `--no-sandbox` option. This disables an important browser defense that ordinarily isolates renderer and related processes from the host operating system. Web automation commonly processes untrusted websites and attacker-controlled page content. If such content exploits a Chrome vulnerability, disabling the sandbox removes a major containment boundary and can increase the likelihood that browser-process compromise results in host-level code execution within the automation user's security context. The option is sometimes used in constrained container environments, but applying it unconditionally is unsafe. The skill's requirement for explicit approval before script execution reduces accidental execution risk, but it does not mitigate exploitation after an approved browser session visits malicious content. ### Attack Path 1. The skill generates a Selenium script using the documented default configuration. 2. The user explicitly approves execution of that script. 3. Chrome starts with `--no-sandbox`. 4. The script visits a malicious or compromised website. 5. Attacker-controlled page content triggers an applicable browser vulnerability. 6. Without normal sandbox containment, the compromised browser process may execute code or access resources available to the automation user. ### Impact Assessment Successful exploitation could expose files, credentials, environment variables, browser data, and network resources accessible to the account running Chrome. The attacker could potentially execute commands with that account's privileges. This setting alone does not grant root or administrative privileges, but the impact becomes sub ...[truncated 126 chars]
Remediation
## Remediation Suggestions - Remove `chrome_options.add_argument("--no-sandbox")` from the default template. - Run Chrome with its sandbox enabled under a dedicated, non-privileged operating-system account. - If disabling the sandbox is technically unavoidable, permit it only through an explicit opt-in configuration with a clear security warning. - Place such execution in a hardened, disposable container or virtual machine with no sensitive host mounts. - Drop Linux capabilities, prevent privilege escalation, use a read-only root filesystem where practical, and apply restrictive seccomp and AppArmor or SELinux policies. - Restrict outbound network access to approved destinations and avoid providing browser processes with secrets that are unnecessary for the task. - Keep Chrome and ChromeDriver patched and use compatible, reviewed versions.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.