vulnerability

Znuny ships a patch for a 9.5 auth bypass and a SQL injection that share one root cause

Two newly published Znuny vulnerabilities, both fixed in 7.3.7 and LTS 6.5.25, trace back to the same class of bug: unvalidated HTTP header input reaching privileged code paths.

Rendered with AI. A self-hosted server with a padlock on its front panel and a red alarm glow entering the machine, standing in for the unvalidated HTTP header input that reaches privileged code paths in Znuny's auth and search modules.

Znuny, an open-source ticketing system and fork of OTRS Community Edition, has two newly published vulnerabilities, both fixed in a released patch. The first is a critical authentication bypass. The second is a SQL injection in ticket search. What makes the pair worth a look is that they trace back to the same class of bug: unvalidated HTTP header input reaching privileged code paths.

What the two CVEs do

CVE-2026-93483, scored 9.5 CRITICAL, sits in the HTTPBasicAuth modules for the agent and customer interfaces. An attacker can bypass specific standard login procedures by manipulating a single HTTP request header, then reach sensitive system functions without authenticating. The affected modules are Kernel::System::Auth::HTTPBasicAuth and Kernel::System::CustomerAuth::HTTPBasicAuth.

CVE-2026-93484, scored 8.6 HIGH, is a SQL injection in the ticket search. The vulnerable paths are Kernel::System::Ticket::TicketSearch and Kernel::System::Ticket::ArticleSearchIndex::DB. User-supplied input from the Content-Type header is concatenated directly into the database query without parameterization, so a crafted header can alter the query.

Both were reported to the vendor by Mokrane ABDELMALEK through the Ghent University VDP programme. The affected versions are 6.1, 6.2, 6.3, 6.4, 7.0, 7.1, 7.2, and 7.3.0 through 7.3.6. The fix landed in Znuny 7.3.7 and LTS 6.5.25.

Why the shared root cause matters

The two CVEs look different on the surface. One is an auth bypass, the other is a SQL injection. But both are reached through HTTP header input that the application did not validate before handing it to privileged code. The auth bypass works because a header value reaches the login path unchecked. The SQL injection works because a header value reaches a query builder unchecked.

That shared shape is the part that should drive your remediation, not just the version number. If you run Znuny on a self-hosted deployment, the fix is a single point release, so the branch choice matters. An LTS deployment needs the 6.5.25 patch. A current-branch deployment needs 7.3.7. Mixing the two, or patching one branch and leaving the other, leaves the vulnerable code path live.

The practical move is to check which branch you are on, apply the matching release, and audit how header input is handled in any custom or forked code. The vendor advisories confirm the fix is in both branches, so there is no waiting on an unreleased patch.

Status and uncertainty

As of 2026-10-16 there is no KEV listing and no confirmed in-the-wild exploitation. This is a newly published, already fixed advisory, not an active exploitation story. The NVD records are status Deferred, meaning the CVSS figures are the vendor-provided values with NIST analysis still pending. Treat the 9.5 and 8.6 scores as vendor-scored, not yet NIST-confirmed. There is also no independent third-party reproduction yet. The core claims rest on the two vendor advisories and the two NVD records, which is two independent publishers.

AI/LLM transparency note

This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.