Organization members could forge the sender of a group direct message

Impact

In an affected organization, any member could send a group direct message that appears to have been sent by a different user. The fabricated message would be stored and delivered as a normal direct message, displayed under the impersonated person's name with no indication to recipients that it did not come from them. The same flaw let a member bypass restrictions on who is permitted to send or initiate direct messages, by attributing the message to a user who is allowed to.

This was only possible through the API, by forging a specific client identifier, and not through Zulip's web, desktop, or mobile apps.

This required a specific configuration of settings in order to be exploitable:

• The organization must restrict account creation to a list of domains
• The impersonated user's email visibility must generally be set to permit everyone to see the email address. On installations where the organization's own hostname is one of the restricted email domains, this condition does not apply and any user may be impersonated.

Additionally the forged message wass restricted by the following conditions:

• The impersonated sender account's email address must be within the aforementioned email domains
• The message must be a direct message whose conversation includes the attacker's account. A 1-1 direct message is technically possible - the attacker Bob can forge a message from Charlie into their own 1-1 thread with Charlie - but this is of little use, since the only viewer…