"Is Jitsi Meet secure" is really two different questions, and most articles answer the wrong one. The software itself has a decent security track record for what it is, media is encrypted in transit by default, and CVEs get patched. The actual source of most incidents is configuration: a room anyone can create without logging in, a lobby that was never turned on, a server three versions behind on a patched vulnerability.
This is the checklist version: authentication, lobby mode, JWT, firewall ports, and the specific CVEs worth knowing about, not encryption internals (our E2EE guide covers that separately) but the misconfigurations that actually show up in incident reports.
Quick answer
Jump to a section
Is Jitsi Meet secure?
Depends what you mean by secure. Media is encrypted in transit via DTLS-SRTP by default, no configuration needed for that baseline. End-to-end encryption is available too, for calls under a certain participant count, which is a separate feature our E2EE deep dive covers in full. None of that protects you from the configuration mistakes below, though, encryption and access control are different problems, and most Jitsi security incidents are the second one, not the first.
If you're new to Jitsi generally, our intro to what Jitsi Meet actually is and our architecture breakdown cover the pieces this checklist assumes you already understand at a high level, Prosody handling auth, JVB routing media, and so on. For a deployment where every item on this checklist matters, not just the convenient ones, see our look at secure military communications with Jitsi Meet.
Locking down room creation
Two different settings get mixed up here, and they do different jobs.
The first is Prosody's restrict_room_creation. On a Jitsi server it sits on the conference MUC component, not the main VirtualHost, and it means only the server's admin account (Jicofo's focus user) can create the underlying chat room. Clients can't create rooms directly and skip Jicofo. Versions of jitsi-meet-prosody before 2.0.5963-1 didn't make sure this line was there, which is why it shows up in security advisories. The current package template looks like this:
Component "conference.meet.example.com" "muc"
restrict_room_creation = true
-- the lobby and breakout components set it too
-- and on the main VirtualHost:
admins = { "focus@auth.meet.example.com" }That line does not mean "only logged-in users can start a meeting". On a default install anyone who opens https://meet.example.com/anything gets a new meeting, because Jicofo creates it for them. To require a login, turn on authentication: JWT for new installs, LDAP if you already run a directory, and SSO through an identity provider on top of JWT. Our rundown of Jitsi's authentication methods compares them, and the LDAP setup guide walks through the directory route.
Jitsi Meet default password and room names
People search for a "Jitsi Meet default password vulnerability" expecting a hardcoded admin password. There isn't one. The problem is the opposite: a new room has no password at all. The room name in the URL is the only thing between a stranger and your call, so /standup or /sales-weekly on a public server is effectively an open door.
- Use long random room names for anything private. The Jitsi web UI generates these if you don't type your own.
- Set a room password or enable the lobby. One of the two, every time, for meetings that matter.
- Turn on
enableInsecureRoomNameWarning: truein config.js. It shows a warning when a room name looks simple and the room has neither a password nor a lobby. - On your own server, require authentication to create rooms (above), so a guessed name only gets someone into the waiting room, not a fresh meeting.
Using lobby mode correctly
Lobby mode holds participants in a waiting area until a moderator admits them, the standard fix for "randoms joining a call." It's genuinely effective, but worth knowing about a real logic flaw that existed in versions before 9391 (CVE-2024-33530): a password-protected room with a lobby enabled could leak the room password to a participant at the moment they were admitted from the lobby, defeating the point of having a password at all.
Patch level matters here specifically
Getting JWT configuration right
JWT auth is the right call for anything programmatic, embedding Jitsi in another app, issuing time-limited meeting links, moderator tokens. The lesson worth internalizing here is CVE-2021-39215, a token forgery bug where Prosody's JWT validation accepted symmetric algorithms in a way that let an attacker forge valid tokens and bypass authentication entirely, a classic algorithm-confusion flaw. Fixed since 2.0.5963, but the underlying lesson still applies to any JWT setup: pin the expected signing algorithm server-side, don't trust whatever algorithm a client-supplied token claims to use.
For the actual token generation and signing walkthrough, our JWT and Jitsi integration guide covers that in detail, this section is the "why it matters" context for that setup, not a replacement for it.
Firewall ports and Jitsi exposure
A hardened Jitsi server needs less open than most default firewall configs leave open. This list follows the official quickstart, minus the parts you don't need:
| Port | Purpose | Should be open to |
|---|---|---|
| 80/tcp | Let's Encrypt certificate checks and the redirect to HTTPS | Public internet |
| 443/tcp | Web interface, signaling | Public internet |
| 10000/udp | JVB media (audio/video) | Public internet |
| 3478/udp, 5349/tcp | coturn STUN and the TCP fallback for blocked UDP, only if coturn runs on this box | Public internet |
| 22/tcp (SSH) | Server administration | Your IP range only, never 0.0.0.0/0 |
| 5222, 5280 (5347 on older installs) | Prosody: XMPP clients (Jicofo, JVB) and the HTTP/WebSocket endpoint nginx proxies | Localhost or your private network only, never public |
If you're also running a TURN server for participants behind restrictive NATs, that's additional exposure to account for deliberately, not accidentally, our TURN server setup guide for Jitsi covers sizing that correctly rather than just opening a wide port range and hoping.
Limiting third-party requests
Less about attackers, more about what your server quietly talks to: by default Jitsi Meet's frontend fetches avatars from Gravatar, and any analytics you configure (the analytics block in config.js takes Amplitude or Matomo keys) send data out too. For a deployment where privacy matters, internal comms, healthcare, anything with data-residency requirements, that's outbound traffic you probably didn't sign up for. Set it in config.js:
// /etc/jitsi/meet/<your-domain>-config.js
disableThirdPartyRequests: trueOne catch: this flag has a history of not catching every third-party call. Older releases shipped a callstats.io integration that was reported to slip through with the flag set (current config.js no longer has callstats at all). And the flag doesn't touch analytics keys you set yourself. Treat it as reducing exposure, not eliminating it, and check your browser's network tab after enabling it if third-party requests are a hard requirement to kill entirely.
Known CVEs worth patching
None of these are reasons to avoid Jitsi, every actively maintained platform accumulates a CVE list, what matters is whether yours is patched. The project lists its own in the jitsi-meet security advisories; the lobby and video-sharing bugs below were reported through other channels and only show up in the CVE databases.
- CVE-2025-64754 (November 2025, Moderate): a DOM redirect issue in the Microsoft OAuth login flow that let an attacker intercept the auth window. Fixed in 2.0.10532, no workaround exists for older versions, upgrading is the only fix.
- CVE-2021-39215 (High): JWT token forgery via algorithm confusion, covered above. Fixed in 2.0.5963.
- CVE-2024-33530, lobby password disclosure (fixed in 9391): a logic flaw exposing the room password to a participant being admitted from a lobby.
- CVE-2024-44081, insecure video-sharing URL loading (fixed in 2.0.9779): a crafted message from another participant could make a client load video from an arbitrary attacker-controlled URL. CVE-2024-44080 is the same kind of bug in the GIPHY sharing feature, fixed in the same release.
The pattern across all of them: every one of them is a non-issue on a current version and a real exposure on an old one. Staying reasonably current isn't optional hardening, it's the single highest-leverage thing on this list.
The full hardening checklist
- restrict_room_creation set on the conference MUC, and authentication (JWT, LDAP or SSO) turned on so anonymous visitors can't start meetings
- Room passwords or the lobby on private meetings, long random room names, enableInsecureRoomNameWarning on
- Lobby mode on for any room not meant to be fully public
- JWT signing algorithm pinned server-side, not trusted from the token
- Firewall limited to 443/tcp and the JVB media port, admin ports restricted by source IP
- disableThirdPartyRequests set in config.js if analytics/avatar calls are a concern, verified in the browser network tab, not just assumed
- Server running a current, patched Jitsi version, not whatever shipped at initial install
- meet.jit.si reserved for low-stakes calls only, not anything sensitive
If getting all of this right on infrastructure you manage yourself sounds like more ongoing work than you want, that's a legitimate reason to run a managed AMI instead. Our Jitsi on AWS and Jitsi on GCP guides cover deployments that start from a hardened baseline rather than a bare install you have to lock down yourself.
Frequently Asked Questions
Is Jitsi Meet secure?
The software itself is, media is encrypted in transit (DTLS-SRTP) and E2EE is available for smaller calls. Most real incidents trace back to configuration, not the code: open room creation, no lobby, meet.jit.si used for something that needed a private server. Secure or not depends more on your setup than on Jitsi itself.
What are the most common jitsi meet security best practices misconfigurations?
Leaving room creation unrestricted so anyone can spin up a room without authenticating, skipping lobby mode on rooms that don't need to be public, running an outdated version that's missing a patched CVE, and exposing the JVB's media port range wider than necessary in the firewall.
Does Jitsi Meet have known security vulnerabilities?
Yes, and that's normal for any actively developed platform, what matters is patching them. Recent examples include CVE-2025-64754 (a Microsoft OAuth login redirect issue, fixed in 2.0.10532) and CVE-2021-39215 (JWT token forgery via algorithm confusion, fixed in 2.0.5963). Both are non-issues on a current, patched install.
How do I secure a self-hosted Jitsi server specifically?
Restrict room creation to authenticated users, enable lobby mode for anything not meant to be public, use JWT with a pinned signing algorithm rather than trusting client-supplied algorithm headers, limit the firewall to the ports Jitsi actually needs, and keep the deployment patched against known CVEs.
Is Jitsi safe?
Yes, for most uses. Calls are encrypted in transit, the code is open source and gets patched. The risk is a badly configured server: open room creation, guessable room names with no password or lobby, or an install that hasn't been updated in a year.
Does Jitsi Meet have a default password on rooms?
No. A new room has no password, so the room name is the only secret. Set a password or turn on the lobby for anything private, and use long random room names. A server you run can also require login before a room is created.
Is meet.jit.si safe for sensitive meetings?
It's fine for a quick call with no sensitive content, it's Jitsi's shared public server with no guarantee about who else is on the infrastructure. For anything confidential, a self-hosted server you control and patch yourself is the safer call, not the public instance.
What ports does a hardened Jitsi Meet server actually need open?
443/tcp for the web interface, and the JVB's media port (10000/udp by default) for audio and video. Anything beyond that, an open SSH port to the world, unnecessary admin interfaces, is attack surface that doesn't need to exist.
Start From a Hardened Baseline
Launch a pre-configured Jitsi Meet server with sane security defaults already set, then apply the rest of this checklist on top of a baseline that isn't starting from zero.
Launch Jitsi Meet 250-User on AWS
