Back to skill

Security audit

CMIC Skill Scanner (Linux ARM64)

Security checks for vulnerabilities and agentic risk

Overview

The skill is a plausible security scanner, but it needs review because its default mode may run a locally resolved external scanner and its install path depends on missing or unpinned artifacts.

Install only after reviewing the external scanner and build source you intend to run. Prefer --engine native for routine scans, avoid running this as an elevated user, verify any binary from an independent trusted source, and use --upload-url or --use-llm only with approved endpoints because findings or target text may leave the machine.

Vulnerability Patterns
  • Tool Hijacking and SpoofingModifies or replaces tools so legitimate-looking calls execute attacker logic
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T07 · Tool Hijacking and Spoofing

Error
Location
SKILL.md:100
Finding
Default Auto Mode May Execute a Spoofed Local Scanner<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:100-102` **Supporting Locations**: `SKILL.md:41, 59, 110`; `INSTALL.md:27-32` **Vulnerability Type**: Local tool resolution and execution hijacking **Risk Level**: High ### Vulnerable Code Snippet ```markdown Default `auto` mode tries a locally resolved external scanner first and falls back to native when it is unavailable or fails. Use `--engine external` to require the external result, or `--engine native` to run only the built-in engine. CMIC passes the target path to a user-configured local tool. The tool runs with the current user's process permissions; trust the external tool and its configuration separately. CMIC only configures the external LLM endpoint when `--use-llm` is explicitly set; the tool may otherwise bootstrap dependencies or use its own network configuration. ``` The installation guide also recommends invoking the default behavior: ```markdown The default engine is `auto`: it prefers a locally resolved external scanner and falls back to the built-in native engine if the external scanner is unavailable or fails. Use `--engine native` to run only the built-in engine. ``` ### Technical Analysis The documented default engine is `auto`, which attempts to resolve and execute an external scanner before using the built-in native implementation. The external process inherits the current user's process permissions and receives the target path. If scanner resolution depends on `PATH`, local configuration, or another location that an attacker can influence, an attacker can place a malicious executable under the expected scanner name. The legitimate-looking review command would then execute attacker-controlled code. This violates secure tool-resolution principles because the package has a native engine capable of performing the task without invoking an independently trusted executable. The source code and claimed scanner binary are absent from the audited artifact, so the exact e ...[truncated 1564 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Make `native` the default engine. Require explicit user consent through `--engine external` before launching another executable. 2. Require an absolute external-scanner path rather than resolving a bare executable name through `PATH`. 3. Reject scanner binaries located in directories writable by untrusted users. 4. Verify the scanner's cryptographic digest or signature against trusted, pinned metadata before execution. 5. Validate file ownership and permissions and reject symlinks or unexpected file types where appropriate. 6. Launch the external process with a minimal environment and remove unrelated credentials and sensitive environment variables. 7. Apply process sandboxing where supported, including restricted filesystem access, network controls, resource limits, and reduced privileges. 8. Clearly display the resolved executable path and require confirmation before its first use. 9. Add tests covering malicious `PATH` entries, symlink substitution, configuration-path manipulation, and checksum mismatches. 10. Include the implementation source or a verifiable binary in the package so the resolution and execution controls can be independently audited. ]]>

T08 · Insecure Dependencies

Warning
Location
SKILL.md:34
Finding
Build Instructions Execute Code from an Unpinned Mutable Repository<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:34-35` **Vulnerability Type**: Unpinned source and dependency supply chain **Risk Level**: Medium ### Vulnerable Code Snippet ```bash git clone https://gitee.com/random_player/cmic-skill-scanner.git cd cmic-skill-scanner && cargo build --release ``` ### Technical Analysis The recommended source-build procedure clones the repository's current default branch and immediately runs `cargo build --release`. It does not pin a reviewed commit, verify a signed tag, validate a source archive checksum, or provide an auditable lockfile in this artifact. A mutable branch can change after this package has been reviewed. In addition, Cargo builds may execute package build scripts and procedural macros during compilation. Consequently, compromise of the repository, maintainer account, or an upstream dependency could cause attacker-controlled code to run on the build host. The audited artifact contains only documentation, agent metadata, and `assets/build/build-info.json`. It does not contain the referenced source tree, dependency lockfile, binary, or checksum file. The stated binary digest therefore does not authenticate the source retrieved by this unpinned command. ### Attack Path 1. An attacker compromises the referenced repository, its maintainer account, or a dependency selected by the project. 2. The attacker modifies the default branch or dependency graph to include a malicious build script, procedural macro, or application payload. 3. A user follows the documented `git clone` command, obtaining the modified repository state. 4. The user runs `cargo build --release`. 5. Cargo compiles the dependency graph and may execute malicious build-time code with the build user's permissions. 6. A compromised output binary may subsequently execute malicious behavior whenever users invoke the scanner. ### Impact Assessment A malicious build script or procedural macro can execute commands with the permissions ...[truncated 482 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin build instructions to a specific reviewed commit hash rather than the repository's default branch. 2. Publish signed release tags and require signature verification before building. 3. Provide a source archive with a documented SHA-256 digest and a reproducible mapping between the source revision and released binary. 4. Include and enforce `Cargo.lock` for release builds; use `cargo build --release --locked`. 5. Review dependency sources, build scripts, procedural macros, and transitive dependencies before release. 6. Generate and publish a software bill of materials and dependency audit results. 7. Build in an isolated environment without personal credentials, SSH-agent forwarding, sensitive environment variables, or unnecessary network access. 8. Provide reproducible-build instructions and compare independently produced binary digests. 9. Include the referenced source, checksum file, and binary in the release artifact, or correct the documentation so it accurately describes the actual package contents. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (6)

Credential Access

High
Category
Privilege Escalation
Content
- CMIC does NOT upload reports unless you configure `--upload-url`
- CMIC does NOT configure an LLM endpoint unless you set `--use-llm`
- `auto` may execute a locally resolved external scanner; use `--engine native` to prevent that
- Does NOT access credentials or SSH configs as scan targets unless they are under the path you explicitly scan

## 工作流程
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Description-Behavior Mismatch

Medium
Confidence
91% confidence
Finding
The guide documents optional LLM review that sends package-derived content to an OpenAI-compatible endpoint, and for external mode delegates packet construction to a child scanner. Even though it mentions bounded/redacted text for native mode, this is still external transmission of analyzed content not reflected in the stated local-audit purpose, creating data leakage and trust-boundary risks.

Description-Behavior Mismatch

Medium
Confidence
95% confidence
Finding
The installation guide advertises an upload mode that sends embedded review details, full scan summaries, and findings to a remote URL, while the skill description frames the tool as a local audit wrapper. That mismatch can cause operators to disclose sensitive package metadata or findings externally without fully appreciating that the tool supports network exfiltration of scan results.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The upload example normalizes sending full scan summaries and findings to a remote endpoint without a clear warning that results may contain sensitive internal paths, package content characteristics, or security-relevant findings. Users may copy-paste the example into enterprise workflows and unintentionally disclose information to external services.

Natural-Language Policy Violations

Medium
Confidence
91% confidence
Finding
The manifest description is written in Chinese while the skill name and much of the rest of the document are in English, and there is no indication that the skill is intentionally limited to Chinese-speaking users or that language selection is optional. This can violate a language/locale policy that requires user choice or documented justification for locale constraints.

Natural-Language Policy Violations

Low
Confidence
93% confidence
Finding
The manifest text for the skill description and default prompt is entirely in Chinese, which implies a fixed language/locale for interaction. The file does not indicate any user opt-in, alternative language support, or justification for a Chinese-only constraint.

Static analysis

No suspicious patterns detected.