OTRS CVE-2026-48188: Critical Unauthenticated SQL Injection Enables Authentication Bypass Across a Decade of Releases

Introduction

An unauthenticated SQL injection in the database layer module of the OTRS ticketing platform lets attackers bypass authentication entirely. That could give them full access to service desk systems, which routinely store PII, internal credentials, and operational workflow data. CVE-2026-48188 has a CVSS score of 9.1 and affects seven major release lines covering nearly a decade of deployments, so any organization running OTRS or one of its community forks should deal with it now.

OTRS (Open Ticket Request System) is a widely deployed service management platform used for IT helpdesk operations, customer support, security incident management, and asset tracking. It started in 2000 as an open-source project by developers in Germany. OTRS AG is now a publicly traded company (Frankfurt Stock Exchange: TR9.F) with a market cap of approximately $41.2M, and it has an active mid-market customer base with 82 reviews on Gartner Peer Insights. The open-source codebase also produced the ((OTRS)) Community Edition and its primary fork, Znuny, so the blast radius extends well beyond OTRS AG's own commercial releases.

Technical Information

Root Cause: Escaping Mismatch with NO_BACKSLASH_ESCAPES

CVE-2026-48188 is classified under CWE-20 (Improper Input Validation). The vulnerability lives in the OTRS database layer module, the component that builds and runs SQL queries against the backend MySQL or MariaDB database.

The root cause is a disagreement between how OTRS sanitizes input and how the database server interprets string literals when the NO_BACKSLASH_ESCAPES SQL mode is active.

By default, MySQL and MariaDB treat the backslash character (\) as an escape character within string literals. The OTRS sanitization routines appear to assume this default, and in certain code paths they rely on backslash-based escaping to neutralize potentially dangerous input. When NO_BACKSLASH_ESCAPES is enabled on the database server, MySQL "disables the use of the backslash character () as an escape character" in string literals, as documented in the MySQL 9.7 Reference Manual. Backslashes become ordinary characters, and the application's escaping strategy silently fails.

This pattern is well documented in other software. The Kysely query builder vulnerability (GHSA-fr9j-6mvq-frcv) is the same class of issue. Its sanitizeStringLiteral method "escapes single quotes (' to '') but does not escape backslashes." When NO_BACKSLASH_ESCAPES is enabled, an attacker can inject backslash characters that break out of string contexts, which allows SQL injection even when single-quote escaping is in place. CVE-2026-48188 follows the same pattern.

Attack Flow

Exploitation proceeds in four steps:

1. Unauthenticated access to the vulnerable input point. The attacker does not need any credentials to reach the code path where the injection occurs. Any network path to the OTRS web application is sufficient.

2. Crafted input submission. The attacker supplies input containing SQL metacharacters and relies on how the backslash character behaves in string contexts. The application escapes single quotes (by doubling them) but also relies on backslash escaping, which does nothing under NO_BACKSLASH_ESCAPES. That gap lets the attacker construct input that breaks out of the intended string literal boundary.

3. SQL injection in the database layer. The crafted input passes through the OTRS database layer module without proper neutralization. The resulting SQL query contains attacker-controlled fragments that execute against the database.

4. Authentication bypass. The injected SQL manipulates authentication-related queries. The attacker bypasses the login mechanism and gains unauthorized access to the OTRS system, potentially with administrative privileges.

The NO_BACKSLASH_ESCAPES Condition

The NO_BACKSLASH_ESCAPES SQL mode is not the default configuration for MySQL or MariaDB. It must be explicitly enabled at the server or session level. A Stack Overflow discussion notes that this mode is sometimes requested for specific application compatibility reasons. Even so, organizations should not assume they are safe because they believe they use default settings. Customized database configurations, Docker images with non-default SQL modes, or managed database services could enable NO_BACKSLASH_ESCAPES without the OTRS administrator knowing.

You can check whether this mode is active by running:

SELECT @@sql_mode;

If NO_BACKSLASH_ESCAPES appears in the result, the OTRS instance is in the vulnerable configuration.

Affected Systems and Versions

The vulnerability affects OTRS versions across seven major release lines:

The NVD advisory describes products based on the ((OTRS)) Community Edition codebase as "very likely" affected. That includes the Znuny fork and potentially other derivatives. Znuny's advisory ZSA-2026-02 currently addresses a different vulnerability (Reflected XSS, CVE-2025-59490), so a separate Znuny advisory for the SQL injection issue may be pending.

Vulnerable configuration requirement: The backend MySQL or MariaDB server must have the NO_BACKSLASH_ESCAPES SQL mode enabled. Installations using the default SQL mode (without NO_BACKSLASH_ESCAPES) are not affected by this specific attack vector.

