LiveKit Voice AI

• Outcome: Pass
• Latest audit: Sep 10, 2026 · 6:54 PM UTC
• Version: 1.0.0

Overview

This is a coherent LiveKit voice-agent guide, with no hidden behavior, but users should treat its install, Docker, API-key, and outbound-calling examples carefully.

Before installing or copying examples, use isolated environments, pin reviewed package and container versions, avoid putting production secrets directly in shell history, and add explicit safeguards before any SIP code can dial real numbers.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:14
• Finding: Unpinned Python and Node.js Dependencies## Vulnerability Details **File Location**: `SKILL.md`, lines 14-17 **Vulnerability Type**: Unpinned third-party dependencies **Risk Level**: Medium ```bash # Install SDK pip install livekit-agents livekit-plugins-openai livekit-plugins-deepgram livekit-plugins-cartesia # Or Node.js npm install @livekit/agents @livekit/agents-plugin-openai ``` ### Technical Analysis The installation commands resolve third-party packages from package registries without exact version constraints, lockfiles, or integrity hashes. Consequently, the code installed when a user follows these instructions can change after the skill has been reviewed. The package names are consistent with the skill's declared LiveKit functionality, and there is no evidence that they are deliberately malicious or typosquatted. Nevertheless, relying on unconstrained registry resolution creates a supply-chain exposure: a compromised publisher account, malicious future release, registry compromise, or unexpected dependency update could introduce arbitrary code. Python packages may execute code during installation or subsequent import. Node.js packages can execute lifecycle scripts during installation. Such code runs with the permissions of the user invoking the package manager. ### Attack Path 1. An attacker compromises a referenced package, its publisher account, or a transitive dependency. 2. The attacker publishes a malicious release that satisfies the unconstrained installation request. 3. A user follows the installation commands in `SKILL.md`. 4. The package manager resolves and installs the malicious release. 5. Malicious installation hooks or imported package code execute with the installing user's privileges. 6. The payload may access files, environment variables, and credentials available to that user, including configured LiveKit or external provider API keys. ### Impact Assessment Successful exploitation could permit arbitrary code execution wi ...[truncated 390 chars]
• Remediation: ## Remediation Suggestions - Pin every direct dependency to an exact, reviewed version. - Supply lockfiles that capture transitive dependency versions. - Enable package integrity verification through hashes or registry-supported integrity metadata. - For Python, provide a hash-locked requirements file and install it using `pip install --require-hashes -r requirements.txt`. - For Node.js, commit a reviewed lockfile and recommend `npm ci` instead of unconstrained `npm install`. - Use trusted registries and consider restricting package installation to an approved internal mirror. - Run dependency vulnerability and provenance checks in CI. - Perform installations in an isolated virtual environment or container and avoid elevated privileges. - Use an automated, reviewed process for updating dependency pins and lockfiles.

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:116
• Finding: Mutable and Unpinned LiveKit Container Image## Vulnerability Details **File Location**: `SKILL.md`, lines 116-119 **Vulnerability Type**: Unpinned container dependency **Risk Level**: Medium ```bash docker run -d \ -p 7880:7880 -p 7881:7881 -p 7882:7882/udp \ -e LIVEKIT_KEYS="api-key: api-secret" \ livekit/livekit-server ``` ### Technical Analysis The deployment command references `livekit/livekit-server` without an immutable SHA-256 digest or even an explicit version tag. Docker therefore resolves a mutable registry image, effectively using the registry's current default tag. The image content retrieved during deployment can differ from the image available when the skill was audited. The referenced image is consistent with the skill's declared functionality, and the reviewed file contains no evidence that the image is currently malicious. However, compromise of the image publisher, registry, or mutable tag could cause users to execute attacker-controlled container code. The container also receives `LIVEKIT_KEYS` through its environment, making those credentials directly available to any process running inside a compromised image. ### Attack Path 1. An attacker compromises the container repository, publisher credentials, registry infrastructure, or the mutable default image tag. 2. The attacker replaces the resolved image with a malicious build. 3. A user executes the documented `docker run` command. 4. Docker downloads and starts the attacker-controlled image. 5. The malicious process reads `LIVEKIT_KEYS` from the container environment and may exfiltrate those credentials. 6. The process can misuse the container's network access and exposed service ports. Additional host impact would depend on the Docker runtime configuration and the presence of a separate container escape or daemon vulnerability. ### Impact Assessment Exploitation provides arbitrary code execution inside the deployed container and access to credentials and resources exposed to tha ...[truncated 454 chars]
• Remediation: ## Remediation Suggestions - Pin the container image to a reviewed version and immutable SHA-256 digest, for example `livekit/livekit-server@sha256:<verified-digest>`. - Verify image signatures and provenance before deployment. - Retrieve images only from an approved registry or controlled mirror. - Scan the pinned image for vulnerabilities and malware before release. - Avoid placing production secrets directly in command history; use Docker secrets or an external secret manager. - Run the container as a non-root user with a read-only root filesystem where compatible. - Drop unnecessary Linux capabilities and apply seccomp, AppArmor, or SELinux confinement. - Restrict outbound network access and expose only ports required by the deployment. - Establish a reviewed process for updating and re-pinning image digests.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The telephony snippet demonstrates creating an outbound SIP participant that dials a real phone number, but it provides no warning that executing it may place live calls, incur charges, or process personal communications data. In a voice-agent skill focused on telephony and realtime communications, this omission is more dangerous because users are likely to copy the example directly into production-like environments.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.