T09 · Insecure Skill Coding Practices
- Location
main.py:47- Finding
Indirect Prompt Injection in the Multi-Stage LLM Pipeline
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill performs the disclosed GEO brand-analysis task through DeepSeek API calls, with no evidence of hidden persistence, local data access, credential theft, or destructive behavior.
Install only if you are comfortable sending the brand name, category keyword, and generated analysis text to DeepSeek under your API key. Treat the report as advisory because crafted inputs can manipulate LLM-based conclusions, and prefer pinned dependencies or a reviewed lockfile before production use.
main.py:47Indirect Prompt Injection in the Multi-Stage LLM Pipeline
requirements.txt:1Unpinned and Unnecessary Third-Party Dependencies
The natural-language content of the skill description, usage instructions, triggers, and safety notes is presented in Chinese, which effectively forces a specific language for users and integrators. The file does not offer an alternative language, user opt-in, or justification that this skill is intentionally region- or locale-specific.
The skill sends user-supplied inputs and model-generated content to an external third-party endpoint (DeepSeek) for processing. This creates a real data exposure boundary: brand names, category keywords, and potentially sensitive prompt contents are transmitted off-platform, which can violate data-handling expectations or compliance requirements if not clearly disclosed and controlled.
# 初始化 OpenAI 客户端,Base URL 指向 DeepSeek API
client = OpenAI(
api_key=api_key,
base_url="https://api.deepseek.com/v1"
)
try:
The prompt explicitly instructs the model to generate the report in Chinese ("使用中文") with no user opt-in or configurable language option. This is a natural-language locale policy issue because the skill imposes a specific language regardless of user preference.
The manifest description is written entirely in Chinese and does not indicate that the skill supports other languages or lets the user choose a locale. Under the policy, a language-specific constraint should be optional or clearly justified as region-specific.
The dependency specification uses a lower-bound range instead of an exact version pin, which makes builds non-reproducible and can allow unexpected upstream changes or vulnerable releases to be installed. In a security-sensitive agent skill, this weakens supply-chain control even if there is no immediate evidence of exploitation.
openai>=1.0.0
pydantic>=2.0.0
python-dotenv>=1.0.0
The pydantic dependency is not pinned to a specific version, so installations may resolve to different releases over time, including versions with known security defects. This creates avoidable supply-chain risk and makes it impossible to verify whether deployed environments are using a safe release.
openai>=1.0.0
pydantic>=2.0.0
python-dotenv>=1.0.0
Pydantic has known advisories, and because the manifest does not pin a version, there is no way to determine whether the installed release is affected. The danger here is uncertainty: deployments may silently resolve to a vulnerable version, exposing consumers to issues such as denial of service depending on how the library is used.
The python-dotenv package is specified with a broad minimum version rather than an exact reviewed version, which permits drift to potentially unsafe or untested releases. This is especially relevant because environment-file tooling can interact with sensitive configuration and filesystem paths.
openai>=1.0.0
pydantic>=2.0.0
python-dotenv>=1.0.0
Python-dotenv has known advisories, but the unpinned manifest prevents verification that a safe version will be installed. Because dotenv utilities may read or write environment files and interact with filesystem paths, unresolved version selection can increase risk if a vulnerable release is chosen.
No suspicious patterns detected.