For exact patched version numbers on the older release lines (7.0.X through 2025.X), consult OTRS Security Advisory 2026-02 directly.

Vendor Security History

OTRS has built up a long vulnerability history over its 26-year lifespan. The OpenCVE database lists 155 CVEs attributed to the OTRS vendor.

CVE-2026-48188 closely resembles a vulnerability disclosed over two decades ago. CVE-2005-3893 was a SQL injection in the OTRS login function via the user parameter, and it allowed authentication bypass in versions 1.0.0 through 1.3.2 and 2.0.0 through 2.0.3. The two compare as follows:

Recent OTRS vulnerabilities also include CVE-2026-6060 (DoS via uncontrolled resource consumption, CVSS 4.5, affecting 7.0.X through 2026.X before 2026.3.X) and CVE-2025-24391 (user account enumeration, CVSS 5.3, affecting 7.0.X through 2025.X).

Unauthenticated SQL injection leading to authentication bypass has now recurred across more than 20 years. That suggests a persistent weakness in how the OTRS codebase sanitizes input on authentication paths. The conditional trigger (NO_BACKSLASH_ESCAPES) narrows the immediate attack surface compared with the 2005 vulnerability, but the range of affected versions in 2026 is much larger.

Threat Landscape Context

As of June 1, 2026, there is no evidence of active exploitation of CVE-2026-48188. The CVE does not appear in the CISA Known Exploited Vulnerabilities Catalog, and no public exploit code or proof of concept has surfaced.

Other exploitation activity in 2026 still matters for assessing the risk:

• LiteLLM CVE-2026-42208: A pre-authentication SQL injection was exploited within 36 hours of disclosure, with Sysdig reporting that attackers extracted API keys and credentials.
• Drupal CVE-2026-9082: A core SQL injection vulnerability saw approximately 15,000 exploit attempts across 65 countries, forcing urgent patches by late May 2026.
• Proofpoint's 2026 exploitation research indicates that real-world exploitation is outpacing CISA's ability to catalog it, and describes a visibility gap that "defenders cannot ignore."

The NO_BACKSLASH_ESCAPES requirement may initially limit the pool of exploitable targets, but automated scanning tools can identify affected configurations quickly. Given how fast SQL injection vulnerabilities were weaponized in 2026, assume the window between disclosure and potential exploitation is days rather than weeks.

The NVD has also not yet completed CVSS scoring enrichment for this record, so automated vulnerability scanners may not flag this CVE right away. Until scanner signatures catch up, track it manually and rely on compensating controls.

Recommended Actions

1. Upgrade to patched OTRS versions. For the 2026.X release line, version 2026.4.X contains the fix. Consult OTRS Security Advisory 2026-02 for the patch versions that apply to older release lines.

2. Disable NO_BACKSLASH_ESCAPES immediately. If you cannot patch right away, removing NO_BACKSLASH_ESCAPES from the MySQL/MariaDB SQL mode configuration eliminates the exploitation condition. Check with SELECT @@sql_mode; and, if the mode is present, update the server configuration file (typically my.cnf or my.ini).

3. Restrict network access. Because the vulnerability is unauthenticated, any network path to the OTRS application is an attack surface. Place OTRS behind a VPN, reverse-proxy authentication, or strict network ACLs.

4. Deploy WAF rules. Web Application Firewall rules that target SQL injection patterns on authentication endpoints give you a compensating control while patches are applied.

5. Inventory Community Edition forks. Organizations running Znuny or other products derived from the ((OTRS)) Community Edition should monitor Znuny's security advisories and any fork-specific channels for corresponding patches.

6. Monitor database logs. Watch for anomalous SQL patterns in authentication-related queries, particularly those involving backslash characters.

References

• NVD: CVE-2026-48188
• OTRS Security Advisory 2026-02
• OTRS Security Advisories Page
• CWE-20: Improper Input Validation
• MySQL 9.7 Reference Manual: Server SQL Modes
• Kysely GHSA-fr9j-6mvq-frcv: MySQL SQL Injection via Backslash Escape Bypass
• OTRS 2.0 Login Function SQL Injection (CVE-2005-3893)
• OTRS CVEs on OpenCVE
• Znuny Security Advisories
• CISA Known Exploited Vulnerabilities Catalog
• LiteLLM CVE-2026-42208 Exploitation Report (The Hacker News)
• Sysdig: CVE-2026-42208 SQL Injection Analysis
• Proofpoint: 2026 Vulnerability Exploitation in the Wild
• Drupal Core SQL Injection Exploitation (The Hacker News)
• Stack Overflow: Repercussions of Enabling NO_BACKSLASH_ESCAPES