Pipecat: Public exposure of Pipecat’s development runner can allow unauthenticated bot session creation

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.