CVE-2026-73570: Zimbra SNMP RCE abused to deploy coin-miner malware

CVE-2026-73570 is a Remote Code Execution issue in Zimbra Collaboration Suite (ZCS), related to SNMP notification/logwatch handling.

In short, an unauthenticated attacker can send a crafted SMTP request and get OS command execution as the zimbra user when the vulnerable SNMP/logwatch components are installed and enabled.

According to NVD, the issue affects Zimbra versions before 10.1.20 when SNMP is installed and SNMP notification is enabled. The Hacker News also reported active exploitation against Zimbra servers.

The observed attack chain is usually:

malicious SMTP request -> unsafe SNMP/logwatch handling -> command execution as zimbra -> malware dropped into /dev/shm -> cron persistence added -> miner or backdoor keeps respawning

What is CVE-2026-73570?

CVE-2026-73570 is an OS Command Injection vulnerability in Zimbra Collaboration Suite.

The issue is in the SNMP notification/logwatch flow, where attacker-controlled input is not handled safely before being passed into system-level processing.

The command runs as the zimbra user, not root. That is still serious because the zimbra user controls important Zimbra services, mailbox components, logs, cron jobs and runtime paths.

When is a Zimbra server at risk?

A server should be checked immediately if:

It is running Zimbra Collaboration Suite. It is not patched to a fixed version. zimbra-snmp or zimbra-net-snmp is installed. SNMP is enabled in Zimbra. zmlogswatch or zmswatch is running.

Quick checks:

su - zimbra -c 'zmcontrol -v' dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp' su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp' su - zimbra -c 'zmlogswatchctl status' su - zimbra -c 'zmswatchctl status'

If you see zimbraServiceEnabled: snmp and zmlogswatch is running, treat the server as high priority for compromise checks.

Signs of compromise

In the cases observed, malware was often dropped into /dev/shm. This directory is a tmpfs location, writable and easy to miss during a quick investigation.

Check:

ls -la /dev/shm crontab -l -u zimbra ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep

Common suspicious files:

/dev/shm/.khp /dev/shm/.khpts /dev/shm/.rguard /dev/shm/idle /dev/shm/javab /dev/shm/ksmd

A cron entry like this is a strong persistence indicator:

/dev/shm/.khp

Why does the malware keep coming back?

Deleting files from /dev/shm is usually not enough.

The malware can return because:

The malicious process is still running in memory. The zimbra crontab runs /dev/shm/.khp every minute. .rguard or idle may protect or redeploy the payload. SNMP/logwatch is still enabled, so the CVE can be exploited again.

The correct order is:

stop reinfection source -> preserve evidence -> kill malware processes -> remove malicious cron -> quarantine malware files -> verify clean state -> recover Zimbra services if needed -> patch/upgrade Zimbra

Cleanup procedure

Run the following commands as root. Review each command before running it on production.

Step 1: Stop the reinfection source

systemctl stop cron su - zimbra -c 'zmlogswatchctl stop' su - zimbra -c 'zmswatchctl stop' su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled snmp'

Disabling SNMP/logwatch is the most important containment step. Do not re-enable these components before Zimbra is patched.

Step 2: Preserve malware evidence

mkdir -p /root/incident-zimbra cp -a /dev/shm/.khp \ /dev/shm/.khpts \ /dev/shm/.rguard \ /dev/shm/idle \ /dev/shm/javab \ /dev/shm/ksmd \ /root/incident-zimbra/ 2>/dev/null crontab -l -u zimbra > /root/incident-zimbra/zimbra-cron-before.txt 2>&1 ps auxf > /root/incident-zimbra/ps-before.txt ss -tunap > /root/incident-zimbra/ss-before.txt sha256sum /root/incident-zimbra/ > /root/incident-zimbra/sha256.txt 2>/dev/null

Step 3: Kill malware processes

pkill -9 -u zimbra -f 'khp|rguard|javab|idle|ksmd'

Step 4: Remove malicious cron

crontab -l -u zimbra | grep -v '/dev/shm/.khp' | crontab -u zimbra -

