Back to skill

Security audit

OpenWebSearch

Security checks for vulnerabilities and agentic risk

Overview

This skill gives coherent, user-confirmed setup and web-retrieval guidance for open-websearch, with some ordinary setup security cautions.

Install only if you want open-websearch integration. Review any package installs, browser downloads, daemon startup, or MCP/client config edits before approving them, and avoid FETCH_WEB_INSECURE_TLS except for non-sensitive diagnostic fetches where you understand the reduced HTTPS protection.

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
references/setup.md:117
Finding

Unpinned Third-Party Package and Browser Binary Installation

Content
View full analysis

Vulnerability Details

File Location: references/setup.md:117
Vulnerability Type: Supply-chain risk from unpinned dependencies
Risk Level: Medium

Complete Code Snippet:

markdown
3. Perform the smallest fitting path.
   - local install: `npm install playwright` and `npx playwright install chromium`
   - existing browser binary with a Playwright client (commonly `playwright-core`) and `PLAYWRIGHT_EXECUTABLE_PATH`
   - existing Playwright package via `PLAYWRIGHT_MODULE_PATH`
   - existing remote browser via `PLAYWRIGHT_WS_ENDPOINT` or `PLAYWRIGHT_CDP_ENDPOINT`

Technical Analysis

The documented installation path runs npm install playwright without selecting an exact, previously audited version. It then invokes npx playwright install chromium, which executes package-provided CLI code and downloads a browser binary. The instructions do not require a lockfile, package integrity verification, a trusted registry, or independent verification of the downloaded browser artifact.

Playwright is a legitimate package, and the Skill requires user confirmation before installation. Nevertheless, using mutable package resolution increases exposure to package-registry compromise, compromised future releases, transitive dependency compromise, registry substitution, and unexpected changes in installation behavior. Execution through npx should also be constrained to the explicitly installed local package so that it cannot resolve an unintended package from a registry.

Attack Path

  1. An attacker compromises a package release, transitive dependency, configured npm registry, or package-delivery path.
  2. A user follows the browser-assisted setup instructions and authorizes the installation.
  3. npm install playwright resolves the mutable package version or affected dependency.
  4. Package installation logic or the subsequently invoked CLI executes with the privileges of the user running npm.
  5. `npx play ...[truncated 742 chars]
Remediation
View remediation

Remediation Suggestions

  • Pin Playwright to an exact, reviewed version rather than installing a mutable latest release.
  • Provide and enforce a lockfile containing package integrity metadata.
  • Configure npm to use an explicitly trusted HTTPS registry and reject unexpected registry substitutions.
  • Invoke the pinned local binary directly, such as through an audited package script or ./node_modules/.bin/playwright, instead of allowing npx to resolve an absent package remotely.
  • Document how the browser artifact is obtained and verified, including expected checksums or the package vendor's supported integrity mechanism.
  • Run installation as a non-privileged user in an isolated environment with minimal access to secrets and unrelated workspace files.
  • Retain the existing requirement for explicit user confirmation before package or browser installation.

T09 · Insecure Skill Coding Practices

Warning
Location
references/engine-selection.md:25
Finding

Optional Disabling of TLS Certificate Verification for Web Retrieval

Content
View full analysis

Vulnerability Details

File Location: references/engine-selection.md:25; related behavior documented in SKILL.md:122
Vulnerability Type: Insecure TLS configuration
Risk Level: Medium

Complete Code Snippet:

markdown
## Failure handling

- If `bing` returns verification or anti-bot pages, prefer `SEARCH_MODE=auto` or switch engines.
- If a page fetch fails due to network restrictions, check proxy configuration.
- If `fetchWebContent` fails on a site with a broken certificate chain, only then consider `FETCH_WEB_INSECURE_TLS=true`.

Related scope statement in SKILL.md:

markdown
- `FETCH_WEB_INSECURE_TLS` only affects `fetchWebContent`, not the search engines.

Technical Analysis

The Skill permits setting FETCH_WEB_INSECURE_TLS=true when a target has a broken certificate chain. Disabling certificate verification removes authentication of the remote HTTPS server for affected fetches. Encryption without reliable peer authentication does not prevent a man-in-the-middle attacker from impersonating the destination and modifying the returned page.

The recommendation is presented as a fallback rather than the default, and its scope is limited to fetchWebContent. However, it does not require explicit confirmation at the point of use, restrict the setting to one destination or one request, prohibit sensitive URLs, or require the setting to be removed immediately afterward. If the variable applies process-wide, unrelated fetches performed while it remains enabled may also lose certificate validation.

Attack Path

  1. A page fetch fails because of a certificate-chain error.
  2. The operator follows the documented fallback and enables FETCH_WEB_INSECURE_TLS=true.
  3. An attacker controlling a network path, proxy, DNS response, or local trust boundary presents an untrusted certificate and impersonates the requested host.
  4. Because certificate verification is disabled, the fetch acce ...[truncated 761 chars]
Remediation
View remediation

Remediation Suggestions

  • Prefer correcting the server certificate chain, using a different trustworthy source, or supplying a narrowly scoped trusted CA bundle.
  • Do not recommend globally disabling TLS verification as a normal recovery mechanism.
  • If insecure retrieval must remain available for diagnostics, require explicit user confirmation immediately before use and display a clear interception warning.
  • Scope the exception to one named host and one request rather than a persistent process-wide environment variable.
  • Prohibit use for authenticated pages, URLs containing tokens, private endpoints, or any request involving sensitive information.
  • Restore certificate verification immediately after the diagnostic request and validate that subsequent fetches use normal TLS checks.
  • Clearly label content obtained without certificate verification as untrusted and unsuitable as sole evidence for security-sensitive conclusions.
Vulnerability Patterns
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Rp1

Medium
Category
MCP Rug Pull
Confidence
85% confidence
Finding

The setup guidance recommends npx playwright, which pulls and executes a package by name at runtime without pinning a specific version. That creates a supply-chain risk: the resolved version can change over time, and if the package or dependency chain is compromised, users may execute unexpected code during setup.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
77% confidence
Finding

The guidance says to prefer startpage for general English-language web search, which encodes a language-specific default in the skill behavior. The policy allows locale constraints when users are given a choice or the limitation is clearly justified; here, the skill also supports Chinese-language sources, but it does not explicitly frame language choice as user opt-in.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.