ClawHub
Back to skill

Security audit

qwenspeak

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly transparent about sending TTS data over SSH, but its setup path asks users to run an unauthenticated remote installer as root.

Install only if you trust the publisher and the SSH server you will use. Before running the setup, pin the installer to an immutable commit or verify a signed checksum, review exactly what sudo will do, use a dedicated SSH key, confirm the server host key out of band, and avoid sending voice samples unless you have explicit consent from the speaker.

A.I.G

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
Findings (3)

T03 · Remote Payload Retrieval and Execution

Error
Location
references/setup.md:13
Finding

Unverified Remote Installer Executed with Root Privileges

Content
View full analysis

Vulnerability Details

File Location: references/setup.md, lines 13-19
Vulnerability Type: Remote payload retrieval and privileged execution
Risk Level: High

Vulnerable Code

bash
# Pick a released tag: https://github.com/psyb0t/docker-qwenspeak/releases
REF=vX.Y.Z
curl -fsSL "https://raw.githubusercontent.com/psyb0t/docker-qwenspeak/${REF}/install.sh" -o install.sh
less install.sh            # review exactly what runs as root
sudo bash install.sh

Technical Analysis

The setup instructions download a shell script from an external personal GitHub repository and direct the operator to execute it with sudo. Selecting a release tag reduces accidental exposure to changes on the main branch, but Git tags can be deleted or moved unless their integrity is independently verified. The instructions do not validate a cryptographic signature, trusted checksum, or immutable commit identity.

Manual inspection with less is a useful precaution but does not provide machine-verifiable integrity and does not ensure that an operator will detect subtle malicious behavior. The downloaded script is outside the audited project, so its effective behavior can differ from the code reviewed here.

Executing the installer as root exceeds the privileges needed by the client-side SSH wrapper itself. Elevated installation may be necessary for operations such as placing a command in /usr/local/bin or provisioning Docker resources, but the setup does not isolate those operations from the rest of the downloaded script.

