SECURITY ADVISORY – CRITICAL
Authentication bypass via client-supplied `Remote-User` header
Only on systems with an ‘HTTPBasicAuth` backend configured
- PUBLISHING DATE:
- RELEASE TYPE:
- CRITICALITY:
- RELEASE:
- 16 September 2026
- Security Patches
- High
- 10.1.19 – 11.0.18 – 11.1 Beta 3
In very specific configurations, attackers had the possibility to exploit rights or access foreign sessions in OTOBO environments using ‘HTTP Basic Auth’.
This article provides all the details about the security vulnerability closed with the patches released today – including which systems are specifically affected and concrete recommendations for action in the different scenarios.
Details regarding the patched vulnerability
Both `HTTPBasicAuth` authentication backends accept a user identity that is supplied by the HTTP client. Whenever there is no `REMOTE_USER` provided by the server, the backend falls back to the value of the HTTP request header `Remote-User`, which any client can set.
No password is verified in this scenario.
In an affected installation an unauthenticated attacker who can reach an OTOBO endpoint that is not covered by an external single sign-on (SSO) enforcement can autheticate as an arbitrary user –including a system administrator – by sending a single HTTP header.
This vulnerability can be exploited, in particular, where the GenericInterface endpoint `/otobo/nph-genericinterface.pl` is excluded from SSO. Here, API clients that do not speak Kerberos nor SAML can bypass SSO and authenticate directly with OTOBO.
Who’s affected?
The vulnerability applies exclusively to systems that meet all three of the following criteria:
- An `HTTPBasicAuth` module is configured as an agent (`AuthModule`) and/or customer (`Customer::AuthModule`) authentication backend.
- OTOBO is reached through a reverse proxy or a web server that forwards, or fails to strip, the `Remote-User` header. (The normal situation for every containerized deployment and for any nginx/Apache/Traefik reverse-proxy setup, because a proxy can only transport an identity in an HTTP
header.) - At least one endpoint is reachable without the proxy’s SSO enforcement, such as a deliberate exclusion for the GenericInterface, direct network access to the application port, or any location that does not apply the SSO module.
Installationen, bei denen der Webserver die Anfrage selbst authentifiziert und die PSGI-Variable `REMOTE_USER` setzt (beispielsweise Apache mit `mod_auth_gssapi` im CGI-, FastCGI- oder mod_perl-Modus), sind nicht direkt über die Variable – dennoch aber durch den Header-Fallback auf allen nicht derart geschützten Endpoint betroffen.
Installations where the web server authenticates the request itself and sets the PSGI variable `REMOTE_USER` (for example Apache with `mod_auth_gssapi` in CGI, FastCGI or mod_perl mode) are not affected through that variable. However, they are still affected through the header fallback on any endpoint that is not protected.
The solution
The security vulnerability is resolved by installing the security patches released today: OTOBO 10.1.19 [Link], OTOBO 11.0.18 , and OTOBO 11.1 Beta 3 [Link].
With these patches, the header route now requires an active opt-in.
Instead of using an arbitrary ‘Remote-User’ variable, the header will be ignored in the future unless – both – of the following conditions are met:
- the new option `AuthModule::HTTPBasicAuth::TrustProxyHeader` (or `Customer::AuthModule::HTTPBasicAuth::TrustProxyHeader`) is enabled – and
- the request includes a shared secret that the reverse proxy uses to identify itself. The value entered for the `WebServer::ProxySecret` variable is sent in the HTTP header as `X-OTOBO-Proxy-Secret`. If containers are in use, the shared secret can also be defined via the `OTOBO_PROXY_SECRET` environment variable.
The verification takes place in real time.
The shared secret works for nginx, Apache (mod_proxy), and Traefik because, in each case, the proxy sets a single request header that overrides any values potentially sent by the client. We also recommend keeping the OTOBO application port inaccessible to untrusted networks.
Existing traditional Apache SSO implementations continue to function as before: The ‘REMOTE_USER’ value set by the web server itself continues to be accepted.
The Nginx templates and Apache sample configurations included in the standard have also been updated. They now include secure defaults – including, specifically, secure sample configurations for exceptions for the REST API interface (“GenericInterface”) – as well as all the information necessary to ensure secure operation.
Following the update
Nothing to Do on Systems without an `HTTPBasicAuth` Authentication Backend
The `WebServer::ProxySecret` setting is read only by `Kernel::System::Auth::HTTPBasicAuth` and `Kernel::System::CustomerAuth::HTTPBasicAuth`, and only when the `TrustProxyHeader` option is enabled. Environments where authentication is performed via a database, LDAP, OpenID Connect, RADIUS, or similar backends are not affected. In these cases, no secret needs to be defined.
What you Need to Do for Systems using `HTTPBasicAuth` with the `Remote-User` Header
(Reverse Proxy SSO)
The fix for systems that use `HTTPBasicAuth` with the `Remote-User` header (reverse proxy SSO) is intentionally designed to be “fail-closed”: In affected systems, user authentication is suspended until the new configuration has been applied.
Steps to restore SSO functionality:
1. Enable `AuthModule::HTTPBasicAuth::TrustProxyHeader` (and/or the customer variant).
2. Configure `WebServer::ProxySecret` (or the environment variable `OTOBO_PROXY_SECRET`).
3. Configure the reverse proxy: Remove remote user headers sent by clients and send the secret via `X-OTOBO-Proxy-Secret`. These adjustments are already included in the templates provided in the standard release.
What Users of Our Official Docker HTTPS/Kerberos Stacks Need to Do
Docker users who use our official HTTPS/Kerberos stacks simply need to set the `OTOBO_PROXY_SECRET` in the .env file; it is automatically passed to nginx and the OTOBO container.
Workaround – if an update is not immediately possible
We strongly recommend that all users who cannot update their systems immediately take the following steps until the update is available:
- Remove the “Remote-User” header (all variations) from incoming client requests on the reverse proxy for all locations.
- Ensure that the application port is inaccessible from untrusted networks.
- Where possible, temporarily disable the ‘HTTPBasicAuth’ option for affected endpoints.
Credits
Thank you to Mokrane ABDELMALEK for the responsible disclosure of this vulnerability. The issue, which had been there for over ten years, was identified as part of the Ghent University VDP program.
Release Notes
OTOBO 10.1.19 – Security Patch
OTOBO 11.0.18 – Security Patch
OTOBO 11.1.0 (Beta3) – Security Patch
Please update your system as soon as possible
Thank you to everyone who contributed!
Need support?
We’re happy to help. Just get in touch.
Company
OTOBO | Simplify work and create exceptional service experiences.
The Source Code Owner and Maintainer of OTOBO.
Software
Service Management Platform
OTOBO Demo
OTOBO Download
OTOBO Documentation
Report a security issues:
security@otobo.org
