CVE-2026-78359 in OTRS
Summary
by MITRE • 10/12/2026
OTRS does not sufficiently enforce the uniqueness of customer user identities across multiple configured CustomerUser backends. When multiple backends, such as a database and LDAP, are configured, the uniqueness check for customer user email addresses is performed only within the selected backend. As a result, an authenticated user with permission to create or modify customer users may create a customer user whose email address is already assigned to a customer user in another backend.
This can result in multiple customer user records representing the same communication identity. Depending on the affected workflow and backend resolution, customer-related information or email communication may subsequently be associated with or exposed to the wrong customer user.
The vulnerability does not allow unauthenticated users to create customer accounts. Exploitation requires permissions to create or modify customer users.
This issue affects OTRS:
* 7.0.X * 8.0.X * 2023.X * 2024.X * 2025.X * 2026.X before 2026.7.X
Please note that ((OTRS)) Community Edition 6.x and before are vulnerable. Products based on the ((OTRS)) Community Edition also very likely to be affected
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in OTRS represents a critical flaw in identity management logic, specifically concerning how unique constraints are enforced across heterogeneous data sources. In enterprise environments, it is common practice to configure multiple CustomerUser backends to aggregate user identities from disparate systems such as relational databases and Lightweight Directory Access Protocol servers. The core technical failure lies in the application's handling of uniqueness checks during the creation or modification of customer user records. Instead of performing a global validation across all configured backend sources, OTRS restricts its uniqueness verification solely to the currently selected backend. This architectural oversight means that if an administrator creates a new customer user via a database interface with an email address already present in an LDAP directory, the system will accept this action without raising any conflict or error. The application fails to cross-reference identities across the entire federation of backends, treating each source as an isolated silo rather than part of a unified identity pool.
This lack of global uniqueness enforcement leads directly to data integrity issues and potential security risks through identity confusion. When multiple distinct customer user records exist for the same email address due to this flaw, subsequent operations involving that communication channel become ambiguous. Depending on how the application resolves which backend takes precedence during authentication or lookup processes, critical information may be associated with the wrong entity. For instance, sensitive ticket history, personal data, or correspondence intended for one specific customer could inadvertently be exposed to another user record sharing the same email address. This scenario effectively creates a form of identity collision that can lead to unauthorized access to private communications or incorrect attribution of actions within the help desk system. The impact is particularly severe in organizations where strict separation of duties and accurate audit trails are required for compliance purposes.
From an exploitation perspective, this vulnerability requires authenticated access with specific privileges rather than being exploitable by unauthenticated attackers. An adversary must possess permissions to create or modify customer user accounts within OTRS. This constraint limits the attack surface to insider threats or compromised administrative credentials but does not diminish the severity of the potential data leakage and integrity violations that can occur once such access is obtained. The flaw affects a wide range of OTRS versions, including 7.0.X through 2026.X prior to version 2026.7.X, as well as older Community Edition releases like 6.x and earlier. Products built upon the OTRS community edition are also highly susceptible due to shared codebases inheriting this structural deficiency in identity management logic.
To mitigate this risk, organizations must ensure that their OTRS instances are upgraded to version 2026.7.X or later where the uniqueness check has been corrected to encompass all configured backends. For environments unable to upgrade immediately, manual audits of customer user records across different backend sources can help identify and resolve existing duplicate email addresses. Administrators should also consider implementing stricter access controls on account creation functions to limit exposure until patches are applied. This issue aligns with CWE-642, which describes External Control of Critical State Data, as the application fails to properly validate input against a global state constraint. Furthermore, it relates to ATT&CK technique T1078, Valid Accounts, specifically in the context of abusing legitimate credentials and permissions to manipulate identity data for unauthorized information access or evasion of detection through identity confusion.