Back to skill

Security audit

HK3 CRM 安装器

Security checks for vulnerabilities and agentic risk

Overview

This HK3 CRM installer is purpose-aligned, but it should be reviewed because it downloads mutable remote code, installs dependencies, and starts a background service without verification or clear consent gates.

Install only if you are comfortable running code from the referenced GitHub repository under your local user account. Review or pin the repository revision first, use a virtual environment or container, inspect requirements.txt before installing, and make sure you know how to stop the background CRM process.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T03 · Remote Payload Retrieval and Execution

Error
Location
setup.sh:9
Finding
Unverified Mutable Remote Code Is Downloaded and Executed<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh`, lines 9-29 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash REPO_URL="https://github.com/jiangyisheng9-bot/hk3-crm.git" if [ -d "$CRM_DIR" ]; then cd "$CRM_DIR" && git pull else cd "$WORKSPACE" && git clone "$REPO_URL" fi cd "$CRM_DIR" pip3 install -r requirements.txt -q 2>/dev/null || pip install -r requirements.txt -q nohup python3 app.py > /tmp/hk3-crm.log 2>&1 & CRM_PID=$! echo $CRM_PID > "$CRM_DIR/.pid" ``` ### Technical Analysis The installer clones or updates a GitHub repository and then directly executes content obtained from that repository. It does not pin the repository to an immutable commit, validate an expected cryptographic hash, or verify a trusted signature. Consequently, the effective code executed by the Skill can change after the local Skill package has been audited. Both initial installation through `git clone` and later updates through `git pull` trust the current remote repository state. The remote repository controls `app.py` and `requirements.txt`, providing multiple code-execution opportunities. The local files do not prove that the current remote repository is malicious. The vulnerability is the unrestricted and unverified remote execution channel. ### Attack Path 1. An attacker compromises the GitHub repository, its maintainer account, or another mechanism capable of changing its default branch. 2. The attacker adds malicious instructions to `app.py`, changes `requirements.txt`, or modifies other code imported by the application. 3. A user or Agent invokes the Skill. 4. The installer retrieves the attacker-controlled revision through `git clone` or `git pull`. 5. The installer runs dependency installation and launches `python3 app.py` without validating the downloaded revision. 6. The malicious code executes with the operating-system privileges and environment access of the user runnin ...[truncated 686 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Vendor the required application source into a reviewed release artifact whenever practical. 2. If remote retrieval is necessary, pin an immutable commit hash rather than using the mutable default branch. 3. Maintain an allowlisted expected commit hash outside the downloaded repository and verify that the checked-out `HEAD` matches it before installing or executing anything. 4. Require cryptographically signed commits or release artifacts and validate signatures against a separately configured trusted key. 5. Download release archives only over authenticated HTTPS and verify a trusted SHA-256 or stronger digest before extraction. 6. Display the repository URL, exact revision, and verification result, and obtain explicit user approval before execution. 7. Abort safely if verification fails; never fall back to running an unverified revision. 8. Execute the application with a dedicated, least-privileged account or within an appropriately restricted container or sandbox. 9. Review the complete remote application and its dependency lockfile as part of each approved version update. ]]>

T08 · Insecure Dependencies

