See how zulip compares to other vendors in security performance
Zulip is an open-source team collaboration tool. In Zulip Server versions through 12.1, guest users can receive new message events for public channels outside their subscriptions. A guest can trigger the issue by registering an event queue with parameters that request messages from an unsubscribed public channel, or an existing event queue can remain affected after the guest's access to the channel is removed. The flaw discloses new public-channel messages to the guest. This issue is fixed in version 12.2.
Zulip is an open-source team collaboration tool. In Zulip Server versions through 12.1, GenericOpenIdConnectBackend matches the identity provider email claim to an active account's deliveryemail without rejecting an explicitly false emailverified claim. If a configured identity provider returns an email address that the authenticating user does not control together with emailverified=false, Zulip can log the user into the existing account for that address. Exploitation requires a misconfigured trusted identity provider, and deployments whose authoritative identity provider only emits email addresses controlled by the authenticating user are not affected. This issue is fixed in version 12.2.
Zulip is an open-source team collaboration tool. Prior to version 11.6, Zulip is an open-source team collaboration tool. From version 1.4.0 to before version 11.6, even after spectator access (enablespectatoraccess / WEBPUBLICSTREAMSENABLED) is disabled, attachments originating from web-public streams can still be retrieved anonymously. As a result, file contents remain accessible even after public access is intended to be disabled. Similarly, even after spectator access is disabled, the /users/me/<streamid>/topics endpoint remains reachable anonymously, allowing retrieval of topic history for web-public streams. This issue has been patched in version 11.6. This issue has been patched in version 11.6.
Zulip is an open-source team collaboration tool. From version 1.4.0 to before version 11.6, ./manage.py import reads arbitrary files from the server filesystem via path traversal in uploads/records.json. A crafted export tarball causes the server to copy any file the zulip user can read into the uploads directory during import. This issue has been patched in version 11.6.
Zulip is an open source team chat application. A weekly cron job (added in 50256f48314250978f521ef439cafa704e056539) demotes channels to being "inactive" after they have not received traffic for 180 days. However, upon doing so, an event was sent to all users in the organization, not just users in the channel. This event contained the name of the private channel. Similarly, the same commit (50256f48314250978f521ef439cafa704e056539) added functionality to notify clients when channels stopped being "inactive." The first message sent to a private channel which had not previously had any messages for over 180 days (and were thus already marked "inactive") would leak an event to all users in the organization; this event also contained the name of the private channel. Commits 75be449d456d29fef27e9d1828bafa30174284b4 and a2a1a7f8d152296c8966f1380872c0ac69e5c87e fixed the issue. This vulnerability only existed in main, and was not part of any published versions.
Zulip is an open-source team collaboration tool. A vulnerability in version 8.0 is similar to CVE-2023-32677, but applies to multi-use invitations, not single-use invitation links as in the prior CVE. Specifically, it applies when the installation has configured non-admins to be able to invite users and create multi-use invitations, and has also configured only admins to be able to invite users to streams. As in CVE-2023-32677, this does not let users invite new users to arbitrary streams, only to streams that the inviter can already see. Version 8.1 fixes this issue. As a workaround, administrators can limit sending of invitations down to users who also have the permission to add users to streams.
Zulip is an open-source team collaboration tool with unique topic-based threading that combines the best of email and chat to make remote work productive and delightful. The main development branch of Zulip Server from May 2, 2023 and later, including beta versions 7.0-beta1 and 7.0-beta2, is vulnerable to a cross-site scripting vulnerability in tooltips on the message feed. An attacker who can send messages could maliciously craft a topic for the message, such that a victim who hovers the tooltip for that topic in their message feed triggers execution of JavaScript code controlled by the attacker.
Zulip is an open-source team collaboration tool. For organizations with System for Cross-domain Identity Management(SCIM) account management enabled, Zulip Server 5.0 through 5.6 checked the SCIM bearer token using a comparator that did not run in constant time. Therefore, it might theoretically be possible for an attacker to infer the value of the token by performing a sophisticated timing analysis on a large number of failing requests. If successful, this would allow the attacker to impersonate the SCIM client for its abilities to read and update user accounts in the Zulip organization. Organizations where SCIM account management has not been enabled are not affected.
Zulip contains a regular expression that is vulnerable to ReDoS (Regular Expression Denial of Service).
In Zulip Server versions before 1.7.2, there was an XSS issue with user uploads and the (default) LOCALUPLOADSDIR storage backend.
In Zulip Server versions before 1.7.2, there was an XSS issue with stream names in topic typeahead.
In Zulip Server versions 1.5.x, 1.6.x, and 1.7.x before 1.7.2, there was an XSS issue with muting notifications.
In Zulip Server versions before 1.7.2, there were XSS issues with the frontend markdown processor.
Zulip is an open-source team collaboration tool. Prior to 12.0, With messageedithistoryvisibilitypolicy set to "moves", /api/v1/messages/{id}/history still returns historical content values, allowing low-privilege users to recover text that was edited away from other users' messages. This vulnerability is fixed in 12.0.
Zulip is an open-source team collaboration tool. From 5.0 to before 11.5, some administrative actions on the user profile were susceptible to stored XSS in group names or channel names. Exploiting these vulnerabilities required the user explicitly interacting with the problematic object. This vulnerability is fixed in 11.5.
Zulip is an open-source team collaboration tool. Zulip supports a configuration where account creation is limited solely by being able to authenticate with a single-sign on authentication backend, meaning the organization places no restrictions on email address domains or invitations being required to join, but has disabled the EmailAuthBackend that is used for email/password authentication. A bug in the Zulip server means that it is possible to create an account in such organizations, without having an account with the configured SSO authentication backend. This issue is patched in version 10.2. A workaround includes requiring invitations to join the organization prevents the vulnerability from being accessed.
Zulip 8.3 is vulnerable to Cross Site Scripting (XSS) via the replaceemojiwithtext function in uiutil.ts.
Zulip 8.3 is vulnerable to Cross Site Scripting (XSS) via the constructcopydiv function in copyandpaste.js.
Zulip is an open-source team chat application. From versions 2.0.0-rc1 to before 10.4 in Zulip Server, the /digest/ URL of a server shows a preview of what the email weekly digest would contain. This URL, though not the digest itself, contains a cross-site scripting (XSS) vulnerability in both topic names and channel names. This issue has been fixed in Zulip Server 10.4. A workaround for this issue involves denying access to /digest/.
Zulip server provides an open-source team chat that helps teams stay productive and focused. Zulip Server 7.0 and above are vulnerable to an information disclose attack, where, if a Zulip server is hosting multiple organizations, an unauthenticated user can make a request and determine if an email address is in use by a user. Zulip Server 9.4 resolves the issue, as does the main branch of Zulip Server. Users are advised to upgrade. There are no known workarounds for this issue.
Zulip server provides an open-source team chat that helps teams stay productive and focused. Prior to 10.0, the data export to organization administrators feature in Zulip leaks private data. The collection of user-agent types identifying specific integrations or HTTP libraries (E.g., ZulipGitlabWebhook, okhttp, or PycURL) that have been used to access any organization on the server was incorrectly included in all three export types, regardless of if they were used to access the exported organization or not. The "public data" and "with consent" exports metadata including the titles of some topics in private channels which the administrator otherwise did not have access to, and none of the users consented to exporting and metadata for which users were in a group DM together. This vulnerability is fixed in 10.0.
Zulip is an open-source team collaboration tool. The API for deleting an organization custom profile field is supposed to be restricted to organization administrators, but its handler failed to check that the field belongs to the same organization as the user. Therefore, an administrator of any organization was incorrectly allowed to delete custom profile fields belonging to a different organization. This is fixed in Zulip Server 10.1.
Zulip is an open-source team collaboration tool. When a user moves a Zulip message, they have the option to move all messages in the topic, move only subsequent messages as well, or move just a single message. If the user chose to just move one message, and was moving it from a public stream to a private stream, Zulip would successfully move the message, -- but active users who did not have access to the private stream, but whose client had already received the message, would continue to see the message in the public stream until they reloaded their client. Additionally, Zulip did not remove view permissions on the message from recently-active users, allowing the message to show up in the "All messages" view or in search results, but not in "Inbox" or "Recent conversations" views. While the bug has been present since moving messages between streams was first introduced in version 3.0, this option became much more common starting in Zulip 8.0, when the default option in the picker for moving the very last message in a conversation was changed. This issue is fixed in Zulip Server 8.3. No known workarounds are available.
Zulip is an open-source team chat application. Starting in version 10.0 and prior to version 10.3, the "Who can create public channels" access control mechanism can be circumvented by creating a private or web-public channel, and then changing the channel privacy to public. A similar technique works for creating private channels without permission, though such a process requires either the API or modifying the HTML, as we do mark the "private" radio button as disabled in such cases. Version 10.3 contains a patch.
Zulip is an open-source team collaboration tool. The API for deleting an organization export is supposed to be restricted to organization administrators, but its handler failed to check that the field belongs to the same organization as the user. Therefore, an administrator of any organization was incorrectly allowed to delete an export of a different organization. This is fixed in Zulip Server 10.1.
Zulip is an open-source team collaboration tool. Zulip Server installs RabbitMQ for internal message passing. In versions of Zulip Server prior to 4.9, the initial installation (until first reboot, or restart of RabbitMQ) does not successfully limit the default ports which RabbitMQ opens; this includes port 25672, the RabbitMQ distribution port, which is used as a management port. RabbitMQ's default "cookie" which protects this port is generated using a weak PRNG, which limits the entropy of the password to at most 36 bits; in practicality, the seed for the randomizer is biased, resulting in approximately 20 bits of entropy. If other firewalls (at the OS or network level) do not protect port 25672, a remote attacker can brute-force the 20 bits of entropy in the "cookie" and leverage it for arbitrary execution of code as the rabbitmq user. They can also read all data which is sent through RabbitMQ, which includes all message traffic sent by users. Version 4.9 contains a patch for this vulnerability. As a workaround, ensure that firewalls prevent access to ports 5672 and 25672 from outside the Zulip server.
Zulip is an open-source team collaboration tool with topic-based threading. Zulip Server version 2.0.0 and above are vulnerable to insufficient access control with multi-use invitations. A Zulip Server deployment which hosts multiple organizations is vulnerable to an attack where an invitation created in one organization (potentially as a role with elevated permissions) can be used to join any other organization. This bypasses any restrictions on required domains on users' email addresses, may be used to gain access to organizations which are only accessible by invitation, and may be used to gain access with elevated privileges. This issue has been patched in release 4.10. There are no known workarounds for this issue. ### Patches Has the problem been patched? What versions should users upgrade to? ### Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? ### References Are there any links users can visit to find out more? ### For more information If you have any questions or comments about this advisory, you can discuss them on the developer community Zulip server, or email the Zulip security team.
Zulip is an open source team chat app. The main development branch of Zulip Server from June 2021 and later is vulnerable to a cross-site scripting vulnerability on the recent topics page. An attacker could maliciously craft a full name for their account and send messages to a topic with several participants; a victim who then opens an overflow tooltip including this full name on the recent topics page could trigger execution of JavaScript code controlled by the attacker. Users running a Zulip server from the main branch should upgrade from main (2022-03-01 or later) again to deploy this fix.
Zulip is an open source group chat application. Starting with version 4.0 and prior to version 4.11, Zulip is vulnerable to a race condition during account deactivation, where a simultaneous access by the user being deactivated may, in rare cases, allow continued access by the deactivated user. A patch is available in version 4.11 on the 4.x branch and version 5.0-rc1 on the 5.x branch. Upgrading to a fixed version will, as a side effect, deactivate any cached sessions that may have been leaked through this bug. There are currently no known workarounds.
Zulip is an open-source team collaboration tool. Versions 2.1.0 through and including 5.2 are vulnerable to a logic error. A stream configured as private with protected history, where new subscribers should not be allowed to see messages sent before they were subscribed, when edited causes the server to incorrectly send an API event that includes the edited message to all of the stream’s current subscribers. This API event is ignored by official clients, but can be observed by using a modified client or the browser’s developer tools. This bug will be fixed in Zulip Server 5.3. There are no known workarounds.