CVE-2026-40300: Zulip Server Information Disclosure Flaw

CVE-2026-40300 Overview

CVE-2026-40300 is an access control vulnerability in Zulip, an open-source team collaboration platform. The flaw exists in the message edit history endpoint /api/v1/messages/{id}/history when administrators configure message_edit_history_visibility_policy to "moves". Under this setting, the endpoint continues to return prior content values, exposing text that users intended to remove through edits. Low-privilege authenticated users can query the endpoint and recover edited-away content from other users' messages. The issue affects Zulip Server versions prior to 12.0 and is tracked under [CWE-284 Improper Access Control]. Zulip resolved the vulnerability in version 12.0. The advisory is published as GHSA-jp8f-mvv6-89cr.

Critical Impact

Authenticated low-privilege users can retrieve previously edited message content from other users, breaking the confidentiality expectation set by the "moves" edit history policy.

Affected Products

• Zulip Server versions prior to 12.0
• Zulip Server 10.0 (confirmed in CPE data)
• Self-hosted Zulip deployments using message_edit_history_visibility_policy = "moves"

Discovery Timeline

• 2026-05-12 - CVE-2026-40300 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-40300

Vulnerability Analysis

The vulnerability resides in Zulip's message edit history API. Zulip allows administrators to control how much edit history is exposed to non-privileged users via the message_edit_history_visibility_policy setting. Setting this policy to "moves" is documented to expose only message movement events, such as topic or stream changes, while suppressing prior content revisions.

The /api/v1/messages/{id}/history endpoint did not enforce this restriction correctly. When clients requested history for a message, the server returned historical content fields alongside the move metadata. Any authenticated user with read access to the message could parse the response and reconstruct earlier text that the message author had edited or removed.

The defect is an authorization filtering failure rather than an authentication bypass. The API correctly validates the caller's session, but it does not strip content fields from the response payload when the visibility policy forbids them.

Root Cause

The root cause is improper enforcement of the configured visibility policy in the history endpoint response builder. The server treats "moves" as a UI-level hint rather than a server-side authorization boundary, returning the full edit history record regardless of the configured policy.

Attack Vector

An attacker requires a valid Zulip account on the target server and read access to the message of interest. The attacker issues an authenticated HTTP GET request to /api/v1/messages/{id}/history for any visible message. The response includes prior rendered_content and prev_content fields, which the attacker reads to recover text the author edited away. No elevated privileges, user interaction, or social engineering is required beyond standard authenticated access.

The vulnerability is described in prose only — no public proof-of-concept code is referenced in the advisory. See the Zulip security advisory GHSA-jp8f-mvv6-89cr for full technical details.

Detection Methods for CVE-2026-40300

Indicators of Compromise

• Unusual volume of authenticated GET requests to /api/v1/messages/{id}/history from a single account or API key
• Requests to the history endpoint for messages the requesting user did not author and did not recently interact with
• API access patterns from accounts that do not typically use programmatic clients

Detection Strategies

• Review Zulip server access logs for sustained or scripted access to the /api/v1/messages/*/history route
• Correlate history endpoint queries with subsequent data export or off-platform exfiltration activity
• Compare the configured message_edit_history_visibility_policy value against the content fields actually returned in API responses during testing

Monitoring Recommendations

• Forward Zulip nginx and application logs to a centralized logging or SIEM platform for retention and analysis
• Establish a baseline of normal history endpoint usage per user and alert on statistical deviations
• Monitor for newly created or recently dormant accounts issuing high-rate API calls to message endpoints

How to Mitigate CVE-2026-40300

Immediate Actions Required

• Upgrade Zulip Server to version 12.0 or later, which contains the fix
• Audit current value of message_edit_history_visibility_policy and identify deployments relying on the "moves" setting for confidentiality
• Review recent access logs for the /api/v1/messages/{id}/history endpoint and identify accounts that may have harvested edit history

Patch Information

The vulnerability is fixed in Zulip Server 12.0. Administrators of self-hosted instances should follow the standard Zulip upgrade procedure documented by the vendor. The official remediation is published in the Zulip security advisory GHSA-jp8f-mvv6-89cr.

Workarounds

• If immediate upgrade to 12.0 is not feasible, change message_edit_history_visibility_policy to a value that does not promise content suppression, and inform users that edits remain recoverable
• Restrict API access at the network layer to trusted clients while planning the upgrade
• Rotate API keys for service accounts and re-evaluate which users require message read access on sensitive streams

# Verify installed Zulip Server version
/home/zulip/deployments/current/manage.py version

# Upgrade self-hosted Zulip Server (run as the zulip user)
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git main