OTRS EUVD-2026-97269

Exploitation requires (1) an OTRS instance configured with two or more CustomerUser backends simultaneously - e.g. a database backend plus an LDAP backend - since the flaw is the per-backend-only uniqueness check; and (2) an authenticated account holding the permission to create or modify customer users (an operator/admin-level capability). Single-backend deployments are not affected, and unauthenticated users cannot exploit this (the advisory explicitly states it does not allow unauthenticated account creation). The practical limiting factors are therefore the non-default multi-backend configuration and the privileged customer-user-management permission, both of which substantially narrow realistic exploitability below the raw CVSS score.

This is a genuine but moderate-priority issue, not an urgent emergency. The CVSS 3.1 base score of 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) is driven by low confidentiality and integrity impact and requires authentication (PR:L), which caps the real-world severity. No EPSS score, SSVC decision, KEV listing, or proof-of-concept was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vulnerability is a logic/data-integrity flaw (CWE-694, inconsistent enforcement of identity uniqueness across multiple CustomerUser backends) rather than a memory-corruption or RCE class issue, so even successful exploitation yields information misrouting/exposure, not system compromise. One signal to weigh carefully: although the CVSS vector lists PR:L, exploitation requires the specific administrative capability to create or modify customer users - a privileged operator role, not an ordinary authenticated user - which in practice narrows the attacker population and lowers likelihood below what a generic PR:L score implies. Net assessment: a legitimate medium-risk hygiene fix for environments running multiple CustomerUser backends, but low urgency absent exploitation signals; patch on a normal cycle.

An OTRS environment is configured with two or more CustomerUser backends (for example a local database plus an LDAP directory). An authenticated operator who holds the permission to create or modify customer users adds a customer record in one backend reusing an email address that already identifies a different customer in another backend. Because the uniqueness check runs only within the selected backend, two records now represent the same communication identity, and depending on backend resolution order, subsequent tickets, customer data, or email replies may be routed to or exposed to the wrong customer user. No public exploit code was provided in the input.