Alexmv

Name of the Vulnerable Software and Affected Versions: Zulip (affected versions not specified) Description: A weekly cron job in Zulip 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, containing the name of the private channel. Similarly, the same commit added functionality to notify clients when channels stopped being "inactive," which also leaked an event to all users in the organization with the name of the private channel. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Zulip Server versions 7.0 through 9.3 **Description** The issue concerns an information disclosure attack where an unauthenticated user can determine if an email address is in use by a user on a Zulip server hosting multiple organizations. There are no known workarounds for this issue. **Recommendations** For Zulip Server versions 7.0 through 9.3, upgrade to Zulip Server 9.4 or switch to the `main` branch of Zulip Server to resolve the issue. At the moment, there is no other information about additional mitigation measures.

**Name of the Vulnerable Software and Affected Versions** Zulip versions 3.0 through 8.2 **Description** The issue arises when a user moves a Zulip message from a public stream to a private stream, and chooses to move just that single message. In such cases, active users without 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. Furthermore, 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. This bug has been present since version 3.0, but became more common starting in Zulip 8.0. **Recommendations** For Zulip versions 3.0 through 8.2, upgrade to Zulip Server 8.3 to resolve the issue. As a temporary workaround, consider reloading the client to ensure the message is no longer visible in the public stream. Restrict access to moved messages to minimize the risk of information disclosure until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Zulip version 8.0 **Description** A vulnerability in Zulip affects installations where non-admins can invite users and create multi-use invitations, but only admins can invite users to streams. This issue allows users to invite new users to streams they can already see, but not to arbitrary streams. The estimated number of potentially affected devices is not specified. **Recommendations** For version 8.0, as a temporary workaround, administrators can limit the sending of invitations to users who also have the permission to add users to streams. For version 8.0, update to version 8.1 to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Zulip versions prior to 7.5 **Description** A security issue was found in Zulip, an open-source team collaboration tool, where users who had been removed from a stream could still access its metadata using the Zulip API. This included stream name, description, settings, and an email address used for incoming email integration. As a result, users could see changes to a stream's metadata after they had lost access to the stream. **Recommendations** For versions prior to 7.5, upgrade to version 7.5 to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Zulip Server versions prior to 7.3 **Description** 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. **Recommendations** For Zulip Server versions prior to 7.3, update to Zulip Server version 7.3 to resolve the issue. As a temporary workaround, consider restricting access to private streams and limiting organization permissions to minimize the risk of exploitation. Restrict the ability to edit, move, or delete messages in private streams to only authorized users.

**Name of the Vulnerable Software and Affected Versions** Zulip versions prior to 6.2 **Description** Zulip is an open-source team collaboration tool with unique topic-based threading. 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, given that `ZulipLDAPAuthBackend` and an external authentication backend are the only ones enabled in `AUTHENTICATION BACKENDS` in `/etc/zulip/settings.py` and the organization permissions don't require invitations to join. The impact is limited to installations with this specific combination of authentication backends and having `Invitations are required for joining this organization` organization permission disabled. **Recommendations** For versions prior to 6.2, upgrade to version 6.2 to address the issue. As a temporary workaround for users unable to upgrade, enable the `Invitations are required for joining this organization` organization permission to prevent this issue.

**Name of the Vulnerable Software and Affected Versions** Zulip Server versions 6.1 and below **Description** 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, 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. **Recommendations** For Zulip Server versions 6.1 and below, users are advised to upgrade to version 6.2 to address the issue. For users unable to upgrade, it is recommended to limit sending of invitations down to users who also have the permission to add users to streams.

**Name of the Vulnerable Software and Affected Versions** Zulip versions prior to commit `2f6c5a8` but after commit `04cf68b` **Description** Zulip is an open-source team collaboration tool. In affected versions, 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. This enables session theft. Only deployments which use the S3 storage are affected, and only deployments which deployed commit `04cf68b45ebb5c03247a0d6453e35ffc175d55da`, which has only been in `main`, not any numbered release. **Recommendations** To resolve the issue, users should upgrade from `main` again to deploy the fix. As a temporary workaround, 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.

**Name of the Vulnerable Software and Affected Versions** Zulip Server versions 5.0 through 5.6 **Description** Zulip is an open-source team collaboration tool. For organizations with System for Cross-domain Identity Management (SCIM) account management enabled, it might theoretically be possible for an attacker to infer the value of the SCIM bearer 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. **Recommendations** For Zulip Server versions 5.0 through 5.6, consider disabling SCIM account management until a patch is available to prevent potential exploitation. Restrict access to the SCIM client to minimize the risk of impersonation. Avoid using the SCIM bearer token in sensitive operations until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Zulip Server versions 2.1.0 through 5.3 **Description** Zulip is an open-source team collaboration tool. It has a user interface tool, accessible only to server owners and server administrators, which provides a way to download a "public data" export. However, this export contains the attachment contents for all attachments, even those from private messages and streams, potentially allowing administrators to access private information they are not expected to have access to. **Recommendations** For Zulip Server versions 2.1.0 through 5.3, update to version 5.4 to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Zulip versions 2.1.0 through 5.2 **Description** The issue is related to a logic error in Zulip, an open-source team collaboration tool. When a stream configured as private with protected history is edited, the server incorrectly sends 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 using a modified client or the browser’s developer tools. **Recommendations** For versions 2.1.0 through 5.2, update to Zulip Server 5.3 to resolve the issue. As a temporary workaround, consider restricting access to edited streams to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Zulip versions 4.0 through 4.10 **Description** Zulip is an open source group chat application that is vulnerable to a race condition during account deactivation. This issue may allow continued access by a deactivated user in rare cases if there is simultaneous access by the user being deactivated. **Recommendations** For Zulip versions 4.0 through 4.10, upgrade to version 4.11 on the 4.x branch or version 5.0-rc1 on the 5.x branch to resolve the issue. Upgrading to a fixed version will deactivate any cached sessions that may have been leaked through this bug.

**Name of the Vulnerable Software and Affected Versions** Zulip Server versions 2.0.0 through 4.9 **Description** Zulip is an open-source team collaboration tool with topic-based threading. A Zulip Server deployment which hosts multiple organizations is vulnerable to an attack where an invitation created in one organization 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. **Recommendations** For Zulip Server versions 2.0.0 through 4.9, upgrade to release 4.10 to patch the issue. At the moment, there are no known workarounds for this issue.

**Name of the Vulnerable Software and Affected Versions** Zulip Server versions prior to 4.9 **Description** Zulip Server is an open-source team collaboration tool that installs RabbitMQ for internal message passing. The initial installation of Zulip Server prior to version 4.9 does not successfully limit the default ports opened by RabbitMQ, including port 25672, the RabbitMQ distribution port. This port is protected by a default "cookie" generated using a weak PRNG, resulting in approximately 20 bits of entropy. If not protected by other firewalls, a remote attacker can brute-force the "cookie" and execute arbitrary code as the rabbitmq user, as well as read all data sent through RabbitMQ, including user message traffic. **Recommendations** For versions prior to 4.9, ensure that firewalls prevent access to ports 5672 and 25672 from outside the Zulip server as a workaround. Update to version 4.9, which contains a patch for this issue.

Name of the Vulnerable Software and Affected Versions: Zulip versions prior to 4.8 Description: 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 `check prereg key and redirect` endpoint, before getting redirected to POST to `/accounts/register/`. The problem was that validation was happening in the `check prereg key and redirect` part and not in `/accounts/register/` - meaning that one could submit an expired confirmation key and be able to register. Recommendations: For versions prior to 4.8, upgrade to Zulip 4.8 as soon as possible, as there are no known workarounds for this issue.