Manticore Search Has an Authorization Bypass — Read-Only Users Can Become Admin

• The Mess: Manticore Search checks authorization only on the first statement of a multi-statement SQL request. An attacker with READ access to one table can append unauthorized queries and dump the internal credential store.
• The Damage: The leaked password hash can be replayed through the MySQL authentication protocol, allowing an attacker to authenticate as admin without recovering the plaintext password.
• The Fix: Upgrade to Manticore Search 28.4.4 or later and investigate existing credentials if authentication was enabled on an affected deployment.

This is not just a read bypass

CVE-2026-92796 affects Manticore Search versions 27.0.0 through before 28.4.4.

The vulnerability appeared with Manticore’s authentication and authorization subsystem introduced in 27.0.0. The problem is in authorization handling for multi-statement SQL requests.

Manticore parses multiple SQL statements from a single request. The authorization layer then checks only the first statement.

Everything after it can execute without its own permission check.

That turns a narrow table-level permission into something much bigger.

An account that should only be able to read:

public_data

can construct a request containing:

SELECT ... FROM public_data; SELECT ... FROM secret_data;

The first query passes authorization.

The second one rides behind it.

The server executes both.

The attacker now has data they were never supposed to see.

The parser was doing exactly what the attacker needed

The vulnerable path sits in the MySQL/SphinxQL execution layer.

Manticore’s SQL grammar explicitly supports multi-statement requests. Statements can be separated with semicolons and parsed into a collection of SQL statements.

The authorization function receives that collection but examines only element zero.

The upstream analysis identifies the vulnerable logic in SqlCheckPerms(), where the first parsed statement is selected for permission validation. The remaining statements are later processed by the multi-statement execution path without another authorization check.

That means the vulnerability is structural.

It is not a strange SQL syntax corner case.

It is a mismatch between:

what the parser accepts

and

what the authorization layer believes it is checking.

The credential database was sitting behind the same bypass

This is where the vulnerability gets ugly.

Manticore stores authentication data in internal tables including:

system.auth_users

and

system.auth_permissions.

Those tables are normally protected by explicit authorization checks.

But those checks are attached to the same first-statement authorization path.

Move the sensitive query into the second statement and the protection disappears.

The public technical analysis demonstrated that a restricted account could use a permitted first query followed by a query against system.auth_users, causing credential information to be returned.

The leaked data includes password-related material such as password_sha1_no_salt, as well as other credential hashes.

At that point the attacker does not need to guess the administrator’s password.

Pass-the-hash works here

The most important technical detail is password_sha1_no_salt.

Manticore’s MySQL authentication implementation uses the value in its challenge-response calculation.

The researcher demonstrated that possession of the stored SHA-1 password value is sufficient to calculate a valid response to the server’s authentication challenge.

The plaintext password never needs to be recovered.

That creates a chain like this:

limited READ account

→ multi-statement authorization bypass

→ credential-store disclosure

→ administrator password hash

→ MySQL authentication as admin

→ persistent administrator account

The final step was demonstrated in the public PoC.

The attacker used the compromised administrative session to create another user and grant it ADMIN permissions.

This is why calling CVE-2026-92796 merely a “read authorization bypass” undersells what it can do in a real authenticated deployment.

The attacker still needs an account

There is an important limitation.

This is not an unauthenticated remote takeover.

The CVE record rates the vulnerability at CVSS 8.8 under CVSS 3.1 and 8.7 under CVSS 4.0, with PR:L.

The attacker therefore needs an authenticated account with some permissions before exploiting the authorization flaw.

But the required permission is deliberately narrow.

The public research demonstrated an account with READ access to only one table.

That is exactly the sort of credential commonly used by applications that integrate with a search backend.

An API service does not necessarily need administrator privileges. It may only need to search one index.

If that credential can reach the vulnerable SQL interface, the authorization boundary becomes meaningless.

Multiple interfaces are affected

The vulnerable SQL execution path is not confined to one particular client.

The technical analysis identifies the same underlying execution path through the MySQL/SphinxQL protocol and HTTP-accessible interfaces including:

• /sql
• /sql?mode=raw
• /cli
• /cli_json

The researcher also reproduced the issue through a direct MySQL protocol request, showing that this is not merely an HTTP parser quirk.

That matters for defenders because blocking one web endpoint does not necessarily remove the vulnerable authorization logic.

The access path needs to be controlled at the service level.

It can expose more than passwords

The credential store is the obvious prize, but it is not the only one.

Once the authorization boundary can be bypassed, a restricted account can read other tables it was never granted access to.

That can expose:

• customer data
• indexed documents
• internal metadata
• application data
• search datasets
• authentication records
• bearer-token hashes

The exact impact depends on what the Manticore instance contains.

The vulnerability therefore breaks the isolation model between tables, not just the protection around the authentication database.

The fix is already available

Manticore fixed the vulnerability in 28.4.4.

The release notes explicitly identify the security fix as an authentication/authorization permission-check bypass in MySQL multi-statement execution. The fix makes sure permissions are validated correctly instead of relying on the first statement in a multi-statement request.

Affected installations should move to 28.4.4 or later.

Do not stop at upgrading the binary if the instance was exposed while vulnerable.

If authentication was enabled and a restricted account could access the vulnerable interface, assume that credentials and indexed data may require investigation.

Rotate credentials after suspected exploitation

Patching closes the authorization bug.

It does not undo credentials that may already have been extracted.

If there is evidence of exploitation, rotate:

• Manticore user passwords
• bearer tokens
• service credentials
• application credentials connected to Manticore
• administrative accounts

Review newly created users and permission grants.

Also inspect Manticore access logs and surrounding reverse-proxy logs for unusual multi-statement requests, especially requests containing access to tables that should have been outside the caller’s permission scope.

No CISA KEV listing

CVE-2026-92796 was published on September 16, 2026.

The current vulnerability record does not list it in CISA KEV, and the available records reviewed for this article do not establish confirmed widespread active exploitation.

There is, however, a public technical write-up and working proof-of-concept demonstrating the complete path from a restricted account to administrator access.

That makes the patching decision considerably simpler for exposed production systems.

Bugstoday’s take

This is the kind of authorization bug that looks boring until someone follows the entire attack chain.

A READ permission on one table should mean exactly that.

Instead, a malicious client can turn one permitted statement into a tunnel through the authorization layer, dump the credential database and authenticate as an administrator without knowing the administrator’s password.

The most interesting part is the architecture failure: the parser understood that the request contained several statements, while the authorization layer behaved as if there was only one.

That gap was enough.

Upgrade Manticore Search to 28.4.4 or later. If the vulnerable authentication subsystem was exposed, check the logs and rotate credentials rather than assuming the upgrade erased the compromise.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Manticore Search official GitHub repository and release 28.4.4.
• Manticore Search issue #4706 documenting the authorization flaw and upstream fix.
• George Chen technical analysis and proof of concept.
• CVE-2026-92796 record.