"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.
Locking down room creation
The default that catches people out most: restrict_room_creation wasn't enforced in older versions, meaning anyone who could reach your server could spin up a room without any authentication at all. This was specifically flagged in a jitsi-meet-prosody security fix, versions before 2.0.5963-1 didn't guarantee this setting was actually on.
VirtualHost "meet.example.com"
modules_enabled = { "muc_lobby_rooms" }
-- restrict room creation to authenticated users only
restrict_room_creation = trueIf every meeting on your server should come from a logged-in user, not an anonymous guest who happened to guess or receive a room name, this is the setting that enforces it. Our rundown of Jitsi's authentication methods covers the full set of login options this pairs with, LDAP, JWT, and internal Prosody accounts among them.
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: 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 exposure
A hardened Jitsi server needs less open than most default firewall configs leave open:
| Port | Purpose | Should be open to |
|---|---|---|
| 443/tcp | Web interface, signaling | Public internet |
| 10000/udp | JVB media (audio/video) | Public internet |
| 22/tcp (SSH) | Server administration | Your IP range only, never 0.0.0.0/0 |
| 5222, 5347 | Prosody internal XMPP | Localhost/internal 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 can reach out to Gravatar for avatars, and to analytics endpoints like Google Analytics and callstats.io. 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: trueWorth knowing the honest limitation here: this setting has a documented history of not catching every third-party call, callstats.io connections in particular have been reported to slip through in some versions even with the flag set. 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, don't just assume the config line did its job.
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:
- 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.
- Lobby password disclosure (fixed before 9391): a logic flaw exposing the room password to a participant being admitted from a lobby.
- Insecure video-sharing URL loading (fixed before 2.0.9779): crafted chat messages could make a client load video from an arbitrary attacker-controlled URL.
The pattern across all four: 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 enabled, no anonymous room creation
- 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 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
