[Self-Hosted] Hidden Callers in Voice Channels - Livekit

(#701) Bug Needs triage privacy self-hosting voice

Summary

I will note, this is not exactly an bug, its more design/privacy gap/feature request/point of awareness. To continue, anyone with livekit-cli/api access can create access tokens to voice calls that are not visible to fluxer app/web users. While I would be obvious that generally speaking that livekit can do this, not being obvious to end-users is my issue here. As you can see in the screenshot below, I "fish-crested" is connected using the fluxer browser, but if I have used the livekit client, you can see my "guest-hacker" user and "fish-crested". To confirm, I spoke as "guest-hacker" I was heard by "fish-crested". To be clear, for private servers, this has valid uses. BUT the user should be aware that someone can hear potentially hear them. I have not tried to see how E2EE goes, but as the is a function of livekit, if the key sharable, then its findable, then it could still potentially work. An additional thing I have not yet tested is Direct Calling and how that is facilitated. I did discuss with Security Team before making this post.

Steps to reproduce

with livekit-cli:
lk create-token   --api-key abc --api-secret 123   --join --room guild_[guild-id]_channel_[channel-id]   --identity guest-hacker   --valid-for 1h
With give access token go to: https://meet.livekit.io/?tab=custom Livekit Server URL: wss://[fluxer-instance-fqdn]/livekit Token: As generated.

Environment

As per operator guide with docker on ubuntu 26.04 Client: Stable Web 2026.702.14514, Windows NT 10.0 (x64), Microsoft Edge 149.0.0.0, Locale en-US

Logs or screenshots

image
  • 616876025-4c126c56-3b5a-44e5-bd6c-3d42e784fbe6.png

    616876025-4c126c56-3b5a-44e5-bd6c-3d42e784fbe6.png

    2940×1230 | 434 kB

5 comments

Sign in with Fluxer to comment and vote.
Comment by @mcd1992
RexSystem 1 vote originally by @mcd1992 on GitHub
E2EE does prevent listening in but it looks like E2EE clients don't require other clients to have encryption. So you can talk to other clients but not listen in without the key. Might want to require e2ee clients to only output audio from other e2ee clients and ignore unencrypted audio. I don't know much about livekit or e2ee setups but I did notice the server gateway is handing out the e2ee keys. Not sure if that's just a shared secret for the clients to then negotiate their own actual keys or how livekit does its PBKDF2 magic but might need a better audit on the e2ee voice long term.
Comment by Hampus
HampusStaff 1 vote originally by @hampus-fluxer on GitHub
This is getting changed already to be 1:1 compatible with Discord (we're removing LiveKit), and all remaining bugs involved here are getting fixed along with it. That's what I've been working on for the past month.
Comment by @CAMongrel
RexSystem 1 vote originally by @CAMongrel on GitHub
This is getting changed already to be 1:1 compatible with Discord (we're removing LiveKit), and all remaining bugs involved here are getting fixed along with it. That's what I've been working on for the past month.
Could you elaborate on this? What's the replacement for LiveKit and what does 1:1 compatibility with Discord mean?
Comment by @vesaber
RexSystem 1 vote edited originally by @vesaber on GitHub
> This is getting changed already to be 1:1 compatible with Discord (we're removing LiveKit), and all remaining bugs involved here are getting fixed along with it. That's what I've been working on for the past month. Could you elaborate on this? What's the replacement for LiveKit and what does 1:1 compatibility with Discord mean?
hampus wrote a custom SFU thats compatible with @discordjs/voice (or libraries that interact with discords vc capability). 1:1 in this case means that the API is pretty much the same as discords.
Deleted comment
Removed by moderator Rex: Removed a general status note that was posted on many GitHub threads. It no longer applies here.
Comment by @thefathacker
RexSystem 1 vote originally by @thefathacker on GitHub OP
I will note, there was a use case that was raised with me after I raised this:
  • Allowing voice channel access via one of timed guest urls without needing to create an account for a converance or other large meeting hosted by users of fluxer via the livekit client.
But I otherwise agree evict would be the most secure option