Step 5: Quarantine malware files

mkdir -p /root/quarantine-zimbra mv /dev/shm/.khp \ /dev/shm/.khpts \ /dev/shm/.rguard \ /dev/shm/idle \ /dev/shm/javab \ /dev/shm/ksmd \ /root/quarantine-zimbra/ 2>/dev/null

Step 6: Start cron again

systemctl start cron systemctl is-active cron

Only start cron. Do not start zmlogswatch, zmswatch or SNMP before patching Zimbra.

Verify after cleanup

ls -la /dev/shm crontab -l -u zimbra | grep /dev/shm ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp || echo SNMPDISABLED'

Expected result:

/dev/shm is clean no cron entry calling /dev/shm/.khp no suspicious javab/rguard/idle/khp/ksmd process SNMP is disabled

If Zimbra MySQL or mailbox fails

After malware activity or an unexpected reboot, Zimbra may show:

mailbox Stopped mysql.server is not running service webapp Stopped zimbra webapp Stopped zimbraAdmin webapp Stopped zimlet webapp Stopped

Check MySQL and services:

su - zimbra -c 'zmcontrol status' su - zimbra -c 'mysql.server status' ss -ltnp | grep 7306 tail -n 200 /opt/zimbra/log/mysqlerror.log

If MySQL is stuck in crash recovery or has a stale socket, back up relevant files first.

Backup before MySQL recovery

mkdir -p /root/zimbra-mysql-backup cp -a /opt/zimbra/log/mysqlerror.log /root/zimbra-mysql-backup/ 2>/dev/null cp -a /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/ 2>/dev/null cp -a /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/ 2>/dev/null cp -a /opt/zimbra/db/data/ibdata1 /root/zimbra-mysql-backup/ 2>/dev/null cp -a /opt/zimbra/db/data/iblogfile /root/zimbra-mysql-backup/ 2>/dev/null

Light MySQL recovery

su - zimbra -c 'zmmailboxdctl stop' mv /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/mysql.sock.bak 2>/dev/null mv /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/tc.log.bak 2>/dev/null su - zimbra -c 'mysql.server start' sleep 20 su - zimbra -c 'mysql.server status' su - zimbra -c 'zmmailboxdctl start' sleep 40 su - zimbra -c 'zmcontrol status'

Expected result:

mysql is running mailbox Running service webapp Running zimbra webapp Running zimbraAdmin webapp Running zimlet webapp Running

This is not a universal fix. Always check /opt/zimbra/log/mysqlerror.log first.

Does this delete mail data?

The malware cleanup steps do not touch mailbox data directly.

Zimbra mail data is usually stored in:

/opt/zimbra/store/

Zimbra database data is usually stored in:

/opt/zimbra/db/data/

The MySQL recovery steps touch tc.log and mysql.sock, so back up first.

Check for JSP webshells

After handling /dev/shm, cron and processes, also check for suspicious JSP files created by the zimbra user in recent days.

Important paths include:

/opt/zimbra/jetty/webapps/ /opt/zimbra/jettybase/webapps/ /tmp/

Unexpected JSP/JSPX files, executable scripts, archives or recently modified web application files may indicate payload staging or webshell deployment.

Check JSP/JSPX files:

find /opt/zimbra/jetty/webapps -type f \( -name ".jsp" -o -name ".jspx" \) -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort

If suspicious JSP backdoors are found, preserve evidence first, then quarantine them from both paths:

/opt/zimbra/jetty/webapps/zimbra/ /opt/zimbra/jettybase/webapps/zimbra/

Evidence backup and quarantine:

