CVE-2026-10880 - Osnexus Quantastor 9.8 Unauthenticated SQL Injection
Osnexus Quantastor 9.8 Unauthenticated SQL Injection
Osnexus Quantastor is vulnerable to unauthenticated SQL injection in the login form up to version 6.6.1. The behavior of the injection varies depending on the stage of the software’s initial setup.
What is Osnexus Quantastor?
In this case, QuantaStor SDS was deployed on physical hardware on prem, usually as a storage appliance inside the company’s own network or data center. The admin would access it from that internal network through the QuantaStor web management interface after installation. That is where the default password matters, because it controls access to the storage management console and should be changed before the appliance is used for real storage workloads.
Before the administrator changes the default password, an attacker has two paths. They can either log in with the publicly known default credentials, or they can inject SQL into the username field on the login page and bypass authentication with a payload like:
admin’ or 1=1+—+- # Password field doesn’t matter.
Since the default credentials are already known, this stage has lower practical impact because the attacker already has an easy way in.
After the administrator changes the default password, the same username field is still the injection point, and the issue is still reachable before login. The difference is that the simple default credential path is gone, so the SQL injection becomes much more useful. Instead of only using it as a login bypass, an attacker can use the different login error messages as a blind SQL injection signal to infer database values one character at a time.
The back end is using SQL, and the payload uses SQL behavior with the load_extension function to test characters from a database value. For example, the attacker can test whether the first character of the stored admin password hash is 4. If the guess is right, the application returns one error message. If the guess is wrong, it returns a different error message.
This final payload is also injected into the username field on the login page. That means this is still a pre-authentication attack. The attacker does not need to already be logged in as an admin, and they do not need access to any internal admin-only page. The database values are not being viewed through the UI. They are being inferred indirectly based on how the login request responds to different SQL conditions.
The final payload is shown below:
‘ OR (CASE WHEN (SUBSTR((SELECT Password FROM User LIMIT 1),1,1)=’4’) THEN 1 ELSE load_extension(1) END)=1--
Before showing the two responses, it helps to explain exactly what the payload is checking. The payload is still being sent through the username field on the login page, before authentication. It is not reading a full row through the admin UI. It is asking the database for one specific value, the ‘Password’ column from the first row in the ‘User’ table. There is no delimiter being parsed here, because the query is not returning a whole row as one long string. It directly selects the Password column with SELECT Password FROM User LIMIT 1.
A simplified version of the user table would look like this:
Name: admin
Password: 4f2a...
Role: adminThe important part of the payload is this:
SUBSTR((SELECT Password FROM User LIMIT 1),1,1)=’4’That is basically asking: is the first character of the stored password hash ‘4’?
When the guess is correct, the condition is true. In my test, guessing ‘4’ produced the invalid characters response:
Login Error
Login attempt to specified IP address failed, please verify IP address and try again.
(Error: Authentication request from IP 10.0.0.191 failed:
[Specified name ‘a’ OR (case when (substr((select password from user limit 1),1,1)=’4’) then 1 else load_extension(1) end)-- contains one or more invalid characters. The ‘name’ may only contain alpha-numeric characters and these characters contained within single quotes.])
(err=21) (err=26)When the guess is wrong, the condition is false. In that case, the query reaches load_extension(1) and returns a different database error. Here the only thing changed is the guessed character, from ‘4’ to ‘3’:
Login Error
Login attempt to specified IP address failed, please verify IP address and try again.
(Error: Read from table User with query
SELECT * FROM User WHERE name = ‘a’ OR (CASE WHEN (SUBSTR((SELECT Password FROM User LIMIT 1),1,1)=’3’) THEN 1 ELSE load_extension(1) END)=1--
failed [not authorized] [err=5])Those two different responses are the blind SQL injection signal. A correct guess returns one error, and an incorrect guess returns another. Since the only thing changing between requests is the character being tested, an attacker can repeat this process and recover the stored password hash one character at a time.
Timeline:
Discovered vulnerability: October 21st, 2025
Initial report to Osnexus: October 31st, 2025
Exited 90-day disclosure period: January 29th, 2026
Public disclosure date: June 4th, 2026