Attack Path

  1. An attacker compromises the upstream repository, a maintainer account, release process, or referenced tag.
  2. The attacker replaces or retargets the referenced install.sh with malicious content.
  3. An operator follows the documented setup procedure and downloads the modified script.
  4. No checksum or signature validation detects the substitution.
  5. The operator executes `sudo ...[truncated 543 chars]
Remediation
View remediation

Remediation Suggestions

  • Include a reviewed installer in the Skill package rather than retrieving executable code at installation time.
  • If remote retrieval is unavoidable, pin the download to an immutable commit hash rather than a mutable tag.
  • Publish a SHA-256 digest through a separately authenticated release channel and verify it before execution.
  • Prefer signed release artifacts and validate the signature against a documented, pinned maintainer key.
  • Fail closed if checksum or signature verification fails.
  • Split privileged and unprivileged installation steps. Use elevation only for narrowly scoped operations that genuinely require it.
  • Avoid executing a large downloaded script as root; install files with explicit commands and restrictive ownership and permissions.
  • Document the exact privileged changes made by the installer so operators can review their necessity.

T08 · Insecure Dependencies

Warning
Location
references/setup.md:25
Finding

Unpinned Python Package Installation

Content
View full analysis

Vulnerability Details

File Location: references/setup.md, line 25
Vulnerability Type: Unpinned third-party dependency installation
Risk Level: Medium

Vulnerable Code

bash
pip install -U "huggingface_hub[cli]"

Technical Analysis

The setup procedure installs the latest available version of huggingface_hub and its transitive dependencies. Neither package versions nor artifact hashes are pinned. The -U option further encourages resolution to whichever releases are current when the command is run.

This prevents reproducible dependency resolution and expands the supply-chain trust boundary beyond the versions reviewed by the project. A compromised upstream release, compromised package registry account, malicious transitive dependency, or unexpected incompatible update could introduce arbitrary installation-time or runtime behavior.

The command does not explicitly use sudo, so root compromise is not inherent. The obtained privileges depend on the account and Python environment used to run pip.

Attack Path

  1. An attacker compromises a relevant package, maintainer account, release pipeline, or transitive dependency.
  2. A malicious or vulnerable release becomes the version selected by the unconstrained dependency resolver.
  3. An operator runs the documented pip install -U command.
  4. The package is installed without checking an approved version or artifact hash.
  5. Malicious installation or runtime code executes with the privileges of the operator running pip.

Impact Assessment

Exploitation can provide code execution under the installing user's account and can affect files, tokens, Python environments, and data accessible to that account. If the command is run in a privileged system environment, the scope can increase accordingly. It can also compromise subsequent model downloads or alter their destinations and contents.

Remediation
View remediation

Remediation Suggestions

  • Pin huggingface_hub and all transitive dependencies to versions reviewed and tested by the project.
  • Use a lock file or hash-locked requirements file with --require-hashes.
  • Install dependencies in a dedicated virtual environment rather than a system Python environment.
  • Remove -U from routine setup instructions to avoid silently accepting future releases.
  • Establish a controlled dependency-update process that includes security review and compatibility testing.
  • Where practical, verify downloaded model artifacts against trusted checksums or signed manifests as well.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/qwenspeak.sh:12
Finding

SSH Host Identity Is Automatically Trusted on First Connection

Content
View full analysis

Vulnerability Details

File Location: scripts/qwenspeak.sh, lines 12-16
Vulnerability Type: Insecure SSH trust-on-first-use configuration
Risk Level: Medium

Vulnerable Code

bash
exec ssh -p "$QWENSPEAK_PORT" \
    -o StrictHostKeyChecking=accept-new \
    -o LogLevel=ERROR \
    "tts@$QWENSPEAK_HOST" "$*"

Technical Analysis

StrictHostKeyChecking=accept-new automatically records and trusts a previously unknown SSH host key. It protects against a changed key after the first successful connection, but it does not authenticate the server during that initial connection.

This is material because the wrapper intentionally transmits TTS text, YAML job definitions, transcripts, and uploaded audio—including potentially biometric voice samples—to the configured host. An attacker capable of intercepting or redirecting the first connection could present a substitute SSH server whose key is automatically accepted.

The setting does not expose the client's private SSH key: SSH authentication signs protocol data rather than transmitting the private key. The primary risk is server impersonation and disclosure or manipulation of session data during the first connection.

Attack Path

  1. A user configures a legitimate QWENSPEAK_HOST but has not previously connected to it.
  2. An attacker gains a network interception, DNS spoofing, routing, or equivalent redirection position.
  3. The attacker presents an SSH host key from a substitute server.
  4. accept-new automatically accepts and stores that key because no prior key exists.
  5. The user submits text, YAML, transcripts, or audio to the attacker-controlled endpoint.
  6. The attacker can collect the submitted data and return forged command results or generated files.

Impact Assessment

Successful exploitation may disclose sensitive text, job configuration, transcripts, and biometric voice recordings. It may also permit response spoofing or c ...[truncated 213 chars]

Remediation
View remediation

Remediation Suggestions

  • Obtain the server host-key fingerprint through an authenticated out-of-band channel before the first connection.
  • Store the expected key in a dedicated known-hosts file distributed or provisioned securely for this service.
  • Invoke SSH with StrictHostKeyChecking=yes and a dedicated UserKnownHostsFile.
  • Consider binding host-key records to both the configured host and nonstandard port.
  • Fail closed when the expected host key is missing or mismatched.
  • Document a secure host-key rotation process rather than reverting to automatic first-use trust.
  • Continue warning users that text and voice samples leave the local host and should be sent only to a verified service.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (6)

Credential Access

High
Category
Privilege Escalation
Confidence
90% confidence
Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · references/setup.md (reported line 48)May include surrounding context.

bash
# Add your SSH key
cat ~/.ssh/id_rsa.pub >> ~/.qwenspeak/authorized_keys

# CPU mode
qwenspeak start -d -m /path/to/models

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
75% confidence
Finding

Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Content

Scanner excerpt · SKILL.md (reported line 20)May include surrounding context.

md
- **Voice cloning requires consent.** Reference audio (`ref_audio`) is
  biometric data of a real person's voice — only clone a voice you have
  explicit consent for. Cloning someone's voice without consent enables
  impersonation and fraud; never clone from audio scraped or supplied
  without the speaker's permission, and never use a clone to impersonate
  a specific named individual without their say-so. See

External Transmission

Medium
Category
Data Exfiltration
Confidence
95% confidence
Finding

The setup instructions fetch an installer script from the network and then execute it as root. Although the text advises pinning to a release tag and reviewing the script first, this still normalizes a dangerous supply-chain pattern where a compromised GitHub account, tag, repository, or reviewed-but-misunderstood script could result in full host compromise.

Content

Scanner excerpt · references/setup.md (reported line 17)May include surrounding context.

bash
# Pick a released tag: https://github.com/psyb0t/docker-qwenspeak/releases
REF=vX.Y.Z
curl -fsSL "https://raw.githubusercontent.com/psyb0t/docker-qwenspeak/${REF}/install.sh" -o install.sh
less install.sh            # review exactly what runs as root
sudo bash install.sh

Sudo/Root Execution

Medium
Category
Privilege Escalation
Confidence
92% confidence
Finding

The documentation instructs users to run the installer with sudo bash, granting the downloaded script full root privileges on the host. In context this is operationally intentional, but if the installer is malicious, compromised, or overly broad, it can modify system files, persistence mechanisms, SSH access, or container configuration with complete control.

Content

Scanner excerpt · references/setup.md (reported line 19)May include surrounding context.

REF=vX.Y.Z curl -fsSL "https://raw.githubusercontent.com/psyb0t/docker-qwenspeak/${REF}/install.sh" -o install.sh less install.sh # review exactly what runs as root sudo bash install.sh

text

## Models

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The wrapper forwards arbitrary user-supplied arguments directly to ssh as a remote command via "$*", effectively turning a TTS skill into a general remote command runner on the target host. In the context of a narrowly described text-to-speech skill, this materially expands capability and could let a caller execute unintended commands, access other data on the remote system, or misuse the tts account if upstream controls are weak.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Low
Category
Not specified by scanner
Confidence
83% confidence
Finding

The manifest describes a text-to-speech skill, but this script depends on environment-provided connection details to reach a remote SSH service. Reading deployment configuration is not mentioned in the manifest and is not itself part of generating speech, cloning voices, or voice design.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.