Error
Location
setup.sh:23
Finding
Remote Dependencies Are Installed Without Integrity Verification or Isolation<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh`, lines 23-25 **Vulnerability Type**: Insecure dependency installation **Risk Level**: High ### Vulnerable Code ```bash cd "$CRM_DIR" pip3 install -r requirements.txt -q 2>/dev/null || pip install -r requirements.txt -q ``` ### Technical Analysis The dependency manifest is supplied by the mutable remote repository and is passed directly to `pip`. The installer does not enforce package hashes, demonstrate that dependencies are pinned to exact reviewed versions, or create an isolated virtual environment. Python package installation may execute package build backends and installation-related code. Therefore, an attacker-controlled dependency declaration can cause code execution during the installation stage, even before `app.py` starts. The fallback from `pip3` to the generic `pip` executable also introduces interpreter ambiguity. It may install packages into a different Python environment from the one used by `python3 app.py`. Quiet mode and suppression of the first command's standard error reduce visibility into package resolution, security warnings, and installation failures. No specific malicious dependency was identified in the audited local files because the remote `requirements.txt` was not included in the project. The finding concerns the unsafe dependency trust and installation process. ### Attack Path 1. An attacker compromises the remote repository and changes `requirements.txt`, or a referenced dependency source becomes compromised. 2. The attacker adds a malicious package, changes a package source, or selects a dependency version containing malicious installation behavior. 3. A user or Agent runs `setup.sh`. 4. The script retrieves the remote manifest and invokes `pip3 install`, or falls back to `pip install`. 5. The package manager downloads and processes the unverified dependency. 6. Malicious build or installation code executes with the privileges of the invoking user. ### Imp ...[truncated 638 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Create a dedicated virtual environment using the same interpreter that will run the application: ```bash python3 -m venv "$CRM_DIR/.venv" "$CRM_DIR/.venv/bin/python" -m pip install --upgrade pip ``` 2. Use `python3 -m pip` or the virtual environment's explicit Python executable instead of ambiguous `pip3` and `pip` commands. 3. Generate and review a lockfile containing exact dependency versions and cryptographic hashes. 4. Enforce integrity verification with: ```bash "$CRM_DIR/.venv/bin/python" -m pip install --require-hashes -r requirements.txt ``` 5. Use only trusted package indexes and explicitly configure approved index URLs. Do not permit unreviewed direct URLs, VCS dependencies, or additional package indexes. 6. Prefer prebuilt, verified wheels where feasible and restrict source builds to dependencies that have been separately reviewed. 7. Do not suppress standard error or security-relevant installation output. Preserve logs and fail closed on any installation error. 8. Run dependency installation and the application under a dedicated least-privileged account or within a constrained build and runtime environment. 9. Review and approve dependency changes before updating the pinned application revision. ]]>
Vulnerability Patterns
  • Rogue AgentSelf-Modification, Session Persistence
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (7)

Lp3

Medium
Category
MCP Least Privilege
Confidence
95% confidence
Finding
The skill advertises an installation workflow that runs a shell script, clones code from GitHub, installs dependencies, and starts a service, but it declares no tool scope or execution permissions. That mismatch is dangerous because it obscures the skill's true execution capabilities from reviewers and users, increasing the risk of unexpected code execution and supply-chain compromise from the referenced repository.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The skill description describes a convenient one-click installer but does not clearly warn that it will execute setup.sh, clone remote code from GitHub, install Python packages, and launch a local service. This lack of transparency is dangerous because users may consent without understanding that arbitrary shell commands and third-party code will run on their machine.

Vague Triggers

Medium
Confidence
92% confidence
Finding
The trigger phrases include broad install-oriented CRM language that can match generic user requests and invoke this skill in situations where the user did not specifically ask for this HK3 CRM package. In a skill that performs shell execution and downloads code, overly broad activation increases the chance of unintended repository cloning and script execution.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The script installs Python dependencies and starts a long-running service automatically, making system changes and spawning a background process without any confirmation, privilege check, or rollback. In an agent-executed skill, this is risky because it can alter the host environment, consume resources, and leave a persistent service running even if the user did not explicitly approve those actions.

Session Persistence

Medium
Category
Rogue Agent
Content
# 3. 启动(后台)
echo "🚀 启动 CRM..."
nohup python3 app.py > /tmp/hk3-crm.log 2>&1 &
CRM_PID=$!
echo $CRM_PID > "$CRM_DIR/.pid"
Confidence
96% confidence
Finding
Using nohup to launch app.py in the background creates persistence beyond the invoking session and writes a PID file, causing the service to remain active after the installer exits. In the context of an agent skill, this is more dangerous because it establishes an unattended resident process from a remote GitHub checkout without sandboxing, service management controls, or explicit approval.

Natural-Language Policy Violations

Low
Confidence
83% confidence
Finding
The skill name, description, and instructions are entirely in Chinese, while no language-selection option or explicit justification for restricting interaction language is provided. Under the policy, locale or language constraints should be opt-in or clearly justified.

Natural-Language Policy Violations

Low
Confidence
84% confidence
Finding
The script's natural-language comments and runtime messages are presented in Chinese only, including usage and operational status text. This imposes a specific language on users without opt-in or justification, which matches the language/locale policy concern.

Static analysis

No suspicious patterns detected.