Skillv2.0.1

ClawScan security

mediaproc · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousMar 30, 2026, 11:53 AM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill's described purpose (remote media processing over SSH) matches the included commands, but there are inconsistencies and some risky installation/usage recommendations you should understand before installing.
Guidance: This skill appears to do what it says (run media tools inside a remote container over SSH), but there are some practical and security issues to consider before using it: - Environment mismatch: The registry metadata does not declare MEDIAPROC_HOST and MEDIAPROC_PORT, yet the script and SKILL.md require them. Expect to set these to point at a trusted mediaproc server you control. - SSH risks: The provided wrapper will automatically accept new host keys (StrictHostKeyChecking=accept-new). That simplifies first-time use but increases the risk of a man-in-the-middle attack. Prefer to verify host keys manually or use known_hosts management. - Install recommendation is risky: references/setup.md suggests piping a GitHub raw install.sh into sudo bash. Do NOT run that blind. Inspect the install.sh contents locally (git clone or curl to a file and review) before running, or build/run the container yourself. - Trust the remote host: Media and file uploads are sent to the mediaproc server; a compromised or malicious server can read/exfiltrate uploaded files or execute arbitrary commands. Only point MEDIAPROC_HOST at a host you control or fully trust. - Mitigations: review the install script, run the mediaproc container locally if possible, use an ephemeral SSH key restricted to the mediaproc instance, verify host keys, and avoid using sudo piping from the web. If you need stronger assurance, ask the publisher for signed releases or source code you can audit. If the publisher updates the registry metadata to declare the required env vars and removes or documents safer install steps (no sudo curl|bash), the incoherence and install risk would be resolved and my confidence would increase.

Review Dimensions

Purpose & Capability: concernThe SKILL.md requires MEDIAPROC_HOST and MEDIAPROC_PORT and SSH access to a mediaproc instance, but the registry metadata lists no required env vars or credentials — that mismatch is incoherent. Otherwise the commands and wrapper script align with the stated media-processing purpose.
Instruction Scope: noteRuntime instructions allow uploading files and running arbitrary media commands on a remote container via SSH, which is consistent with the purpose. However the wrapper uses ssh with StrictHostKeyChecking=accept-new (automatic acceptance of new host keys), which raises MITM risk. The instructions also point users to running an install script that provisions SSH keys and a local mediaproc host; those setup directions increase the attack surface if the remote image or install script is untrusted.
Install Mechanism: concernThere is no formal install spec in the registry, but references/setup.md tells users to run curl -fsSL https://raw.githubusercontent.com/psyb0t/docker-mediaproc/main/install.sh | sudo bash. Piping a remote script to sudo bash is a high-risk recommendation even when hosted on GitHub raw; it can run arbitrary code as root. The skill itself doesn’t install code, but the provided setup guidance is risky.
Credentials: concernThe skill does not declare required env vars in the registry metadata, yet both SKILL.md and scripts/mediaproc.sh require MEDIAPROC_HOST and MEDIAPROC_PORT. That inconsistency hides the fact that the agent/user must supply network endpoints and SSH access (and will expose file transfer through that channel). No API keys are requested, which is appropriate, but the missing declared env vars is misleading.
Persistence & Privilege: okThe skill is not always-enabled and does not request system-level privileges in the registry. The wrapper is a simple SSH proxy and does not modify other skills or agent config. Autonomous invocation is allowed (default) but that is normal behavior and not by itself a concern.