This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Zimbra Collaboration Suite
A reflected cross-site scripting (XSS) vulnerability in the zimbraAdmin/public/secureRequest.jsp component of Zimbra Collaboration 8.8.12 allows unauthenticated attackers to execute arbitrary web scripts or HTML via a host header injection. (2021-12-15, CVE-2020-18984)
An XSS vulnerability exists in the Webmail component of Zimbra Collaboration Suite before 8.8.15 Patch 11. It allows an attacker to inject executable JavaScript into the account name of a user's profile. The injected code can be reflected and executed when changing an e-mail signature. (2020-07-02, CVE-2020-13653)
Synacor Zimbra Admin UI in Zimbra Collaboration Suite before 8.8.0 beta 2 has Persistent XSS via mail addrs. (2019-05-30, CVE-2018-10948)
There is a Persistent XSS vulnerability in the briefcase component of Synacor Zimbra Collaboration Suite (ZCS) Zimbra Web Client (ZWC) 8.8.8 before 8.8.8 Patch 7 and 8.8.9 before 8.8.9 Patch 1. (2019-05-30, CVE-2018-14425)
mailboxd component in Synacor Zimbra Collaboration Suite 8.6, 8.7 before 8.7.11 Patch 7, and 8.8 before 8.8.10 Patch 2 has Persistent XSS. (2019-05-29, CVE-2018-18631)
Synacor Zimbra Collaboration Suite Collaboration before 8.8.11 has XSS in the AJAX and html web clients. (2019-05-29, CVE-2018-14013)
Zimbra Web Client (ZWC) in Zimbra Collaboration Suite 8.8 before 8.8.8.Patch4 and 8.7 before 8.7.11.Patch4 has Persistent XSS via a contact group. (2018-05-30, CVE-2018-10939)
Cross-site scripting (XSS) vulnerability in the ZmMailMsgView.getAttachmentLinkHtml function in Zimbra Collaboration Suite (ZCS) before 8.7 Patch 1 and 8.8.x before 8.8.7 might allow remote attackers to inject arbitrary web script or HTML via a Content-Location header in an email attachment. (2018-03-27, CVE-2018-6882)
Why Cross-site Scripting can be dangerous
Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.
The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:
https://server.com/confirmation?message=Transaction+Complete
what results in:
<span>Confirmation: Transaction Complete</span>
In that case the message can be modified to become a valid Javascript code, e.g.:
https://server.com/confirmation?message=<script>dangerous javascript code here</script>
and it will be executed locally by the user's browser with full access to the user's personal application/browser data:
<span>Confirmation: <script>dangerous javascript code here</script></span>