CVE-2026-93483 in Znuny
Summary
by MITRE • 10/15/2026
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{REMOTE_USER} (set by the web server after successful authentication), but also, as a fallback, from $ENV{HTTP_REMOTE_USER}, 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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Znuny versions through 7.3.6 represents a critical failure in input validation and trust boundaries within the application's authentication subsystem. Specifically, this flaw resides in the HTTPBasicAuth modules for both agent and customer interfaces, designated technically as Kernel::System::Auth::HTTPBasicAuth and Kernel::System::CustomerAuth::HTTPBasicAuth respectively. The core technical issue stems from an insecure design pattern where the application logic incorrectly trusts user-supplied input that is intended to be controlled by infrastructure components rather than end-users. In a standard web architecture, environment variables such as REMOTE_USER are typically set by reverse proxies or web servers like Apache or Nginx after they have successfully performed their own authentication checks against an upstream identity provider. However, the Znuny implementation includes a fallback mechanism that reads from HTTP_REMOTE_USER if REMOTE_USER is not present. This variable is populated directly from the Remote-User request header sent by the client, which is fully controllable by any attacker making HTTP requests to the application.
This architectural flaw allows for complete authentication bypass and identity impersonation without requiring valid credentials such as passwords or API keys. An attacker can simply craft a malicious HTTP request containing a forged Remote-User header with the username of any existing user in the Znuny system, including high-privilege administrators. Because the application accepts this value as authoritative proof of identity when the primary REMOTE_USER variable is absent, it logs the attacker into the targeted account immediately. This bypasses all standard login procedures and security controls designed to verify user identity. The impact is severe, granting unauthorized access to sensitive system functions, confidential customer data, internal tickets, and administrative configuration panels. Since Znuny is often used for IT service management containing proprietary business information, this exposure can lead to significant data breaches, regulatory non-compliance, and operational disruption.
From a classification perspective, this vulnerability aligns with CWE-287, which describes Improper Authentication, specifically the failure to properly verify credentials or trust external sources of identity without validation. It also maps closely to CWE-345, Insufficient Verification of Data Authenticity, as the application fails to ensure that the HTTP_REMOTE_USER variable originates from a trusted source rather than an untrusted client input. In terms of offensive security frameworks, this attack vector corresponds to ATT&CK technique T1078, Valid Accounts, where adversaries use legitimate credentials or impersonate valid users to gain access. Furthermore, it relates to T1621, Multi-Factor Bypass, in contexts where the Remote-User header might have been intended as part of a multi-factor authentication chain provided by an external proxy, which is now circumvented entirely.
Mitigation strategies must focus on eliminating the trust placed in untrusted headers and enforcing strict input validation at the application boundary. The most effective immediate remediation is to disable or remove the fallback logic that reads from HTTP_REMOTE_USER within the Kernel::System::Auth::HTTPBasicAuth and Kernel::System::CustomerAuth::HTTPBasicAuth modules if external proxy-based authentication is not strictly required, or to ensure that REMOTE_USER is always set by a trusted reverse proxy before reaching Znuny. If header-based authentication is necessary, administrators should configure their web server or load balancer to strip the Remote-User header from incoming requests and only populate it internally after successful upstream authentication. Additionally, implementing strict access control lists on the application interface can prevent direct internet exposure of endpoints that rely on this mechanism until patches are applied. Organizations running Znuny 7.3.6 or earlier should upgrade to a patched version immediately where this fallback behavior has been removed or secured against header injection attacks.