T09 · Insecure Skill Coding Practices
- Location
SKILL.md:16- Finding
Undisclosed Multi-Provider Transmission of User Search Queries
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:16-20andSKILL.md:150-154
Vulnerability Type: Privacy disclosure mismatch and excessive query distribution
Risk Level: MediumVulnerable Code
markdown 3. **Controlled Search**: Use web_fetch to execute search requests with rate limiting: - Add 1-2 second delay between requests to respect server load - Batch requests in groups of 3-4 engines with sequential execution between batches - Include standard browser headers to identify as legitimate user agent - If access is denied (403/429), fetch engine homepage to obtain fresh session cookiesThe data-handling notice contradicts that network behavior:
markdown ### Data Handling - **No Personal Data**: Tool does not collect or transmit user personal information - **Local Execution**: All operations run locally, no external data transmission - **Session Isolation**: Cookies are session-specific and cleared after useTechnical Analysis
The Skill explicitly directs the agent to place user-provided search terms into URLs and submit them to batches of three or four external search providers. This network access is necessary for web-search functionality, but distributing every query to several providers is broader than the minimum access required to perform a search.
Search queries may contain names, email addresses, internal project identifiers, confidential business information, personal concerns, credential-like strings, or other sensitive data. URL query parameters may be retained in provider logs, network telemetry, browser or tool history, and monitoring systems.
The statement that all operations are local and involve “no external data transmission” is factually incompatible with the required
web_fetchoperations. Consequently, users may submit information under an incorrect privacy assumption.The static pre-scan finding at
references/international-search.md:185is not evidence that an actual password is ...[truncated 1879 chars]- Remediation
View remediation
Remediation Suggestions
- Replace the inaccurate privacy statements with an explicit disclosure that search terms and request metadata are transmitted to selected third-party search engines.
- Default to a single search provider and use additional providers only when the user requests aggregation or the first provider fails.
- Obtain explicit user confirmation before transmitting a query to multiple providers, especially when sensitive information is detected.
- Display the destination domains before network requests are made.
- Warn users not to submit passwords, API keys, authentication tokens, private keys, personal identifiers, confidential documents, or proprietary internal data.
- Apply URL encoding to all user-controlled query values and keep provider hostnames constrained to a fixed allowlist.
- Minimize request metadata and avoid reusing identifying cookies where they are not required.
- Document realistic cookie behavior and verify that cookies remain domain-scoped, in memory, and are cleared after each search session.
- Replace remote password-generation examples with local generation using a cryptographically secure random-number generator.
- Provide a privacy-preserving mode that uses one user-selected provider and disables cookie acquisition, retries, and multi-provider fan-out.