TS=$(date +%Y%m%d%H%M%S) INC=/root/incident-zmmail-jsp-webshell-$TS QUA=/root/quarantine-zmmail-jsp-webshell-$TS mkdir -p "$INC" "$QUA" # Save list and hashes find /opt/zimbra/jetty/webapps/zimbra /opt/zimbra/jettybase/webapps/zimbra \ -xdev -type f \( -iname '.jsp' -o -iname '.jspx' \) -mtime -30 \ -print > "$INC/suspicious-jsp-list.txt" xargs -a "$INC/suspicious-jsp-list.txt" sha256sum > "$INC/suspicious-jsp-sha256.txt" # Backup samples while read f; do mkdir -p "$INC/files$(dirname "$f")" cp -a "$f" "$INC/files$f" done < "$INC/suspicious-jsp-list.txt" # Quarantine from webroot while read f; do mkdir -p "$QUA$(dirname "$f")" mv "$f" "$QUA$f" done < "$INC/suspicious-jsp-list.txt" # Verify find /opt/zimbra/jetty/webapps/zimbra /opt/zimbra/jettybase/webapps/zimbra \ -xdev -type f \( -iname '.jsp' -o -iname '.jspx' \) -mtime -30 -print

Risks:

If a file is a legitimate custom JSP, removing it may affect a custom webmail function. Random file names and content using exec, base64, AES or command execution are strong webshell indicators. This does not affect mailbox data. A restart is not always required immediately, but webmail should be verified after quarantine.

Important note: zmlogswatch/zmswatch may start again

After disabling SNMP/logwatch to mitigate CVE-2026-73570, zmlogswatch and zmswatch may start again after daily logrotate or after zmcontrol restart.

This happens because Zimbra logrotate configs often contain postrotate commands that restart zmlogswatchctl and zmswatchctl. Also, logger may still be listed in zimbraServiceEnabled.

So after temporary mitigation, check these services periodically, especially after midnight or after restarting Zimbra.

If you need a stronger temporary block before patching, back up the logrotate configs, comment the restart lines, and consider removing logger from zimbraServiceEnabled.

This can prevent logwatch from starting again and reopening the attack vector, but the Admin Console may lose part of its monitoring/statistics.

Disable zmlogswatch/zmswatch so they do not auto-start

Warning: disabling logger, zmlogswatch and zmswatch may make the Zimbra Admin Console show logger/monitoring as red, or remove some graphs/statistics.

During the unpatched phase, this is an acceptable temporary trade-off to prevent logwatch from restarting automatically.

After upgrading to a fixed version, restore the configuration from backup and re-enable logger if needed.

Back up Zimbra logrotate configs

cp -a /etc/logrotate.d/zimbra /etc/logrotate.d/zimbra.bak.$(date +%F-%H%M%S) cp -a /opt/zimbra/conf/zmlogrotate /opt/zimbra/conf/zmlogrotate.bak.$(date +%F-%H%M%S)

Open these two files:

/etc/logrotate.d/zimbra /opt/zimbra/conf/zmlogrotate

Find these lines, often around line 85 and 99:

su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true

Comment them:

# su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true # su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true

Remove logger from enabled services:

su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled logger'

Stop current logwatch/swatch processes:

su - zimbra -c 'zmlogswatchctl stop' su - zimbra -c 'zmswatchctl stop' su - zimbra -c 'zmlocalconfig -e snmpnotify=no'

Verify:

su - zimbra -c 'zmlogswatchctl status' su - zimbra -c 'zmswatchctl status' su - zimbra -c 'zmlocalconfig snmpnotify' su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | egrep "logger|snmp" || echo "LOGGERSNMPDISABLED"'

Expected result:

zmlogswatch is not running. zmswatch is not running. snmpnotify = no LOGGERSNMPDISABLED

Re-enable monitoring/logger after patching

Only do this after Zimbra is patched or upgraded.

su - zimbra -c 'zmprov ms $(zmhostname) +zimbraServiceEnabled logger' su - zimbra -c 'zmlogswatchctl start' su - zimbra -c 'zmswatchctl start'

If you commented the logrotate files, open them again:

/etc/logrotate.d/zimbra /opt/zimbra/conf/zmlogrotate

Uncomment these lines:

su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true

Re-enable SNMP only after patching

su - zimbra -c 'zmprov ms $(zmhostname) +zimbraServiceEnabled snmp' su - zimbra -c 'zmlocalconfig -e snmpnotify=yes' su - zimbra -c 'zmswatchctl start'

