T09 · Insecure Skill Coding Practices
- Location
config.py:9- Finding
Hard-Coded Third-Party API Credentials
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This search skill is mostly a Chinese web-search CLI, but it ships hard-coded third-party API keys and under-discloses how queries are routed through external services.
Install only after the publisher removes and rotates the bundled Tavily and Jina keys, documents which external services receive queries, and preferably pins dependencies. Treat any searches as shared with Jina and the selected search providers; avoid sensitive or proprietary queries unless you have reviewed and replaced the credentials with your own.
config.py:9Hard-Coded Third-Party API Credentials
requirements.txt:1Unpinned and Unverified Python Dependencies
A description-behavior mismatch is a real security issue here because the declared purpose is simple aggregated search, while the detected implementation reportedly includes hardcoded third-party API credentials, an external AI summarization service, and additional web-fetching through Jina Reader that are not disclosed. Undocumented external services and embedded secrets can cause data exfiltration, unauthorized billing, secret leakage, and trust-boundary violations for users who believe they are only invoking local or direct search functionality.
The README advertises AI summarization via Tavily but does not disclose that user queries and possibly aggregated search results may be transmitted to a third-party service. In an agent/search skill, users may submit sensitive prompts, internal research topics, or proprietary data, so this omission creates a real privacy and data-handling risk rather than a purely documentation issue.
The skill advertises and enables network-based search behavior but does not declare any explicit tool scope such as permissions or allowed-tools. In an agent ecosystem, this weakens policy enforcement and transparency, making it easier for the skill to perform outbound requests without clear operator awareness or sandbox constraints.
The description and title explicitly position the skill as '中文AI Agent专用' and '中文AI聚合搜索', indicating a fixed language/locale constraint in the natural-language description. Because the file does not offer any user choice, opt-in, or explain a justified region-specific compliance need, this is a language/locale policy concern under the stated rule.
The natural-language comments describe the skill as a Chinese AI aggregate search configuration and present the setup entirely in Chinese without indicating that users may choose another language or locale. This can be a language/locale policy issue when the skill appears to force a specific language experience without opt-in or explicit justification.
The file contains hard-coded third-party API credentials for Tavily and Jina. Embedded secrets are a real security issue because anyone with access to the skill source can reuse the keys, incur cost, access associated service quotas/data, and potentially pivot into other connected systems depending on the provider account configuration.
The CLI defaults and hardcoded supported platforms constrain searches to Chinese-language and China-centric services without explicit user opt-in, which can bias results, reduce coverage, and route user queries to region-specific third parties. In an agent context, this can silently shape downstream decisions or expose sensitive search terms to a narrower geopolitical and provider set than the user may expect.
The description states this is a "中文AI Agent专用" tool, which indicates the skill is intended specifically for Chinese-language AI agents and does not offer a user language choice. This is a natural-language locale policy concern because it imposes a language constraint without documenting opt-in or justification.
The README presents the skill as Chinese-only and all user-facing documentation is in Chinese, but it does not explicitly offer language/locale choice or justify the restriction as a region-specific requirement. Under the policy, forcing a specific language without opt-in can be a natural-language policy concern.
The dependency declaration uses a lower-bound specifier (requests>=2.31.0) instead of pinning an exact version, which makes builds non-reproducible and can cause installation of unexpected future releases or vulnerable intermediary versions depending on resolution behavior. In a network-facing search tool, this increases supply-chain uncertainty because requests is directly used for outbound HTTP interactions and has had multiple security advisories.
requests>=2.31.0
beautifulsoup4>=4.12.0
pydantic>=2.0.0
click>=8.0.0
The manifest does not pin the requests version, so it is impossible to verify from this file whether the installed release avoids known requests advisories. This is especially relevant here because the skill is a multi-platform search tool and likely relies on HTTP requests extensively, increasing exposure if a vulnerable version is resolved at install time.
beautifulsoup4 is unpinned, so installations may vary over time and across environments, reducing reproducibility and making it harder to verify whether deployed versions are secure and tested. While this library is less directly security-sensitive than an HTTP client, unexpected parser behavior changes can still affect the robustness of a scraping/search aggregation tool.
requests>=2.31.0
beautifulsoup4>=4.12.0
pydantic>=2.0.0
click>=8.0.0
pydantic>=2.0.0 allows a wide range of versions to be installed, which prevents assurance about exactly which code is running and whether known vulnerable releases are excluded. Because pydantic often processes external or user-controlled input, version ambiguity can matter when parser or validation bugs are disclosed.
requests>=2.31.0
beautifulsoup4>=4.12.0
pydantic>=2.0.0
click>=8.0.0
Because pydantic is not pinned, the requirements file does not establish whether deployed environments will use a version affected by known pydantic CVEs. Since pydantic commonly validates untrusted input, ambiguity around the installed version creates avoidable uncertainty in a component that may process external search parameters or structured responses.
click is specified as click>=8.0.0, which permits installation of many versions, including potentially vulnerable ones, and prevents reproducible builds. For an agent skill that may expose CLI entry points or wrapper scripts, dependency ambiguity can broaden supply-chain risk even if no direct exploit is shown in this file.
requests>=2.31.0
beautifulsoup4>=4.12.0
pydantic>=2.0.0
click>=8.0.0
The click dependency is unpinned, so the file does not prove that an installed version is free from known advisories. If the skill exposes command-line operations, an inadvertently resolved vulnerable click release could introduce avoidable risk through dependency drift.
No suspicious patterns detected.