Back to skill

Security audit

Local Vosk STT

Security checks for vulnerabilities and agentic risk

Overview

This is a simple local speech-to-text skill with disclosed setup steps; its main risk is ordinary supply-chain exposure from installing Vosk and downloading a model without pinning or checksum verification.

Before installing, use a dedicated virtual environment instead of --break-system-packages, pin the Vosk package, and verify the downloaded model archive with a trusted checksum. Also confirm the missing transcribe script is supplied elsewhere, because this artifact alone only documents commands and setup.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:40
Finding
Unpinned Python Dependency Installation Bypasses System Package Protections## Vulnerability Details **File Location**: `SKILL.md`, line 40 **Vulnerability Type**: Unpinned third-party dependency installed with weakened package-management safeguards **Risk Level**: Medium **Vulnerable Code Snippet**: ```bash pip3 install vosk --user --break-system-packages ``` ### Technical Analysis The setup instructions install the mutable, unpinned `vosk` package and its transitive dependencies from the user's configured Python package index. Because no exact version or cryptographic hashes are specified, the code retrieved during installation can change after the skill has been reviewed. The `--break-system-packages` option explicitly overrides protections intended to prevent `pip` from interfering with an externally managed Python environment. Although `--user` limits installation to the current account in typical configurations, this combination can still introduce incompatible or attacker-controlled packages into the user's Python import path. Package installation and subsequent imports may execute package-controlled Python code. Exploitation therefore depends on compromise of the package, one of its dependencies, the configured package index, or dependency resolution. ### Attack Path 1. An attacker compromises a resolved package or dependency, publishes a malicious future release, or controls a package source configured on the target. 2. A user follows the documented setup command without specifying a reviewed version or hash. 3. `pip` resolves and downloads the attacker's package content. 4. Package-controlled code runs during installation or when the installed module is subsequently imported. 5. The payload executes with the privileges of the user running `pip`. ### Impact Assessment Successful exploitation could provide arbitrary code execution under the installing user's account. This may expose files, credentials, environment variables, and other resources accessible to that account. It could ...[truncated 269 chars]
Remediation
## Remediation Suggestions - Create and activate a dedicated virtual environment instead of modifying an externally managed Python environment. - Remove `--break-system-packages`. - Pin `vosk` and all transitive dependencies to reviewed versions in a lock file. - Require package hashes, such as through `pip install --require-hashes -r requirements.txt`. - Use a trusted, explicitly configured package index and retain reviewed dependency artifacts where practical. - Add dependency vulnerability and provenance checks to the release process. - Document the installation procedure, for example: ```bash python3 -m venv ~/.venvs/local-vosk ~/.venvs/local-vosk/bin/python -m pip install --upgrade pip ~/.venvs/local-vosk/bin/python -m pip install --require-hashes -r requirements.txt ```

T08 · Insecure Dependencies

Warning
Location
SKILL.md:43
Finding
Downloaded Model Archive Is Extracted Without Integrity Verification## Vulnerability Details **File Location**: `SKILL.md`, lines 43–45 **Vulnerability Type**: Unverified external model dependency **Risk Level**: Medium **Vulnerable Code Snippet**: ```bash mkdir -p ~/vosk-models && cd ~/vosk-models wget https://alphacephei.com/vosk/models/vosk-model-small-en-us-0.15.zip unzip vosk-model-small-en-us-0.15.zip ``` ### Technical Analysis The instructions download a third-party model archive and immediately extract it without checking a cryptographic digest or digital signature. HTTPS protects the connection in transit when certificate validation and the local trust store remain secure, but it does not independently establish artifact integrity if the hosting service, publishing account, DNS/trust infrastructure, or upstream artifact is compromised. The archive is also trusted before its member paths are inspected. Malicious archive entries could attempt to place files outside the intended extraction directory, subject to the behavior and protections of the installed `unzip` implementation. The extracted model is later consumed by software outside the audited project, so malformed model data could also exercise vulnerabilities in that software. No malicious archive or parser vulnerability was present in the audited material; these are the exploitation conditions created by the missing verification step. ### Attack Path 1. An attacker compromises the model host or distribution process, or otherwise causes the download URL to return an altered archive. 2. A user executes the documented `wget` command. 3. Because no expected checksum or signature is checked, the altered archive is accepted. 4. The user extracts the archive into `~/vosk-models`. 5. Malicious archive paths may overwrite user-accessible files if the extraction utility permits them, or crafted model content may be processed later by Vosk. 6. Any resulting access is bounded initially by the privileges of the user performin ...[truncated 520 chars]
Remediation
## Remediation Suggestions - Publish a trusted SHA-256 or stronger digest for the exact model archive. - Verify the digest before extraction and stop immediately on mismatch. - Prefer a cryptographically signed manifest and verify its signature using a pinned publisher key. - Download to a newly created temporary directory and inspect archive member paths before extraction. - Reject absolute paths, parent-directory traversal entries, symlinks, and unexpected files. - Extract with restrictive permissions into a dedicated model directory. - Pin the expected archive URL, filename, version, size, and digest in the skill documentation. Example checksum verification: ```bash wget -O vosk-model-small-en-us-0.15.zip \ https://alphacephei.com/vosk/models/vosk-model-small-en-us-0.15.zip echo 'EXPECTED_SHA256 vosk-model-small-en-us-0.15.zip' | sha256sum --check --strict - unzip vosk-model-small-en-us-0.15.zip ``` Replace `EXPECTED_SHA256` with a digest obtained through a trusted publisher-controlled channel.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.