Verify after re-enabling:

su - zimbra -c 'zmcontrol status' su - zimbra -c 'zmlogswatchctl status' su - zimbra -c 'zmswatchctl status' su - zimbra -c 'zmlocalconfig snmpnotify' su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | egrep "logger|snmp"'

Post-cleanup tasks

After the server is running again:

Keep SNMP/logwatch disabled until patched. Monitor /dev/shm for 30-60 minutes. Monitor the zimbra crontab. Monitor CPU/load and outbound connections. Check the mail queue. Patch or upgrade Zimbra to a fixed release. Only re-enable SNMP/logwatch after patching and verification.

Check queue:

/opt/zimbra/common/sbin/postqueue -p | tail -n 40

Summary workflow

1. Check /dev/shm, processes and crontab. 2. Stop cron, zmlogswatch and zmswatch. 3. Disable SNMP in Zimbra. 4. Preserve evidence. 5. Kill malware processes. 6. Remove malicious cron. 7. Quarantine malware files. 8. Start cron again. 9. Verify that malware does not respawn. 10. Recover MySQL/mailbox if needed. 11. Check JSP webshells in Zimbra webapps paths. 12. Monitor queue and services. 13. Prevent zmlogswatch/zmswatch from auto-starting before patching. 14. Patch or upgrade Zimbra. 15. Re-enable logger/SNMP only after patching and verification.

References

NVD: CVE-2026-73570 The Hacker News: attackers exploit Zimbra SNMP flaw Zimbra Security Center Zimbra Security Advisories

Conclusion

CVE-2026-73570 is serious because it can allow remote command execution as the zimbra user through SNMP notification/logwatch handling.

In observed incidents, attackers dropped malware into /dev/shm, added cron persistence, and ran a miner or backdoor.

The key point is this: do not only delete the malware file. Stop the reinfection path first.

A practical response order is:

stop cron + SNMP/logwatch -> preserve evidence -> kill malware -> remove malicious cron -> quarantine payloads -> check JSP webshells -> verify clean state -> recover Zimbra if needed -> block logwatch auto-restart before patching -> patch/upgrade Zimbra

Most important: do not re-enable SNMP/logwatch before Zimbra is patched, because that may allow the malware to return.

In Zimbra Collaboration (ZCS) before 10.1.17, weak cryptographic key generation vulnerability exists in the OnlyOffice integration. The zimbraDocumentEditingJwtSecret is generated using an insecure random number generator, resulting in insufficient entropy. An attacker who obtains a JWT signed with the generated secret may be able to recover the JWT signing secret through offline brute-force, potentially enabling JWT forgery.

In Zimbra Collaboration (ZCS) before 10.1.17, a Cross-Site Request Forgery (CSRF) vulnerability exists in the Exchange Web Services (EWS) endpoint of Zimbra Collaboration (ZCS) due to insufficient validation of request content types. An attacker can exploit this vulnerability by causing an authenticated user to submit a crafted request, potentially allowing unauthorized actions to be performed on behalf of the victim.

In Zimbra Collaboration before 10.1.17, a local file inclusion (LFI) vulnerability exists in the Zimbra Classic Web Client due to improper validation of the fu request parameter. An unauthenticated attacker can exploit this vulnerability by supplying a crafted path, potentially allowing unauthorized disclosure of protected files, such as WEB-INF/web.xml, within the web application directory. This occurs in the Forward servlet.

In Zimbra Collaboration (ZCS) before 10.1.17, a path traversal vulnerability exists in the Zimbra Briefcase document editing functionality due to improper validation of the packages parameter. An authenticated attacker can exploit this vulnerability by supplying a crafted path traversal sequence, potentially allowing unauthorized disclosure of sensitive files within the web application directory.

In Zimbra Collaboration (ZCS) before 10.1.17, a stored cross-site scripting (XSS) vulnerability exists in the Zimbra Classic Web Client due to insufficient sanitization of specific attachment content during inline preview. An attacker can send a crafted email containing a malicious attachment that, when previewed by a user, executes arbitrary JavaScript within the victim's browser session. Successful exploitation may allow an attacker to perform unauthorized actions on behalf of the victim user, potentially leading to data exfiltration or unauthorized access to sensitive information.

