Description

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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-12T07:16:37.423Z",
  "pubdate": "2026-10-12T07:16:37.423Z",
  "executiveSummary": "The vulnerability involves a flaw in identity management within OTRS when utilizing multiple CustomerUser backends simultaneously, such as a combination of LDAP and database-backed storage.\nThe core issue is an insufficient validation mechanism that only enforces email address uniqueness within the scope of a single backend rather than across the entire application's authentication infrastructure.\nThis vulnerability allows an authenticated user with administrative or user-management privileges to create or modify customer identities that conflict with existing records in separate backends.\nImpact includes the potential for data leakage, unauthorized access to communication threads, and the merging of distinct user identities into a single logical entity, compromising the integrity of customer support workflows.\nExploitation requires an attacker to already possess the permissions necessary to manage customer accounts within the system; it is not accessible to unauthenticated or guest users.\nAffected products include OTRS versions 7.0.X, 8.0.X, 2023.X, 2024.X, 2025.X, and versions of 2026.X prior to 2026.7.X, as well as legacy ((OTRS)) Community Edition 6.x and earlier.",
  "technicalDetails": "The vulnerability resides in the identity management module responsible for creating and updating CustomerUser accounts. When OTRS is configured to authenticate or retrieve user information from multiple backends (e.g., local database vs. remote LDAP directory), the system performs a uniqueness constraint check on the email address field to prevent duplicate identities.\nThe root cause is a scope-limited validation logic. Instead of querying all configured backends to verify the global uniqueness of an email address, the validation function is restricted to the specific backend where the record is being created or modified. This creates a namespace collision condition.\nAttack Flow: An attacker with sufficient privileges to manage customer accounts identifies an email address belonging to an existing user in Backend A (e.g., an LDAP directory). The attacker then uses the administrative interface to create a new customer identity in Backend B (e.g., the local database) using the same email address found in Backend A.\nBecause the validation check is local to Backend B, it does not detect the existence of the user in Backend A, allowing the creation of a duplicate identifier.\nPost-Exploitation Impact: Once the duplicate identity is created, the OTRS session management and backend resolution logic may become ambiguous. Depending on the backend priority configuration and lookup order, system workflows may incorrectly resolve the email identity. This can lead to sensitive ticket information, private email communications, or user data being associated with the wrong account record, effectively exposing information to the unauthorized entity created by the attacker.\nThis issue is strictly a logical flaw in the identity verification process and does not involve memory corruption or code injection. It requires the attacker to have pre-existing high-level privileges to manipulate customer accounts. The lack of global cross-backend synchronization ensures that even with complex multi-source identity environments, the application fails to maintain the integrity of the user registry.\nAffected versions include 7.0.X, 8.0.X, 2023.X, 2024.X, 2025.X, and 2026.X prior to 2026.7.X. Legacy versions, including ((OTRS)) Community Edition 6.x and earlier, remain inherently vulnerable to this architectural defect."
}