Cross-site Scripting (XSS) - Stored in zulip/zulip
Reported on
Dec 18th 2021
Description
Zulip is a powerful, open source group chat application that combines the immediacy of real-time chat with the productivity benefits of threaded conversations. Zulip is used by open source projects, Fortune 500 companies, large standards bodies, and others who need a real-time chat system that allows users to easily process hundreds or thousands of messages a day. With over 700 contributors merging over 500 commits a month, Zulip is also the largest and fastest growing open source group chat project , this is vulnerable for Stored XSS thru creating streams
Proof of Concept
Impact
This vulnerability is capable of stored XSS
We have a fix in a private repository. We'll notify here when we've release it publicly.
@alexmv - absolutely!
This report has received CVE:
CVE-2021-3853
Once you have released your fix and are comfortable for this report to go public, please confirm the fix against this report, and we can go ahead and publish the CVE for you as well. Let me know if you have any questions or require any further assistance, and I am on call to help! 👋
Just for reference, I incorrectly double assigned a CVE to this report, with the number mentioned above. This has now been corrected and assigned its own CVE number.
@admin: https://nvd.nist.gov/vuln/detail/CVE-2021-3866 claims "up to and including 4.8" is vulnerable, which is incorrect -- this vulnerability was never in any released version of Zulip, only in the main branch.
Can you update the CVE? You can also add https://blog.zulip.com/2022/01/19/cve-2021-3866/ as a reference to it.
@alexmv - apologies!
We usually require a version number when publishing a CVE, can you confirm the version number it will be published in, or perhaps we can update it once the version is published?
Otherwise, I can put the commit SHA in place of the version number. Let me know your thoughts, and of course happy to add the extra reference for you as well.
There is no vulnerable version that it is published in, and there will never be a numbered release which is vulnerable. The commit which fixed it will eventually be released in 5.0, but saying "fixed in 5.0" would give the incorrect impression that versions prior to that are vulnerable -- which they are not. Only main was ever vulnerable.
To be clear, while it's somewhat unusual to file a CVE which doesn't affect any numbered releases, we did so because we support deploying and upgrading from main, and wanted to be explicit about the vulnerability to those that were running from it.
I think the only accurate way to phrase it is as commit hashes:
Stored XSS in GitHub repository zulip/zulip on commits between 44f935695d452cc3fb16845a0c6af710438b153d and 3eb2791c3e9695f7d37ffe84e0c2184fae665cb6 (affects no numbered releases).
@Alex - thanks for clarifying here in such depth. Very helpful 👍
I have made the adjustments for you here:
https://github.com/CVEProject/cvelist/pull/4247
The CVE should update across all public databases once merged.
Thanks, @admin! The description still incorrectly says "prior to and including 4.8", however: https://github.com/CVEproject/cvelist/blob/master/2021/3xxx/CVE-2021-3866.json#L43
I'm not familiar with this github-based CVE workflow -- if this is something I can submit a PR for myself, do let me know.
@Alex - apologies! 🤦♂️ I have created a PR to update the CVE here:
https://github.com/CVEProject/cvelist/pull/4260/files
Once this is merged the CVE will be almost immediately updated.