An authorization bypass vulnerability exists in Zimbra Collaboration (ZCS) before 10.1.17 due to improper authorization validation in delegated email sending functionality. An authenticated attacker can send specially crafted SOAP requests to impersonate another user and send emails without possessing the required delegation or send-as permissions. This occurs in the SaveDraftRequest SOAP handler.

A remote code execution vulnerability exists in Zimbra Collaboration (ZCS) before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. Due to improper sanitization of untrusted input during SNMP notification processing, an unauthenticated attacker can send specially crafted SMTP requests that may result in execution of arbitrary operating system commands as the Zimbra user.

An issue was discovered in Zimbra Collaboration (ZCS) 10.0 and 10.1. A Cross-Site Request Forgery (CSRF) vulnerability exists in Zimbra Web Client due to the issuance of authentication tokens without CSRF protection during certain account state transitions. Specifically, tokens generated after operations such as enabling two-factor authentication or changing a password may lack CSRF enforcement. While such a token is active, authenticated SOAP requests that trigger token generation or state changes can be performed without CSRF validation. An attacker could exploit this by inducing a victim to submit crafted requests, potentially allowing sensitive account actions such as disabling two-factor authentication. The issue is mitigated by ensuring CSRF protection is consistently enforced for all issued authentication tokens.

Rejected reason: This CVE was rejected due to being a duplicate of CVE-2024-45519.

An issue was discovered in Zimbra Collaboration (ZCS) 10.0 and 10.1. A stored cross-site scripting (XSS) vulnerability exists in the Zimbra Briefcase feature due to insufficient sanitization of specific uploaded file types. When a user opens a publicly shared Briefcase file containing malicious scripts, the embedded JavaScript executes in the context of the user's session. This allows an attacker to run arbitrary scripts, potentially leading to data exfiltration or other unauthorized actions on behalf of the victim user.

An issue was discovered in Zimbra Collaboration (ZCS) 10.0 and 10.1. An XML External Entity (XXE) vulnerability exists in the Zimbra Exchange Web Services (EWS) SOAP interface due to improper handling of XML input. An authenticated attacker can submit crafted XML data that is processed by an XML parser with external entity resolution enabled. Successful exploitation may allow disclosure of sensitive local files from the server.

Zimbra Collaboration (ZCS) 10.0 and 10.1 contains an LDAP injection vulnerability in the Mailbox SOAP service within a FolderAction operation. The application fails to properly sanitize user-supplied input before incorporating it into an LDAP search filter. An authenticated attacker can exploit this issue by sending a crafted SOAP request that manipulates the LDAP query, allowing retrieval of sensitive directory attributes.

An issue was discovered in Zimbra Collaboration (ZCS) 10.0 and 10.1. A cross-site request forgery (CSRF) vulnerability exists in Zimbra Webmail due to improper validation of CSRF tokens. The application accepts CSRF tokens supplied within the request body instead of requiring them through the expected request header. An attacker can exploit this issue by tricking an authenticated user into submitting a crafted request. This may allow unauthorized actions to be performed on behalf of the victim.

Zimbra Collaboration Suite (ZCS) 10.0 and 10.1 contains a reflected cross-site scripting (XSS) vulnerability in the Classic Webmail REST interface (/h/rest). The application fails to properly sanitize user-supplied input, allowing an unauthenticated attacker to inject malicious JavaScript into a crafted URL. When a victim user accesses the link, the injected script executes in the context of the Zimbra webmail application, which could allow the attacker to perform actions on behalf of the victim.

A Local File Inclusion (LFI) vulnerability exists in the Webmail Classic UI of Zimbra Collaboration (ZCS) 10.0 and 10.1 because of improper handling of user-supplied request parameters in the RestFilter servlet. An unauthenticated remote attacker can craft requests to the /h/rest endpoint to influence internal request dispatching, allowing inclusion of arbitrary files from the WebRoot directory.

