Security audit

YiDunAppDefense

Security checks across malware telemetry and agentic risk

Overview

This skill appears aligned with YiDun app hardening, but it needs review because it downloads and runs an external tool while handling sensitive app packages and credentials with incomplete safeguards.

Install only if you trust YiDun and are authorized to send the selected app packages to that service. Avoid pasting AppKeys or signing passwords into chat or shell commands, review ~/.yidun-defense/config.ini permissions after configuration, disable or pin updates for release builds where reproducibility matters, and verify the downloaded tool through a trusted vendor channel where possible.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
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
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (18)

Lp3

Medium

Category: MCP Least Privilege
Confidence: 82% confidence
Finding: The skill advertises shell-capable behavior such as downloading a JAR, invoking Java, and manipulating local configuration, but declares no explicit permissions or warning boundaries. This creates a trust and review gap: an agent may execute system-affecting actions without users or platform policy layers understanding that network and shell operations are involved.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The README instructs users to provide an AppKey to the configuration flow without clearly warning that this credential is sensitive, should not be pasted into general chat, and may be stored or exposed through agent logs or shell history. In an AI-agent context, prompting for secrets via natural-language interaction increases the chance of accidental disclosure to the model, platform, or other telemetry systems.

Missing User Warnings

Medium

Confidence: 83% confidence
Finding: The README advertises automatic tool download and app hardening through a vendor service but does not clearly disclose that user binaries and related metadata may be transmitted to an external service. For a skill handling proprietary mobile apps, lack of an upfront privacy and data-transfer warning can cause users to unknowingly send sensitive code or intellectual property off-host.

Vague Triggers

Medium

Confidence: 77% confidence
Finding: The example trigger phrases are broad and overlap with ordinary requests like '帮我加固这个 APK' or '配置加固工具', increasing the chance the skill activates unintentionally. In this skill's context, accidental activation is more dangerous because it can lead to downloads, local file processing, and secret collection/storage without sufficiently explicit user intent.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The documentation states that the skill will automatically download an external tool and save the user's appkey, but it does not clearly warn about network access, execution of third-party code, persistent credential storage, or the local system paths affected. This is dangerous because users may expose secrets or allow code execution and file modifications without informed consent.

Missing User Warnings

Medium

Confidence: 84% confidence
Finding: The documentation says setup will create directories, download tooling, verify integrity, and create configuration files, but it does not clearly warn that these actions modify the local system and may contact remote services. In an agent-executed context, insufficient disclosure increases the risk of users or orchestrators triggering network activity and persistent local changes without informed consent.

Missing User Warnings

Medium

Confidence: 89% confidence
Finding: Documenting a fully automatic mode without a prominent warning means an agent could process user-supplied files and communicate with remote protection services without an additional confirmation step. In a skill context that handles application binaries and credentials, this raises the chance of unintended data transmission, privacy violations, and surprise file modification in CI/CD or autonomous workflows.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The guide instructs users to enter an AppKey and use configuration scripts, but it does not clearly warn that the credential will be stored locally in ~/.yidun-defense/config.ini and used with a third-party service. This creates a real secret-handling risk because users may disclose production credentials without understanding persistence, access scope, or transmission implications.

Missing User Warnings

Low

Confidence: 87% confidence
Finding: The setup instructions tell users to run an installation script that downloads and installs third-party tooling and creates files under the home directory, but they do not prominently disclose these side effects before execution. While common in setup guides, the lack of warning reduces informed consent and can lead users to run unreviewed code that modifies their environment.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The guide documents a fully automatic mode that applies recommended protection settings without prompting, but it does not explicitly warn users that their application artifacts may be modified, re-signed, encrypted, or otherwise transformed non-interactively. In a security-sensitive build workflow, this can cause unintended changes to release binaries and increase the risk of unsafe or incorrect hardening choices being applied at scale.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The documentation shows signing configuration with plaintext password fields in `config.ini` examples but does not warn users against storing real credentials in files or checking them into source control. This pattern normalizes insecure secret handling and can lead to keystore compromise, unauthorized signing, and downstream supply-chain abuse if those credentials leak.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The CI/CD example injects a secret directly into an automation command without any guidance on masking, least-privilege scoping, rotation, or avoiding exposure in logs and shell history. In build pipelines, insufficient secret-handling guidance can result in accidental disclosure of the AppKey and unauthorized use of the protection service or related account resources.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The document explicitly instructs users to place keystore passwords and alias passwords in plaintext inside config.ini, but it does not warn about secret exposure risks or recommend safer handling. In CI systems, shared build hosts, source repositories, backups, or support bundles, this can lead to credential leakage and unauthorized signing of Android artifacts.

Missing User Warnings

Low

Confidence: 74% confidence
Finding: The documentation states that the tool will automatically check for new versions and auto-upgrade when the network is available, but it does not mention supply-chain, integrity, reproducibility, or environment-change risks. In build and release pipelines, silent tool updates can change outputs unexpectedly or introduce malicious or compromised dependencies if the update channel is attacked.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The script accepts the AppKey as a positional command-line argument, which can expose the secret through shell history, process listings, audit logs, or CI job output. Although this is a common convenience feature and not obviously malicious, it creates a real credential-handling weakness because AppKeys are sensitive authentication material for the protection service.

Missing User Warnings

Medium

Confidence: 89% confidence
Finding: The script stores the AppKey in a local config file under $HOME without warning the user that the credential will persist on disk. If file permissions are too broad, the home directory is backed up, synchronized, or accessed by other local users/processes, the secret may be disclosed and reused to access the associated service.

Ssd 3

Medium

Confidence: 95% confidence
Finding: The example dialogue explicitly asks the user to paste the AppKey into the chat session, training both users and agents to handle secrets in plain conversational text. In an AI skill context, this is dangerous because secrets may be retained in conversation history, observability tooling, prompts, transcripts, or echoed back to the user and downstream systems.

Ssd 3

Medium

Confidence: 95% confidence
Finding: The configuration update example repeats the unsafe pattern of collecting a new AppKey through conversational exchange, reinforcing insecure secret-handling behavior. Repetition in documentation makes unsafe collection more likely to be implemented by downstream agents exactly as shown, amplifying credential exposure risk.

VirusTotal

66/66 vendors flagged this skill as clean.

View on VirusTotal

Static analysis

Detected: suspicious.destructive_delete_command

Documentation contains a destructive delete command without an explicit confirmation gate.

Warn

Code: suspicious.destructive_delete_command
Location: INSTALL.md:289