Znuny through 7.3.6 constructs a ticket-search database query by directly concatenating user-supplied input into the SQL statement. This lack of proper sanitization or the use of parameterized queries allows an attacker to inject arbitrary SQL commands, leading to data theft, modification, or denial of service. Specifically this is in Kernel::System::Ticket::TicketSearch and Kernel::System::Ticket::ArticleSearchIndex::DB via the ContentSearch parameter. The parameter is expected to be either "AND" or "OR", but its value was concatenated directly into the generated SQL query without validation.

In Znuny through 7.3.6, an attacker can bypass specific standard login procedures and gain unauthorized access to sensitive system functions by manipulating a specific HTTP request header. Because the application incorrectly trusts this header, an attacker can impersonate any user, including administrators, without requiring a password. This grants full access to confidential data and system controls. More specifically, the HTTPBasicAuth modules for the agent (Kernel::System::Auth::HTTPBasicAuth) and customer (Kernel::System::CustomerAuth::HTTPBasicAuth) interfaces read the username to log in not only from $ENV{REMOTEUSER} (set by the web server after successful authentication), but also, as a fallback, from $ENV{HTTPREMOTEUSER}, which is populated directly from an attacker-controllable "Remote-User" request header. On systems where HTTPBasicAuth was configured as the authentication backend, this allowed an attacker to log in as any existing user by sending a request with a forged Remote-User header, without providing any credentials.

In Znuny LTS before 6.5.21 and Znuny before 7.3.3, there is reflected XSS in

AdminCommunicationLog (aka the communication log administration view).

In Znuny LTS before 6.5.21 and Znuny before 7.3.3, XSS can occur via stored user preferences.