CVE-2026-102682: Pipecat: Public exposure of Pipecat’s development runner can allow unauthenticated bot session creation
Pipecat is an open-source Python framework for building real-time voice and multimodal conversational agents. From 0.0.98 until 1.6.0, the pipecat-ai package's built-in development runner exposes unauthenticated endpoints including /start, /daily, and /daily-dialin-webhook that can create bot sessions and Daily rooms. The runner binds to localhost by default and is intended only for local development, so exploitation requires an operator to expose it to untrusted traffic through --host 0.0.0.0, a published port, or a tunnel without access controls. An unauthenticated caller can consume local resources and third-party quotas and, depending on configuration, receive a room URL and join token. Version 1.6.0 adds a prominent development-runner banner and documentation that clarifies the unauthenticated boundary and directs production deployments to an authenticated dispatcher or managed runtime, while the endpoint behavior remains by design. This issue is fixed in version 1.6.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pipecat-aito a version that resolves this vulnerability.Fixed in 1.6.0 - Compensating control
Do not expose the development runner to untrusted traffic without access controls; use an authenticated dispatcher or managed runtime for production deployments.
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Deployments running the built-in development runner are exposed only if the runner has been made reachable by untrusted traffic, such as by using --host 0.0.0.0, publishing its port, or placing it behind a tunnel without access controls. The runner binds to localhost by default.
What can an unauthenticated attacker do if they can reach the runner?
They can call endpoints including /start, /daily, and /daily-dialin-webhook to create bot sessions and Daily rooms. This can consume local resources and third-party quotas and may expose a room URL and join token, depending on configuration.
Does upgrading change the endpoint authentication behavior?
Version 1.6.0 adds a prominent development-runner banner and documentation describing the unauthenticated boundary, but the endpoint behavior remains by design. For production, use an authenticated dispatcher or managed runtime rather than exposing the development runner.
What should be done if an immediate upgrade is not possible?
Do not expose the development runner to untrusted traffic. Restrict access to localhost or otherwise place access controls in front of any published port or tunnel.