T03 · Remote Payload Retrieval and Execution
- Location
scripts/setup.sh:93- Finding
Unverified Remote Installer Is Piped Directly into a Shell
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill's weekly-report purpose is coherent, but it handles credentials and team report data with weak transport, storage, and installation safeguards that warrant review before use.
Review this before installing in any real workplace environment. Use only least-privilege test credentials at first, avoid storing secrets in project `.env` files, do not run the streamed remote installer without independent verification, and do not process confidential reports unless the report system uses HTTPS and your organization approves sending report contents to the configured LLM provider. Treat `.token_cache` and `.data_cache` as sensitive files and delete or protect them after use.
scripts/setup.sh:93Unverified Remote Installer Is Piped Directly into a Shell
scripts/lib/config.py:11Credentials, Session Tokens, Cookies, and Report Data Are Transmitted over Plaintext HTTP
scripts/lib/login.py:142Authentication Material Is Stored in an Unprotected Plaintext Cache
scripts/lib/fetcher.py:344Raw Employee Weekly Reports Are Persisted in a Plaintext Data Cache
scripts/lib/summarizer.py:227Internal Employee Report Content Is Disclosed to an External LLM Service
scripts/lib/generator.py:107Unvalidated Output Filename Allows Writes Outside the Configured Output Directory
scripts/pyproject.toml:7Unpinned Dependencies and Mutable Package Sources Make Builds Non-Reproducible
The documented behavior claims tightly scoped weekly-report automation, but the analysis indicates the implementation does not actually perform the advertised login/data-fetch/document-generation functions and instead exposes a more generic LLM capability. That mismatch is dangerous because operators may trust and authorize the skill for sensitive team-report workflows while it can behave outside the stated purpose, weakening oversight and enabling misuse of provided credentials, data, or model access.
Piping downloaded content directly into sh removes any opportunity for inspection and immediately executes whatever the remote endpoint returns. In a skill that already expects credentials and local setup, this materially raises compromise risk because a successful supply-chain attack could lead to arbitrary code execution, credential theft, or persistence on the host.
irm https://astral.sh/uv/install.ps1 | iex
# 安装 uv (macOS/Linux)
curl -LsSf https://astral.sh/uv/install.sh | sh
# 安装依赖
cd skills/weekly-report/scripts
The guide explicitly recommends storing a username, password, and API key in a .env file without safeguards. In practice, .env files are commonly leaked through source control, backups, support bundles, or permissive filesystem access, and these credentials could be used to access the weekly report system and associated AI provider.
$env:DEEPSEEK_API_KEY="sk-xxxxx"
**使用 .env 文件:**
```env
WEEKLY_REPORT_USERNAME=your_username
WEEKLY_REPORT_PASSWORD=your_password
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
model_config = SettingsConfigDict(
env_prefix="WEEKLY_REPORT_",
env_file=".env",
env_file_encoding="utf-8",
extra="ignore",
)
The pipe into sh removes any inspection barrier and turns network-delivered content directly into executable shell commands. That makes compromise of the remote source or transport immediately equivalent to arbitrary code execution on the user's machine.
fi
# Use official installer (works in most cases)
curl -LsSf https://astral.sh/uv/install.sh | sh
# Source shell profile if it exists (uv installer adds to profile)
if [ -f "$HOME/.bashrc" ]; then
The skill declares powerful capabilities via setup scripts, environment variables, shell commands, networking, and file access, but does not define any explicit tool scope or permission boundaries. That creates an authorization gap where a user or orchestrator may invoke a skill with broader powers than users would reasonably expect, increasing the risk of unintended credential use, data access, or command execution.
The description emphasizes convenience and automation but does not clearly warn that the skill will use stored credentials to log into an external report system and access team members' report data. In this context, that omission is security-relevant because users may trigger the skill without realizing it will perform authenticated actions and process potentially sensitive organizational information.
The trigger conditions are broad enough to activate on ordinary mentions of summaries, work reports, or weekly reports, which can cause the skill to run in contexts the user did not intend. Because this skill can use credentials, network access, and team data, over-triggering increases the chance of unnecessary data access or execution of sensitive automation without clear informed consent.
The documentation instructs users to place usernames, passwords, and API keys into environment variables and a .env file, but it does not warn that .env files are sensitive, should be excluded from version control, and must be protected with appropriate filesystem permissions. In a skill that automates login and uses third-party LLM APIs, these secrets enable direct account access and data exposure if mishandled.
The workflow explicitly describes capturing authorization headers and caching both tokens and cookies in local files, but provides no warning about the sensitivity of these credentials or expectations for secure storage. If those cache files are readable by other local users, included in backups, or accidentally committed, an attacker could reuse active session material to access the weekly report system as the user.
The workflow sends raw weekly report data to an external LLM API for summarization, but does not disclose the privacy implications of transmitting potentially sensitive business content and employee-related data to a third-party service. This can cause unintentional data leakage, regulatory issues, or retention of internal information outside the organization's boundary.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
provider: Literal["deepseek", "openai"] = Field(default="deepseek", description="LLM provider")
model: str = Field(default="deepseek-chat", description="Model name")
base_url: str = Field(default="https://api.deepseek.com/v1", description="API base URL")
max_tokens: int = Field(default=4000, description="Maximum tokens in response")
temperature: float = Field(default=0.7, description="Temperature for generation")
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
provider: Literal["deepseek", "openai"] = Field(default="deepseek", description="LLM provider")
model: str = Field(default="deepseek-chat", description="Model name")
base_url: str = Field(default="https://api.deepseek.com/v1", description="API base URL")
max_tokens: int = Field(default=4000, description="Maximum tokens in response")
temperature: float = Field(default=0.7, description="Temperature for generation")
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
provider: Literal["deepseek", "openai"] = Field(default="deepseek", description="LLM provider")
model: str = Field(default="deepseek-chat", description="Model name")
base_url: str = Field(default="https://api.deepseek.com/v1", description="API base URL")
max_tokens: int = Field(default=4000, description="Maximum tokens in response")
temperature: float = Field(default=0.7, description="Temperature for generation")
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
provider: Literal["deepseek", "openai"] = Field(default="deepseek", description="LLM provider")
model: str = Field(default="deepseek-chat", description="Model name")
base_url: str = Field(default="https://api.deepseek.com/v1", description="API base URL")
max_tokens: int = Field(default=4000, description="Maximum tokens in response")
temperature: float = Field(default=0.7, description="Temperature for generation")
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
provider: Literal["deepseek", "openai"] = Field(default="deepseek", description="LLM provider")
model: str = Field(default="deepseek-chat", description="Model name")
base_url: str = Field(default="https://api.deepseek.com/v1", description="API base URL")
max_tokens: int = Field(default=4000, description="Maximum tokens in response")
temperature: float = Field(default=0.7, description="Temperature for generation")
The defaults set the team name and member list in Chinese, which implies a fixed language/locale context in the skill's natural-language behavior. There is no indication in this file that users can opt into another language or that the locale restriction is explicitly documented as region-specific.
The display helper formats dates as YYYY年MM月DD日, which forces Japanese-language output. This is a natural-language/locale policy concern because the file provides no opt-in, fallback, or explanation that the skill is intended only for a Japanese locale.
The code persists fetched weekly report data to a local .data_cache file without any access controls, retention policy, or user disclosure. Because this skill handles team weekly reports, the cached content may contain sensitive employee work summaries or internal business data that can be exposed to other local users, later processes, backups, or accidental commits.
This file embeds Chinese-only category labels and later uses Chinese titles and fonts throughout document generation, which effectively forces a specific language/locale. The policy allows locale constraints only when user choice or clear documented justification is provided, neither of which appears in this file.
This code sends arbitrary prompts and chat messages to a third-party LLM API, but there is no indication here of consent gating, redaction, or user-facing notice before potentially sensitive weekly-report data leaves the local environment. In the context of a team weekly-report skill, prompts may contain employee work summaries, internal project details, or other confidential business information, so external transmission creates a real confidentiality and compliance risk.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
return DeepSeekClient(
api_key=api_key,
model=model or "gpt-4",
base_url=base_url or "https://api.openai.com/v1",
)
else:
raise ValueError(f"Unknown LLM provider: {provider}")
The login flow intercepts outbound browser requests and extracts the authorization header, which is highly sensitive authentication material. Even if intended to automate login, collecting tokens from live network traffic increases exposure of credentials and is especially risky because this skill is designed to access a real work-reporting system containing team data.
The code persists a captured authentication token and all browser cookies to a local file in plaintext with no access controls, expiry handling, or user consent. If the workstation, project directory, logs, backups, or synced files are accessible to another user or process, these credentials can be reused to impersonate the user and access the reporting system.
The embedded prompt is entirely in Chinese and instructs the model to produce output in that language and format, which imposes a specific language/locale behavior. The file does not indicate that users can choose another language or that the Chinese-only constraint is a documented, region-specific requirement.