An issue was discovered in Zimbra Collaboration (ZCS) 10.0 and 10.1. A hardcoded Flickr API key and secret are present in the publicly accessible Flickr Zimlet used by Zimbra Collaboration. Because these credentials are embedded directly in the Zimlet, any unauthorized party could retrieve them and misuse the Flickr integration. An attacker with access to the exposed credentials could impersonate the legitimate application and initiate valid Flickr OAuth flows. If a user is tricked into approving such a request, the attacker could gain access to the user s Flickr data. The hardcoded credentials have since been removed from the Zimlet code, and the associated key has been revoked.

Zimbra Collaboration (ZCS) before 10.1.12 allows SSRF because of the configuration of the chat proxy.

A Cross-Site Request Forgery (CSRF) vulnerability exists in the ResetPasswordRequest operation of Zimbra Collaboration (ZCS) when the zimbraFeatureResetPasswordStatus attribute is enabled. An attacker can exploit this by tricking an authenticated user into visiting a malicious webpage that silently sends a crafted SOAP request to reset the user's password. The vulnerability stems from a lack of CSRF token validation on the endpoint, allowing password resets without the user's consent.

A vulnerability in the EnableTwoFactorAuthRequest SOAP endpoint of Zimbra Collaboration (ZCS) allows an attacker with valid user credentials to bypass Two-Factor Authentication (2FA) protection. The attacker can configure an additional 2FA method (either a third-party authenticator app or email-based 2FA) without presenting a valid authentication token or proving access to an already configured 2FA method. This bypasses 2FA and results in unauthorized access to accounts that are otherwise protected by 2FA.

An issue was discovered in Zimbra Collaboration (ZCS) through 10.1. A Cross-Site Scripting (XSS) vulnerability exists in Zimbra webmail due to insufficient validation of the content type metadata when importing files into the briefcase. Attackers can exploit this issue by crafting a file with manipulated metadata, allowing them to bypass content type checks and execute arbitrary JavaScript within the victim's session.

Zimbra Collaboration (ZCS) before 9.0.0 Patch 46, 10.0.x before 10.0.15, and 10.1.x before 10.1.9 is vulnerable to a denial of service condition due to improper handling of excessive, comma-separated path segments in the Admin Console. An unauthenticated remote attacker can send specially crafted GET requests that trigger redundant processing and inflated responses. This leads to uncontrolled resource consumption, resulting in denial of service.

An issue was discovered in Zimbra Collaboration (ZCS) 8.8.15 and 9.0 and 10.0 and 10.1. A Cross-Site Scripting (XSS) vulnerability in the Zimbra Classic UI allows attackers to execute arbitrary JavaScript within the user's session, potentially leading to unauthorized access to sensitive information. This issue arises from insufficient sanitization of HTML content, specifically involving crafted tag structures and attribute values that include an @import directive and other script injection vectors. The vulnerability is triggered when a user views a crafted e-mail message in the Classic UI, requiring no additional user interaction.

An issue was discovered in Zimbra Collaboration (ZCS) 9.0.0 before Patch 43, 10.0.x before 10.0.12, 10.1.x before 10.1.4, and 8.8.15 before Patch 47. A Cross-Site Scripting (XSS) vulnerability in the Zimbra Classic UI allows attackers to execute arbitrary JavaScript within the user's session, potentially leading to unauthorized access to sensitive information. This issue arises from insufficient sanitization of HTML content, including malformed <img> tags with embedded JavaScript. The vulnerability is triggered when a user views a specially crafted email in the Classic UI, requiring no additional user interaction.

In Zimbra Collaboration (ZCS) 9.0 through 10.1, a Cross-Site Request Forgery (CSRF) vulnerability exists in the GraphQL endpoint (/service/extension/graphql) of Zimbra webmail due to a lack of CSRF token validation. This allows attackers to perform unauthorized GraphQL operations, such as modifying contacts, changing account settings, and accessing sensitive user data when an authenticated user visits a malicious website.