OTRS helpdesk auth-bypass flaw, no login needed (CVE-2026-48188)

The helpdesk platform OTRS has a vulnerability, CVE-2026-48188 (rated 9.1 "Critical" out of 10), that lets an attacker break in from outside without ever logging in. OTRS is software that records inquiries from customers and employees as tickets and tracks how each one is handled. When this flaw is exploited, someone with no login credentials at all can impersonate a legitimate user and slip inside the system from across the network.

There is one clear trigger condition, however. The flaw applies only when the database is MySQL or MariaDB and its setting is in a specific mode called NO_BACKSLASH_ESCAPES. Any configuration that does not match this condition is not affected. Being able to determine first whether your own environment falls under this condition is the single most important point here.

The affected versions are OTRS 7.0.X / 8.0.X / 2023.X / 2024.X / 2025.X, the 2026.X line before 2026.4.X, and the formerly free OTRS Community Edition 6.0.x and products derived from it. The fix is in OTRS 2026.4.X and later. The primary source is OTRS Security Advisory 2026-02, published by vendor OTRS AG.

What Is OTRS?

OTRS (Open Ticket Request System) is a ticketing platform that logs each internal or external inquiry as a "ticket" and lets you track who handled it, when, and how. It has been widely used for customer support desks, internal IT helpdesks, and IT Service Management (ITSM, the practice of systematizing the operational work of IT departments). It comes from the German vendor OTRS AG, which today focuses on its commercial editions.

A free OTRS Community Edition was once widely deployed, but its development has ended. A community fork called Znuny has taken over as its successor. Because this vulnerability covers not only commercial OTRS but also the unmaintained Community Edition 6.0.x and products based on it, organizations still self-hosting the free edition are in the most dangerous position.

Are You Affected? (How to Check)

This is not "everyone running it is exposed"; it depends on your database setting. Checking the following two things in order tells you whether your environment is at risk.

First, check the database SQL mode. If OTRS runs on MySQL or MariaDB, run the command SELECT @@sql_mode; against the database. If the returned string contains NO_BACKSLASH_ESCAPES, you meet the affected condition. If it does not, you are not affected (the same applies if you use another database such as PostgreSQL).

Second, check the version. If the SQL mode above matched and OTRS is 7.0.X / 8.0.X / 2023.X / 2024.X / 2025.X, or a 2026.X before 2026.4.X, or Community Edition 6.0.x (and its derivatives), you are affected. If you have already updated to OTRS 2026.4.X or later, you are fixed regardless of the SQL mode. The table below summarizes the verdict for each combination of edition and SQL mode.

The Lock on the Inquiry Box Can Be Picked from Outside

What makes this flaw stand out is that exploiting it requires no login and no sign-up: it can be reached from across the internet with no authentication. The people who come after it are attackers who scan automatically for weak support desks, competitors and data brokers who want customer lists and inquiry histories, fraud groups who impersonate customers to extract money, and third parties whose real target is the companies that use the desk. A ticketing system holds the names, emails, and phone numbers of everyone who wrote in, attached documents, agents' handling notes, and sometimes even initial passwords and contract details. The moment this flaw is exploited in an affected environment, the attacker is treated as a legitimate agent and the entire stash of tickets is carried off.

The damage downstream chains together. The personal data lined up in the inquiry history gets sold off in bulk as lists. Next, using that data, phishing that impersonates the support desk with real-looking wording, such as "regarding your recent inquiry," goes out, and the customers who receive it reply without a second thought. The login details pried loose this way are then used as a foothold for hijacking other services or for breaking into the internal systems of the companies the desk supports.

And the responsibility comes back to the company and the support team running OTRS. If the entrusted inquiry contents leak, they must notify the individuals and report to the data protection authority, and they bear the cost of victim response and compensation. Above all, a support desk is "the place you contact when you are in trouble," and the fact that information leaked from it tears down the very trust customers had placed in the company. Whether you escape this cost comes down to whether you check the trigger condition and act now.

CVE-2026-48188: From Unauthenticated SQL Injection to Authentication Bypass

