A LiveKit server on a public address still used the image's default API key and secret. The matching dashboard accepted a default basic-auth pair. With that keypair a caller who had no account could:
- List on the order of a hundred rooms, with a TURN password on every room.
- List participants in rooms they did not create.
- Mint subscribe tokens that the RTC validator accepted.
- Join a pre-existing foreign room and receive audio frames.
- List SIP outbound trunks. Credentials were present in the API where the dashboard HTML masked them.
Negative controls: no token was 401, a wrong secret was 401, a token with subscribe turned off received no audio frames. Positive: our own room and a foreign room both returned on the order of a thousand audio frames.
We listed trunks. We did not modify them. A recording call answered success. We did not start a new recording job. Some control calls (mute, kick, delete) answered 404 or 503 that day: reachable and authorized, not a torn-down call.
What we proved
An established RTC session on a room we did not create, with audio frames, from the default keypair. Reproduced from a clean state by a second pass.
What this is not
We do not claim a bounty was paid, and we do not name the parent organization. The fact is the default key on a public media server.
Why a scanner misses it
A default-credential check that stops at "dashboard returned 200" never joins a room and never counts audio frames. The first pass stopped at a WebSocket handshake that closed. The second pass finished the join.
Buyer takeaway: The RTC port is production. Image defaults on that port are a wiretap.
