Impact
Zulip 4.0 and later are 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. This access can theoretically continue until one of the following events happens:
- The session expires from memcached; this defaults to two weeks, and is controlled by SESSION_COOKIE_AGE in /etc/zulip/settings.py
- The session cache is evicted from memcached by other cached data.
- The server is upgraded, which clears the cache.
Patches
This problem is patched in Zulip Server 4.11. Upgrading to this version will, as a side effect, deactivate any cached sessions that may have been leaked through this bug, because upgrading clears all memcached caches (at least from a logical perspective).
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.
Impact
Zulip 4.0 and later are 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. This access can theoretically continue until one of the following events happens:
- The session expires from memcached; this defaults to two weeks, and is controlled by
SESSION_COOKIE_AGEin/etc/zulip/settings.py- The session cache is evicted from memcached by other cached data.
- The server is upgraded, which clears the cache.
Patches
This problem is patched in Zulip Server 4.11. Upgrading to this version will, as a side effect, deactivate any cached sessions that may have been leaked through this bug, because upgrading clears all memcached caches (at least from a logical perspective).
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.