CVE-2026-102682

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.

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.

Pipecat’s built-in development runner exposes endpoints that create bot sessions and, for the Daily transport, paid Daily rooms. These development endpoints intentionally do not authenticate callers.

The runner binds to localhost by default and is designed exclusively for local development. It is not built or supported as a production server. Exploitation therefore requires an operator to deliberately make the development runner reachable from an untrusted network, such as by setting --host 0.0.0.0, publishing its port, or using a public tunnel without access controls.

If exposed in this way, an unauthenticated caller may invoke endpoints including /start, /daily, and /daily-dialin-webhook. Depending on the endpoint and configuration, this can create a bot session or Daily room and may return a room URL and join token. Repeated requests may also consume local resources and third-party service quotas.

The consequences of interacting with a launched bot depend on that bot’s configuration and connected tools. Access to external systems or sensitive information is not an inherent capability of the development runner and is therefore not included as a general impact.

Pipecat 1.6.0 clarifies this security boundary in two ways:

• The development runner displays a prominent startup banner identifying it as a development tool.
• The documentation explicitly states that the runner must not be used as a production server or exposed directly to untrusted traffic.

The local development documentation (https://docs.pipecat.ai/pipecat/deployment/running-bots-locally) identifies the unauthenticated endpoints, lack of rate limiting, and risks of public exposure. The production deployment documentation (https://docs.pipecat.ai/pipecat/deployment/running-bots-in-production) directs users to a production dispatcher or managed runtime and describes minimum protections for limited prototype use.

Resolution

Pipecat 1.6.0 documents and surfaces the intended security boundary of the development runner. The unauthenticated development behavior remains by design. Users must not expose the runner directly to untrusted networks; production deployments require an authenticated dispatcher or managed runtime.

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.

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.

Pipecat’s built-in development runner exposes endpoints that create bot sessions and, for the Daily transport, paid Daily rooms. These development endpoints intentionally do not authenticate callers.

The runner binds to localhost by default and is designed exclusively for local development. It is not built or supported as a production server. Exploitation therefore requires an operator to deliberately make the development runner reachable from an untrusted network, such as by setting --host 0.0.0.0, publishing its port, or using a public tunnel without access controls.

If exposed in this way, an unauthenticated caller may invoke endpoints including /start, /daily, and /daily-dialin-webhook. Depending on the endpoint and configuration, this can create a bot session or Daily room and may return a room URL and join token. Repeated requests may also consume local resources and third-party service quotas.

The consequences of interacting with a launched bot depend on that bot’s configuration and connected tools. Access to external systems or sensitive information is not an inherent capability of the development runner and is therefore not included as a general impact.

Pipecat 1.6.0 clarifies this security boundary in two ways:

• The development runner displays a prominent startup banner identifying it as a development tool.
• The documentation explicitly states that the runner must not be used as a production server or exposed directly to untrusted traffic.

The local development documentation (https://docs.pipecat.ai/pipecat/deployment/running-bots-locally) identifies the unauthenticated endpoints, lack of rate limiting, and risks of public exposure. The production deployment documentation (https://docs.pipecat.ai/pipecat/deployment/running-bots-in-production) directs users to a production dispatcher or managed runtime and describes minimum protections for limited prototype use.

Resolution

Pipecat 1.6.0 documents and surfaces the intended security boundary of the development runner. The unauthenticated development behavior remains by design. Users must not expose the runner directly to untrusted networks; production deployments require an authenticated dispatcher or managed runtime.