T03 · Remote Payload Retrieval and Execution
- Location
scripts/env_init.sh:30- Finding
Unverified Remote SDK Retrieval and Execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill fits its video-analysis purpose, but it automatically installs remote SDK code and includes unsafe environment-file handling that warrant review before use.
Install only if you are comfortable with the skill creating or reusing a Python virtual environment, installing a Volcengine SDK from a remote URL, uploading videos/results to Volcengine LAS, and using LAS credentials. Prefer reviewing or replacing the auto-update step with a pinned, hash-verified dependency install, and do not run the polling helper in workspaces where .env files may be untrusted.
scripts/env_init.sh:30Unverified Remote SDK Retrieval and Execution
scripts/poll_background.sh:20Arbitrary Shell Execution Through Sourced Environment File
The skill is presented as a video-analysis wrapper, but its documented behavior includes environment bootstrapping, package installation/upgrade, manifest fetching, and other remote/networked setup actions not disclosed in the top-level purpose. Hidden or under-described execution behavior is dangerous because it can expand the attack surface to supply-chain compromise, unreviewed code download, and unexpected host modification.
The skill is presented as a video-analysis wrapper, but its documented behavior includes environment bootstrapping, package installation/upgrade, manifest fetching, and other remote/networked setup actions not disclosed in the top-level purpose. Hidden or under-described execution behavior is dangerous because it can expand the attack surface to supply-chain compromise, unreviewed code download, and unexpected host modification.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
PROJECT_ROOT="$(cd "${SCRIPT_DIR}/../../.." && pwd)"
if [ -f "${PROJECT_ROOT}/.env" ]; then
source "${PROJECT_ROOT}/.env"
export LAS_API_KEY LAS_REGION
fi
Using source on a .env file executes its contents as shell code, not just environment assignments. If an attacker can modify .env, they can achieve arbitrary code execution when this polling script runs, potentially inheriting the script's environment and any accessible secrets. This is more dangerous in an automation skill because the script may run unattended in CI, agent, or service contexts.
PROJECT_ROOT="$(cd "${SCRIPT_DIR}/../../.." && pwd)"
if [ -f "${PROJECT_ROOT}/.env" ]; then
source "${PROJECT_ROOT}/.env"
export LAS_API_KEY LAS_REGION
fi
The skill instructs the agent to run shell commands (source, ffprobe, lasutil, file writes/uploads) but does not declare any explicit tool scope or allowed-tools boundary. This creates an authorization gap where a reviewer or runtime may underestimate the skill’s execution and network capabilities, increasing the chance of unintended command execution or data movement.
The result-handling instructions conflict with the earlier execution path and expected response schema, which can cause downstream parsing of the wrong fields or files. In a shell-capable skill, inconsistent output assumptions can lead to accidental disclosure, overwriting unrelated files, failed safety checks, or operators trusting incomplete/incorrect results.
The script performs a remote manifest fetch and conditionally installs a package from a network URL during environment initialization, even though the skill's stated purpose is video analysis rather than software bootstrap or self-update. This expands the trust boundary to external infrastructure and creates a supply-chain risk: a compromised endpoint, manipulated manifest, or unexpected wheel change could cause unreviewed code to be installed and executed in the operator's environment.
The script automatically runs pip install --upgrade against a remote wheel URL without prior warning or confirmation. Installing executable Python packages during setup can execute attacker-controlled code via package contents or dependency hooks, making this a direct supply-chain execution risk, especially because it occurs implicitly as part of sourcing the script.
The script sources a project .env file and exports LAS_API_KEY and LAS_REGION, which is access to sensitive credentials. While there is an internal comment about loading the environment, there is no user-facing warning, confirmation, or explicit disclosure that credentials will be read and used.
The checklist defines Step 4 as '结果呈现' at L42-L43, but the later section heading is '### Step 5: 结果呈现' at L118. This is an active contradiction in the skill's own operating instructions, not merely missing detail, and could cause an agent to skip or misreport required execution stages.
This shell script contains its title, error text, and status messages in Chinese only, which imposes a specific language on users. The file does not provide any opt-in, fallback, or documentation indicating that the skill is intentionally limited to a Chinese-speaking or region-specific context.
The script's comments, usage guidance, and runtime status/error messages are all presented in Chinese, with no opt-in or alternative language path. This is a natural-language locale constraint that may violate organizational language policy when not explicitly justified or made configurable.
The file contains user-visible error text and operational comments in Chinese, with no indication that language selection is optional or region-specific. This can violate a language/locale policy when a skill imposes one language without user opt-in or documented justification.
This file presents itself as a background polling helper for checking task status, but it also sources the project .env file and exports LAS_API_KEY/LAS_REGION. Reading credentials is not obviously required for a narrowly described local poll-loop script, and is a broader capability than simple status checking logic.