In Zulip Server versions from 1.7.0 to before 2.0.7, a bug in the new user signup process meant that users who registered their account using social authentication (e.g., GitHub or Google SSO) in an organization that also allows password authentication could have their personal API key stolen by an unprivileged attacker, allowing nearly full access to the user's account.

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 Desktop before 5.0.0 improperly uses shell.openExternal and shell.openItem with untrusted content, leading to remote code execution.

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.

In Zulip Server before 1.7.1, on a server with multiple realms, a vulnerability in the invitation system lets an authorized user of one realm on the server create a user account on any other realm.

Zulip Server 2.x before 2.1.7 allows eval injection if a privileged attacker were able to write directly to the postgres database, and chose to write a crafted custom profile field value.

Improper Access Control in GitHub repository zulip/zulip prior to 4.10.

Zulip is an open source team chat tool. Due to an incorrect authorization check in Zulip Server 5.4 and earlier, a member of an organization could craft an API call that grants organization administrator privileges to one of their bots. The vulnerability is fixed in Zulip Server 5.5. Members who don’t own any bots, and lack permission to create them, can’t exploit the vulnerability. As a workaround for the vulnerability, an organization administrator can restrict the Who can create bots permission to administrators only, and change the ownership of existing bots.

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. 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 is an open source team chat and Zulip Mobile is an app for iOS and Andriod users. In Zulip Mobile through version 27.189, a crafted link in a message sent by an authenticated user could lead to credential disclosure if a user follows the link. A patch was released in version 27.190.

Zulip from 8.0 to 8.3 contains a memory leak vulnerability in the handling of popovers.

Zulip Server before 2.1.5 has Incorrect Access Control because 0198preregistrationuserinvitedas adds the administrator role to invitations.

In zulip before 1.3.12, deactivated users could access messages if SSO was enabled.

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 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 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/.

Cross-site Scripting (XSS) - Stored in GitHub repository zulip/zulip more than and including 44f935695d452cc3fb16845a0c6af710438b153d and prior to 3eb2791c3e9695f7d37ffe84e0c2184fae665cb6.

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 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 group chat application that combines real-time chat with threaded conversations. In affected versions expiration dates on the confirmation objects associated with email invitations were not enforced properly in the new account registration flow. A confirmation link takes a user to the checkpreregkeyandredirect endpoint, before getting redirected to POST to /accounts/register/. The problem was that validation was happening in the checkpreregkeyandredirect part and not in /accounts/register/ - meaning that one could submit an expired confirmation key and be able to register. The issue is fixed in Zulip 4.8. There are no known workarounds and users are advised to upgrade as soon as possible.

Zulip Server 1.5.1 and below suffer from an error in the implementation of the invitebyadminsonly setting in the Zulip group chat application server that allowed an authenticated user to invite other users to join a Zulip organization even if the organization was configured to prevent this.

The Markdown parser in Zulip server before 2.0.5 used a regular expression vulnerable to exponential backtracking. A user who is logged into the server could send a crafted message causing the server to spend an effectively arbitrary amount of CPU time and stall the processing of future messages.

Zulip contains a regular expression that is vulnerable to ReDoS (Regular Expression Denial of Service).

Zulip is an open-source team collaboration tool with unique topic-based threading. In the event that 1: ZulipLDAPAuthBackend and an external authentication backend (any aside of ZulipLDAPAuthBackend and EmailAuthBackend) are the only ones enabled in AUTHENTICATIONBACKENDS in /etc/zulip/settings.py and 2: The organization permissions don't require invitations to join. An attacker can create a new account in the organization with an arbitrary email address in their control that's not in the organization's LDAP directory. The impact is limited to installations which have this specific combination of authentication backends as described above in addition to having Invitations are required for joining this organization organization permission disabled. This issue has been addressed in version 6.2. Users are advised to upgrade. Users unable to upgrade may enable the Invitations are required for joining this organization organization permission to prevent this issue.

Zulip is an open-source team collaboration tool with topic-based threading that combines email and chat. Users who used to be subscribed to a private stream and have been removed from it since retain the ability to edit messages/topics, move messages to other streams, and delete messages that they used to have access to, if other relevant organization permissions allow these actions. For example, a user may be able to edit or delete their old messages they posted in such a private stream. An administrator will be able to delete old messages (that they had access to) from the private stream. This issue was fixed in Zulip Server version 7.3.

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 Server before 2.1.3 allows XSS via the modallink feature in the Markdown functionality.

Zulip Server before 2.1.3 allows reverse tabnabbing via the Markdown functionality.

The image thumbnailing handler in Zulip Server versions 1.9.0 to before 2.0.8 allowed an open redirect that was visible to logged-in users.