CVE-2026-115574 in Zulip
Summary
by MITRE • 11/04/2026
Zulip is an open-source team collaboration tool. From 11.0 until 12.2, organizations with web-public channels enabled exposed the GET /json/users endpoint to logged-out spectators, and a missing access-control check allowed include_custom_profile_fields=true to return every user's custom profile field values in addition to the documented limited directory data. This exposed those custom profile field values to unauthenticated visitors. This issue is fixed in version 12.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified within Zulip versions ranging from 11.0 through 12.2 represents a critical failure in access control mechanisms, specifically affecting organizations that have enabled web-public channels. Web-public channels are designed to allow unauthenticated visitors to view specific public content without logging in, thereby facilitating open collaboration and information sharing with the broader internet or external stakeholders. However, this feature inadvertently created an attack surface where sensitive internal data could be exfiltrated by unauthorized actors due to a missing access-control check on the GET /json/users endpoint. This API endpoint is typically intended for retrieving user directory information but was improperly exposed to logged-out spectators when web-public channels were active, violating the principle of least privilege and proper separation between public-facing interfaces and internal administrative data structures.
The technical flaw centers on the inclusion_custom_profile_fields parameter within the users endpoint request. When this parameter is set to true, the API returns not only the standard limited directory data such as names and email addresses but also all custom profile field values associated with every user in the organization. Custom profile fields are often used by organizations to store sensitive or semi-sensitive information about employees, including departmental roles, internal contact numbers, employee IDs, location details, or other personally identifiable information configured for administrative purposes. Because the access control logic failed to verify whether the requesting entity was authenticated and authorized to view this specific subset of data, any unauthenticated visitor could retrieve these fields by simply appending include_custom_profile_fields=true to their request against the users endpoint. This constitutes a classic Broken Access Control vulnerability where the server fails to properly enforce restrictions on what authenticated or unauthenticated users are allowed to access.
The operational impact of this vulnerability is significant for organizations relying on Zulip as their primary communication platform, particularly those with large user bases and extensive use of custom profile fields. The exposure allows an attacker to perform a comprehensive enumeration of internal personnel data without needing valid credentials. This information can be leveraged for subsequent attacks such as targeted phishing campaigns, social engineering efforts, or credential stuffing attempts where the attacker already possesses accurate personal details about potential victims. Furthermore, the aggregation of this data contributes to privacy violations and may breach regulatory compliance requirements such as GDPR or HIPAA if the custom fields contain protected health information or other regulated personal data. The ability to scrape user profiles en masse also aids in building detailed organizational charts for reconnaissance purposes, which is a common precursor step in advanced persistent threat campaigns.
This vulnerability aligns with CWE-284 Improper Access Control and falls under MITRE ATT&CK technique T1078 Valid Accounts if the attacker were to use stolen credentials, but more accurately maps to T1596 Search Open Technical Databases or T1087 Account Discovery when considering unauthenticated enumeration. The root cause is a logic error in the API layer where the permission check for custom profile fields was not correctly scoped to authenticated users only, despite being part of an endpoint that had public access enabled under specific channel configurations. To mitigate this issue and prevent similar occurrences, organizations must ensure they are running version 12.2 or later of Zulip, which includes the necessary patches to restrict access to sensitive user data fields. Additionally, security teams should audit their API endpoints for proper authorization checks, ensuring that any parameter allowing retrieval of detailed user attributes is strictly gated behind authentication and appropriate role-based permissions. Regular penetration testing focused on broken object level privileges can help identify such misconfigurations before they are exploited in the wild.