The problem lies in OTRS's database layer module (the shared component that handles communication with the database): an improper input validation (CWE-20). It handles externally supplied strings too loosely, so a crafted string sent here causes an unintended database command to be executed as-is.

SQL injection is a classic attack technique that secretly slips a forbidden database command (an SQL statement) in through an input field or screen operation (classified as CWE-89). Normally, to block such attacks, a backslash (\) is placed before special symbols in the input as a marker meaning "this is a character, not a command," neutralizing it. But when the database is in NO_BACKSLASH_ESCAPES mode, it treats that backslash as "just a character" and does not recognize it as a neutralizing marker. As a result, a crafted string that was supposedly neutralized passes through as a command, and the attack succeeds. That is why the trigger condition is limited to this SQL mode.

From there, this issue leads to authentication bypass (CWE-287, slipping past the login check that should be required). By using the unauthenticated SQL injection to deceive the login decision logic into treating the attacker as a legitimate user, an intruder can get inside the system without knowing any ID or password.

As for whether attacks are actually being observed, as of this writing (June 1, 2026) the flaw is not listed in the CISA KEV, the "catalog of vulnerabilities known to be actively exploited" published by the U.S. Department of Homeland Security agency CISA. This is because it has only just been disclosed, and the listing status should be watched going forward. For the official write-up of details such as the reporter, refer to the vendor's Advisory 2026-02.

Impact Matrix (Edition x SQL Mode)

Whether your OTRS is affected is determined by the combination of edition/version and whether MySQL/MariaDB is in NO_BACKSLASH_ESCAPES mode. Find your position in the table below.

The case to watch is the end-of-maintenance Community Edition 6.0.x. Unlike commercial OTRS, an official fix may never be released for it. If this applies to you, the realistic path is to buy time with the workaround below while planning a migration to a maintained successor such as Znuny. For the exact availability of any remediation, refer to the official advisory.

What to Do Right Now

The response differs by which edition you run. After confirming the trigger condition (SQL mode) and version first, work through the following in order.

1. For commercial / supported builds, update to 2026.4.X or later. Updating is the fundamental fix. Check the OTRS release notes and Advisory 2026-02 and move to the fixed version. Once updated, you are safe regardless of the SQL mode.

2. If you cannot update immediately, remove NO_BACKSLASH_ESCAPES from the SQL mode. This is an immediate workaround. Run SELECT @@sql_mode; on MySQL/MariaDB, and if that mode is present, remove it from the configuration (such as sql_mode in my.cnf). The MariaDB SQL mode reference is helpful here. Note, however, that removing this mode changes how strings are handled and may affect the behavior of other applications. On a shared database, confirm the impact before changing it.

3. Community Edition users should buy time with the workaround and consider migrating. Because maintenance has ended, it is quite likely you cannot wait for an official fix. Reduce the immediate risk with the SQL mode change in step 2, then plan around migrating to a maintained line such as the successor Znuny.

4. Narrow your exposure and monitor logs. Do not leave the OTRS login screen reachable by the general public; placing it behind a VPN or IP restrictions cuts down the path for unauthenticated external probing. Also inspect login and database-adjacent access logs for bursts of suspicious requests. Blocking SQL-injection-like strings with a WAF (Web Application Firewall) is effective as well.

To an attacker, a ticketing system is "a box where the personal data of customers and employees is kept all in one place." If you want to quickly grasp the flaws lurking in the open-source tools you self-host the same way, see our OSS Supply Chain Scanner as well. Organizations running OTRS or Znuny in-house should take this as a chance to review their database settings and their exposure once.

References

• ▸NVD - CVE-2026-48188 Detail
• ▸OTRS Security Advisory 2026-02 (primary source)
• ▸CWE-20: Improper Input Validation
• ▸CWE-89: SQL Injection
• ▸CWE-287: Improper Authentication
• ▸MariaDB - SQL Mode (NO_BACKSLASH_ESCAPES)
• ▸Znuny (OTRS Community Edition fork)
• ▸CISA Known Exploited Vulnerabilities Catalog