Development Runner Exposed to Untrusted Networks Allows Unauthenticated Bot Session Creation

The Pipecat development runner exposes two endpoints with no authorization check:

• POST /start — Spawns the full AI pipeline (LLM, TTS, transport). Returns session credentials or a Daily.co room URL.
• GET /daily — Creates or retrieves a Daily.co room for the session.

Neither endpoint performs any authentication, API key check, or token verification. The entire access control surface is the bind address: the runner is expected to listen on 127.0.0.1 where only the local developer can reach it. When that boundary fails, the endpoints are open to every caller on the reachable network.

Four common developer workflows break the boundary:

Once the development server is reachable, exploitation is a single unauthenticated HTTP request:

The direct impact is financial: each unauthorized /start call initiates a metered session across every AI provider in the pipeline. An attacker running repeated requests can escalate costs continuously. The operator receives no indication until API invoices arrive or provider quotas are exhausted.

Secondary impacts depend on the bot configuration: if the pipeline handles sensitive data, unauthorized sessions may expose that data to the attacker; if the bot executes tool calls or sends outbound messages, those actions are triggered on the attacker’s behalf.

Upgrade to pipecat-ai ≥ 1.6.0, which adds authentication controls to the development runner. As defence-in-depth regardless of version, bind the server to localhost and avoid publishing dev ports: