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

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 Server before 2.1.5 has Incorrect Access Control because 0198preregistrationuserinvitedas adds the administrator role to invitations.

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

Zulip Server before 2.1.5 allows reflected XSS via the Dropbox webhook.

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 was an XSS issue with stream names in topic typeahead.

In Zulip Server versions before 1.7.2, there were XSS issues with the frontend markdown processor.

Zulip Server before 2.1.5 allows reverse tabnapping via a topic header link.

Zulip Server before 2.1.3 allows XSS via a Markdown link, with resultant account takeover.

Zulip server before 2.0.5 incompletely validated the MIME types of uploaded files. A user who is logged into the server could upload files of certain types to mount a stored cross-site scripting attack on other logged-in users. On a Zulip server using the default local uploads backend, the attack is only effective against browsers lacking support for Content-Security-Policy such as Internet Explorer 11. On a Zulip server using the S3 uploads backend, the attack is confined to the origin of the configured S3 uploads hostname and cannot reach the Zulip server itself.

In Zulip Server versions before 1.7.2, there was an XSS issue with user uploads and the (default) LOCALUPLOADSDIR storage backend.

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

An issue was discovered in Zulip Server before 3.4. A bug in the implementation of the allpublicstreams API feature resulted in guest users being able to receive message traffic to public streams that should have been only accessible to members of the organization.

Zulip is an open-source team collaboration tool. Zulip Server versions 2.1.0 above have a user interface tool, accessible only to server owners and server administrators, which provides a way to download a "public data" export. While this export is only accessible to administrators, in many configurations server administrators are not expected to have access to private messages and private streams. However, the "public data" export which administrators could generate contained the attachment contents for all attachments, even those from private messages and streams. Zulip Server version 5.4 contains a patch 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. In versions of zulip prior to commit 2f6c5a8 but after commit 04cf68b users could upload files with arbitrary Content-Type which would be served from the Zulip hostname with Content-Disposition: inline and no Content-Security-Policy header, allowing them to trick other users into executing arbitrary Javascript in the context of the Zulip application. Among other things, this enables session theft. Only deployments which use the S3 storage (not the local-disk storage) are affected, and only deployments which deployed commit 04cf68b45ebb5c03247a0d6453e35ffc175d55da, which has only been in main, not any numbered release. Users affected should upgrade from main again to deploy this fix. Switching from S3 storage to the local-disk storage would nominally mitigate this, but is likely more involved than upgrading to the latest main which addresses the issue.

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.

An issue was discovered in Zulip Server before 3.4. A bug in the implementation of the canforgesender permission (previously isapisuperuser) resulted in users with this permission being able to send messages appearing as if sent by a system bot, including to other organizations hosted by the same Zulip installation.

An issue was discovered in Zulip Server before 3.4. A bug in the implementation of replies to messages sent by outgoing webhooks to private streams meant that an outgoing webhook bot could be used to send messages to private streams that the user was not intended to be able to send messages to.