If your company is running an AI-powered voice assistant or conversational chatbot built on Pipecat, a hacker on the internet may be able to walk right into your server and take complete control — no password required.
Who's at Risk — and How Many
Pipecat is an open-source Python framework built by Daily.co and widely adopted for constructing real-time voice agents, customer service bots, and multimodal AI assistants — the kind of software increasingly fielded by startups and enterprises alike to handle phone calls, support tickets, and live voice interactions. The framework has racked up thousands of deployments across the AI developer ecosystem, and it sits at the infrastructure layer of products that real customers interact with every day.
The vulnerability, tracked as CVE-2025-62373, affects every version of Pipecat from 0.0.41 through 0.0.93 — a wide swath of the framework's release history spanning well over a year of production deployments. Any organization running a Pipecat server in those version ranges that has LiveKit integration enabled is potentially exposed to complete server takeover from the internet, with no authentication required from the attacker.
What an Attacker Can Actually Do
Here's the scenario in plain terms. You've built an AI voice agent — maybe it answers customer calls, maybe it powers an internal helpdesk tool. Under the hood, your Pipecat server is listening for incoming connections over a WebSocket, which is the persistent, two-way communication channel that allows real-time audio and conversation data to flow between users and your AI. Normally, the people connecting to that WebSocket are your legitimate users or your own internal systems.
But because of this flaw, a malicious actor doesn't need to be a legitimate user. They just need to be able to reach your server's WebSocket port — which, for any internet-facing deployment, is trivially achievable. Once they connect, they can send a carefully crafted data packet. Your server will receive that packet, try to process it as a normal message, and in doing so will execute whatever instructions the attacker hid inside it. We're talking about the ability to install malware, steal encryption keys and API credentials, pivot deeper into your internal network, destroy data, or conscript your server into a botnet. The entire machine is forfeit.
The especially troubling part is how silent and clean this attack looks. The attacker doesn't have to break down any doors. They knock, hand your server a poisoned envelope, and your server opens it and follows the instructions inside — all without any alarms going off. There are no failed login attempts to detect, no suspicious authentication events to trigger your monitoring. From the outside, it looks like normal traffic.
The Technical Anchor: Unsafe Pickle Deserialization via WebSocket
For security researchers, the vulnerability class here is a textbook — and particularly dangerous — instance of unsafe deserialization (CWE-502). Specifically, the flaw lives inside a class called LivekitFrameSerializer, which contains a deserialize() method that calls Python's native pickle.loads() directly on raw data received from WebSocket clients, with zero validation, sanitization, or allowlist enforcement applied beforehand.
Python's pickle module is a known landmine in security circles — its own official documentation warns developers never to unpickle data received from untrusted sources, because pickle payloads can execute arbitrary Python code during the deserialization process itself, before any application-level logic has a chance to inspect or reject them. This is a pre-auth, network-reachable, zero-click remote code execution primitive. The CVSS score is 9.8 out of 10 (Critical), reflecting the network attack vector, low attack complexity, no privileges required, and no user interaction needed. This is about as bad as it gets on paper.
Context: Discovery, Exploitation Status, and What We Know
The Pipecat project has marked the vulnerable LivekitFrameSerializer class as deprecated and undocumented — meaning it was an optional, non-default component that developers had to deliberately opt into, which somewhat limits the attack surface compared to a flaw in a default-on feature. That's a meaningful caveat: not every Pipecat deployment is vulnerable, only those that specifically implemented LiveKit integration using this serializer class.
That said, the word "undocumented" cuts both ways. Because the component was undocumented, developers who used it may not have understood its risks, and may not be watching closely for security advisories related to it. As of publication, no active exploitation has been confirmed in the wild, but security teams should treat "not yet exploited" as a narrow window, not a clean bill of health. The vulnerability is now public, the affected version range is clearly defined, and the attack technique — pickle deserialization over WebSocket — is well-understood and easy to weaponize by anyone with intermediate Python skills. The race between patching and exploitation is now officially on.
What You Should Do Right Now
Three concrete steps, in order of urgency:
-
Upgrade Pipecat to version 0.0.94 or later immediately. This is the fixed release. If you are running anything between 0.0.41 and 0.0.93, you are in the vulnerable window. Run
pip install --upgrade pipecat-aiand confirm your installed version withpip show pipecat-ai. Do not wait for a scheduled maintenance window on this one — the CVSS score and the public nature of the flaw warrant emergency patching. -
Audit your codebase for any use of
LivekitFrameSerializer. Search your entire codebase — including any infrastructure-as-code configs and deployment scripts — for references toLivekitFrameSerializer. If you find it, rip it out. The class is deprecated and should not exist in any production deployment going forward, regardless of whether you've patched. Grep command:grep -r "LivekitFrameSerializer" . - Restrict WebSocket access at the network level as a defense-in-depth measure. Even after patching, review your firewall and load balancer rules to ensure your Pipecat server's WebSocket endpoint is not unnecessarily exposed to the open internet. Use authenticated reverse proxies, restrict by IP range where possible, and enable logging on WebSocket connection events so you have visibility if anomalous connection patterns emerge. If you have a Web Application Firewall, verify it is inspecting WebSocket traffic, not just HTTP.
Bottom line: CVE-2025-62373 is a critical, pre-authentication remote code execution vulnerability in a widely-used AI voice framework. The attack requires no special skills and leaves no obvious footprints. If Pipecat is anywhere in your stack, treat this as a fire drill: patch today, audit your code, and lock down your network perimeter.