CVE-2025-62373 : RCE Pipecat agents IA voix (pickle)

Les faits

Pipecat est un framework Python open source maintenu par Daily.co, largement adopté pour bâtir des agents conversationnels vocaux et multimodaux en temps réel : voicebots, copilots IA, plateformes de support client automatisé. Publiée fin avril 2026, l'advisory CVE-2025-62373 décrit une vulnérabilité d'exécution de code à distance critique affectant le sérialiseur LivekitFrameSerializer, une classe optionnelle et peu documentée dédiée à l'intégration avec LiveKit. La faille repose sur un usage non sécurisé du module pickle : la désérialisation de données contrôlées par un attaquant permet l'exécution arbitraire de code sur le serveur hébergeant l'agent vocal. Concrètement, tout flux entrant malveillant transitant par ce sérialiseur peut compromettre l'intégralité de l'infrastructure conversationnelle. Cet article détaille le mécanisme technique de l'exploitation, les versions concernées, les indicateurs de compromission à surveiller et les mesures correctives à déployer sans délai.

Le score CVSS 3.1 est calculé à 9.8 selon la base GitLab Advisories : vecteur AV:N/AC:L/PR:N/UI:N, perte totale de confidentialité, intégrité et disponibilité. Une simple charge pickle malveillante envoyée via WebSocket suffit à déclencher l'exécution de code Python arbitraire avec les privilèges du processus Pipecat.

La classe vulnérable est dépréciée et a été supprimée du dépôt avec la version 0.0.94. Les développeurs ayant intégré LiveKit doivent migrer vers LiveKitTransport, qui s'appuie sur le SDK officiel LiveKit et utilise Protocol Buffers pour le transport.

Impact et exposition

Les déploiements concernés exposent généralement un endpoint WebSocket publiquement accessible pour la téléphonie ou le chat vocal en temps réel. La compromission donne accès à toutes les clés API stockées dans l'environnement (OpenAI, Anthropic, Deepgram, ElevenLabs, Twilio), ainsi qu'aux flux audio, transcripts et conversations utilisateurs traversant l'agent. Sur un serveur mutualisé, l'attaquant peut pivoter vers les autres workloads d'IA hébergés.

Les écosystèmes IA conversationnels et voicebots construits sur Pipecat sont particulièrement exposés : centres de contact intelligents, assistants médicaux et juridiques, démos de produits IA. La majorité des déploiements n'exigent pas d'authentification WebSocket pour faciliter l'intégration front, ce qui maximise la surface d'attaque.

Recommandations immédiates (2)

• Mettre à jour pipecat-ai en version 0.0.94 ou ultérieure dans tous les environnements (pip install -U pipecat-ai).
• Auditer le code applicatif pour identifier toute utilisation de LivekitFrameSerializer et migrer vers LiveKitTransport selon le guide officiel.
• Implémenter une couche d'authentification (JWT, API key) sur les endpoints WebSocket exposés publiquement, indépendamment du correctif.
• Mettre en place un WAF ou un proxy applicatif filtrant les frames WebSocket non conformes au schéma attendu (Protocol Buffers ou JSON validé).
• Faire tourner le processus Pipecat avec un utilisateur non privilégié, dans un conteneur isolé sans accès au réseau interne sensible.

Détails techniques du vecteur d'attaque

La faille exploite le mécanisme natif de désérialisation de Python. Le module pickle reconstruit des objets à partir d'un flux d'octets contenant des opcodes exécutables, dont REDUCE, qui permet d'invoquer n'importe quelle fonction Python — y compris os.system ou subprocess.Popen — via la méthode magique __reduce__. En appelant pickle.loads() sur des données brutes reçues d'un client WebSocket sans liste blanche de classes autorisées, LivekitFrameSerializer.deserialize() permet à un attaquant distant de forger une charge qui exécute une commande arbitraire dès sa désérialisation, sans qu'aucune donnée applicative ne soit réellement traitée par la logique métier.

Le détail du score CVSS 3.1 (9.8) illustre la sévérité : AV:N (exploitable depuis le réseau, aucun accès local requis), AC:L (pas de condition particulière, l'exploit est fiable et reproductible), PR:N et UI:N (ni authentification ni interaction utilisateur), et un impact C:H/I:H/A:H car le code s'exécute avec les pleins privilèges du processus Pipecat, généralement lancé sans sandboxing ni conteneurisation renforcée dans les déploiements observés.

Un précédent classique dans l'écosystème IA/ML

Les vulnérabilités de désérialisation pickle constituent une classe de risque récurrente dans l'écosystème Python data science et IA : des CVE similaires ont déjà touché torch.load() de PyTorch, les artefacts de modèles MLflow, ou encore joblib. La documentation officielle de Python avertit depuis des années que « ne désérialisez jamais des données pickle provenant d'une source non fiable » — un principe régulièrement ignoré dans les frameworks IA où la rapidité de prototypage prime sur la validation d'entrée. Le cas Pipecat est aggravé par le fait que la classe vulnérable traitait des flux réseau publics (WebSocket), et non de simples fichiers de modèles locaux, ce qui la rend directement exploitable sans ingénierie sociale.

Recommandations immédiates

• Mettre à jour pipecat-ai vers la version 0.0.94 ou supérieure sans délai sur tous les environnements de production.
• Auditer le code source pour toute référence à LivekitFrameSerializer et migrer vers LiveKitTransport, qui repose sur Protocol Buffers et élimine toute désérialisation pickle côté réseau.
• En attendant la mise à jour, isoler les endpoints WebSocket exposés derrière un WAF filtrant les payloads binaires suspects et restreindre l'accès réseau par liste blanche d'IP.
• Faire tourner les clés API (OpenAI, Anthropic, Deepgram, ElevenLabs, Twilio) potentiellement exposées sur tout serveur ayant fait tourner une version vulnérable.

Comment savoir si je suis vulnérable ?

Vérifiez la version installée avec pip show pipecat-ai : toute version comprise entre 0.0.41 et 0.0.93 incluse est concernée. Un grep sur le code applicatif via grep -r "LivekitFrameSerializer" . permet de confirmer une utilisation effective de la classe vulnérable, y compris dans des dépendances internes ou des forks maintenus séparément.

Votre infrastructure est-elle exposée ?

Un test rapide consiste à cartographier les endpoints WebSocket exposés publiquement (via un scan de ports ou un inventaire d'infrastructure) et à vérifier lesquels servent des agents Pipecat en frontal, notamment derrière des load balancers cloud où l'exposition directe est parfois masquée par une architecture en microservices.