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 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 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 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 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 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 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. 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 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. 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 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 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 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 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 from 8.0 to 8.3 contains a memory leak vulnerability in the handling of popovers.

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. 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. It was discovered by the Zulip development team that active users who had previously been subscribed to a stream incorrectly continued being able to use the Zulip API to access metadata for that stream. As a result, users who had been removed from a stream, but still had an account in the organization, could still view metadata for that stream (including the stream name, description, settings, and an email address used to send emails into the stream via the incoming email integration). This potentially allowed users to see changes to a stream’s metadata after they had lost access to the stream. This vulnerability has been addressed in version 7.5 and all users are advised to upgrade. There are no known workarounds for 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 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 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 unique topic-based threading. Zulip administrators can configure Zulip to limit who can add users to streams, and separately to limit who can invite users to the organization. In Zulip Server 6.1 and below, the UI which allows a user to invite a new user also allows them to set the streams that the new user is invited to -- even if the inviting user would not have permissions to add an existing user to streams. While such a configuration is likely rare in practice, the behavior does violate security-related controls. This does not let a user invite new users to streams they cannot see, or would not be able to add users to if they had that general permission. This issue has been addressed in version 6.2. Users are advised to upgrade. Users unable to upgrade may 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. 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. 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 is an open-source team collaboration tool with topic-based threading that combines email and chat. When displaying messages with embedded remote images, Zulip normally loads the image preview via a go-camo proxy server. However, an attacker who can send messages could include a crafted URL that tricks the server into embedding a remote image reference directly. This could allow the attacker to infer the viewer’s IP address and browser fingerprinting information. This vulnerability is fixed in Zulip Server 5.6. Zulip organizations with image and link previews disabled are not affected.

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.

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

In zulip before 1.3.12, bot API keys were accessible to other users in the same realm.