GHSA-hqm2-cfx2-2vgh: Medium severity pip/pipecat-ai vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/pipecat-aito a version that resolves this vulnerability.Fixed in 1.6.0 - Compensating control
Do not expose the development runner directly to untrusted networks; keep it bound to localhost rather than setting --host 0.0.0.0 or publishing its port without access controls. For production deployments, use an authenticated dispatcher or managed runtime.
Event History
Frequently Asked Questions
Is a default development-runner setup exposed to remote attackers?
No. The runner binds to localhost by default, so remote exploitation requires an operator to deliberately expose it to an untrusted network.
What must an attacker be able to do to exploit this?
They need network access to an exposed development-runner port or publicly accessible tunnel. The affected development endpoints intentionally do not require caller authentication.
What can an unauthenticated caller do through an exposed runner?
They may invoke endpoints including /start, /daily, and /daily-dialin-webhook to create bot sessions or, with the Daily transport, paid Daily rooms. Depending on configuration, responses may include a room URL and join token; repeated requests can also consume local resources and third-party quotas.
What should be done if updating is not immediately possible?
Keep the development runner bound to localhost and do not publish its port to untrusted networks. If a tunnel is necessary, ensure it has access controls rather than making the runner publicly reachable.
How can I determine whether my environment is at risk?
Check whether a development runner has been started with --host 0.0.0.0, had its port published, or has been placed behind a public tunnel without access controls. Environments limited to localhost are not remotely reachable through this issue.