Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify OTRS CE 6 with Basic Auth under CGI/mod_perl
-
DeliveryCraft request with forged Remote-User header
-
ExploitHeader mapped to HTTP_REMOTE_USER env var
-
ExecutionOTRS trusts value, skips password check
-
PersistAuthenticate as targeted agent/customer via Generic Interface
-
ImpactAccess confidential data and modify configuration
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Anti-spoofing controls
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires TWO specific conditions to hold simultaneously: (1) HTTP Basic Authentication must be configured as the active authentication backend in OTRS, and (2) the OTRS instance must run in a CGI or mod_perl deployment where the web server maps arbitrary inbound HTTP request headers into corresponding HTTP_* environment variables (exposing a forged 'Remote-User' header as HTTP_REMOTE_USER). Only OTRS ((Community Edition)) 6.x and prior, plus derivative products, are affected. Limiting factors that reduce real-world exploitability: it does NOT work on default installations lacking Basic Auth, does NOT affect OTRS 7+ (which uses Mojolicious/Hypnotoad and validates REMOTE_USER via an SSO shared secret), and the achievable impact is bounded by the privileges of whichever existing agent or customer account the attacker chooses to impersonate (the attacker must know a valid target username). |
| Impact | The vendor-supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:L, score 9.4) frames this as a trivially exploitable, network-reachable, unauthenticated authentication bypass (CWE-290) - on paper a top-priority flaw. However, the description materially qualifies that picture: exploitation is NOT possible against a default install. Two specific preconditions must both hold - HTTP Basic Authentication must be the configured authentication backend, AND the deployment must be CGI or mod_perl based such that inbound HTTP headers are mapped into HTTP_* environment variables. This makes the AC:L rating optimistic; the real-world attack complexity is higher because it depends on a non-default, operator-chosen configuration, which is why this analysis independently downgrades to AC:H / AT:P. No EPSS score, CISA KEV entry, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the sole source is the vendor's own advisory (OTRS-SA-2026-18). The net assessment: a genuinely serious, easy-to-weaponize bypass WHERE the vulnerable configuration exists, but the configuration dependency and the EOL status of the affected product (Community Edition 6.x and prior) likely narrow the exposed population considerably. Treat as high priority for anyone still running OTRS CE 6 with Basic Auth under CGI/mod_perl; lower practical urgency elsewhere. |
| Exploit ScenarioDerived | An attacker identifies an internet-facing OTRS Community Edition 6.x Generic Interface endpoint running under CGI/mod_perl with HTTP Basic Authentication as the backend. They send a request containing a forged 'Remote-User' HTTP header set to the username of an existing agent or administrator; the web server exposes it as HTTP_REMOTE_USER, which OTRS trusts as an already-authenticated identity without any password check. No public exploit code was provided in the input, but the technique is a simple single-header spoof requiring no special tooling. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Authentication bypass in ((OTRS)) Community Edition 6.x and earlier lets an unauthenticated remote attacker impersonate any existing agent or customer account when HTTP Basic Authentication is the configured authentication backend. Because the CGI/mod_perl deployment maps an attacker-supplied 'Remote-User' request header into the HTTP_REMOTE_USER environment variable, OTRS treats that header value as an already-authenticated username and skips password verification, after which the Generic Interface can be accessed with the impersonated account's privileges. Exploitation is not unconditional: it requires Basic Auth to be the active backend, a CGI/mod_perl (not Mojolicious/Hypnotoad) deployment, and knowledge of a valid target username, which is why an independent assessment rates the attack complexity as High (AC:H) rather than the vendor's AC:L, and no public exploit code was identified at time of analysis. OTRS 7 and later are unaffected by this vector.
RemediationAI
The definitive fix is to migrate to OTRS 7 or later, which uses Mojolicious/Hypnotoad, does not expose arbitrary request headers through %ENV, and additionally validates REMOTE_USER against a configured SSO shared secret; the unsafe HTTP_REMOTE_USER fallback has been removed in those releases as a hardening measure. For ((OTRS)) Community Edition 6.x deployments that cannot be migrated - no vendor-released patch for the CE 6.x line was identified in the available data - apply compensating controls at the web-server layer: configure the server to strip or overwrite any inbound Remote-User header before it reaches the application (for example with mod_rewrite/mod_headers SetEnvIf rules or the equivalent in your server), and ensure REMOTE_USER is only ever populated by the trusted authentication module rather than derived from client-supplied headers; the trade-off is that aggressive header stripping may break other proxies or SSO integrations that legitimately forward Remote-User. Where feasible, switch away from HTTP Basic Authentication as the OTRS authentication backend, since the flaw is only reachable when Basic Auth is active - this removes the attack path entirely at the cost of reconfiguring user authentication. Restricting network access to the OTRS Generic Interface and web UI to trusted networks or a reverse proxy that normalizes and validates headers reduces exposure but is a defense-in-depth measure, not a substitute for migration. Patch and upgrade guidance should be tracked against the vendor advisory at https://otrs.com/release-notes/otrs-security-advisory-2026-18/.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-290 (Authentication Bypass by Spoofing): OTRS's HTTP Basic Authentication modules resolve the authenticated identity from either the REMOTE_USER or HTTP_REMOTE_USER environment variable instead of from a verified credential exchange. In CGI and mod_perl deployments, web servers conventionally translate inbound HTTP request headers into environment variables prefixed with HTTP_ (for example, a client-sent 'Remote-User: admin' header becomes HTTP_REMOTE_USER for the application). Because OTRS accepts HTTP_REMOTE_USER as a trusted, pre-authenticated username when the Basic Auth backend is active, an attacker who controls a request header can assert any identity the application already knows. The problem is architectural - trusting a namespace (HTTP_*) that is populated from untrusted client input rather than from the server's own authentication module. The design is only safe when the web server injects REMOTE_USER itself after a successful credential check and no client-controlled header can reach the same variable. OTRS 7+ largely sidesteps the class of flaw by moving to Mojolicious/Hypnotoad, which does not expose arbitrary request headers through %ENV, and by requiring REMOTE_USER to be validated against a configured SSO shared secret; the residual HTTP_REMOTE_USER fallback was removed there as a hardening measure.
Know when Otrs gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
PR:N since no credentials are needed, but AC:H because success depends on a non-default Basic-Auth backend plus a CGI/mod_perl header-to-env configuration; C/I:H and A:L reflect impersonated-account privileges.
Primary rating from Vendor (OTRS).
CVSS VectorVendor: OTRS
DescriptionCVE.org
The HTTP Basic Authentication modules in ((OTRS)) Community Edition 6 and prior accept the authenticated username from either the REMOTE_USER or HTTP_REMOTE_USER environment variable. In CGI and mod_perl based deployments, HTTP request headers may be mapped to corresponding HTTP_* environment variables. As a result, an unauthenticated remote attacker can supply a crafted Remote-User request header which is exposed to the application as HTTP_REMOTE_USER. When HTTP Basic Authentication is configured as the authentication backend, OTRS trusts this value as an already authenticated username and does not perform an additional password verification. An attacker may therefore authenticate through the Generic Interface as an existing agent or customer user without knowing the corresponding credentials.
The resulting privileges depend on the account being impersonated. Successful exploitation may allow access to confidential information and modification of data or configuration with the permissions of the affected user. Exploitation requires HTTP Basic Authentication to be configured as an authentication backend and a web server environment in which attacker-controlled HTTP headers are exposed through the corresponding HTTP_* environment variables.
OTRS 7 and later are not affected by this attack vector due to the use of Mojolicious/Hypnotoad and does not expose arbitrary request headers through %ENV in the manner required for exploitation. The supported REMOTE_USER mechanism additionally requires validation through the configured SSO shared secret. The unused HTTP_REMOTE_USER fallback has nevertheless been removed as a security-hardening measure.
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 ViewAI
A critical authentication bypass in OTRS Community Edition 6.x and earlier allows an outside party to impersonate any existing agent or customer account without a password, potentially exposing service desk tickets, customer records, and internal communications, and permitting actions through the Generic Interface under a trusted identity. Organizations running OTRS 6 or older on a CGI/mod_perl deployment with HTTP Basic Authentication as the active backend are affected, and no vendor patch is available. Because the flaw removes the credential check entirely rather than merely weakening it, security leadership should treat this as a priority exposure until affected instances are reconfigured or upgraded.
No vendor-released patch identified at time of analysis. Interim mitigations: disable HTTP Basic Authentication as the authentication backend, migrate from CGI/mod_perl to Mojolicious/Hypnotoad, strip or block inbound Remote-User headers at the reverse proxy, restrict agent and Generic Interface access to trusted networks, and upgrade to OTRS 7 or later, which is unaffected by this vector.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
In OTRS 6.0.x up to and including 6.0.1, OTRS 5.0.x up to and including 5.0.24, and OTRS 4.0.x up to and including 4.0.2
In the Admin Package Manager in Open Ticket Request System (OTRS) 5.0.0 through 5.0.24 and 6.0.0 through 6.0.1, authenti
Multiple cross-site request forgery (CSRF) vulnerabilities in (1) CustomerPreferences.pm, (2) CustomerTicketMessage.pm,
Open Ticket Request System (OTRS) 3.3.9 has XSS in index.pl?Action=AgentStats requests, as demonstrated by OrderBy=[XSS]
Improper Input Validation vulnerability in the upload functionality for user avatars allows functionality misuse due to
Improper Input Validation vulnerability in OTRS AG OTRS, OTRS AG ((OTRS)) Community Edition allows SQL Injection via Tic
Multiple SQL injection vulnerabilities in the FAQ package 2.x before 2.3.6, 4.x before 4.0.5, and 5.x before 5.0.5 in Op
Cross-site scripting (XSS) vulnerability in Open Ticket Request System (OTRS) Help Desk 2.4.x before 2.4.15, 3.0.x befor
OTRS fails to immediately invalidate previously issued JWT authentication tokens when an agent or customer user account
Unauthenticated SQL injection in OTRS and the legacy ((OTRS)) Community Edition database layer enables authentication by
The functions to fetch e-mail via POP3 or IMAP as well as sending e-mail via SMTP use OpenSSL for static SSL or TLS base
In Open Ticket Request System (OTRS) 3.3.x through 3.3.16, 4.x through 4.0.23, and 5.x through 5.0.19, an attacker with
EUVD-2026-97258
GHSA-prj2-j7v3-mhcv
NVD
CVE.org
EPSS
VulDB
Exploit-DB