CVE-2026-111669 in Zr.Admin.NET
Summary
by MITRE • 10/16/2026
ZR.Admin.NET through 3.8.2 contains an sql injection vulnerability that allows authenticated attackers to manipulate the ORDER BY clause by supplying a crafted PagerInfo.Sort query parameter to the shared ToPage paging helper. Attackers holding the system:user:list permission can inject subquery or CASE expressions via GET /system/user/list to extract database contents such as stored credentials through blind techniques.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in ZR.Admin.NET versions up to 3.8.2 represents a significant security flaw within its data pagination and sorting mechanisms, specifically targeting the ToPage helper function used for handling query parameters. This component is responsible for translating user-supplied input into SQL commands that determine how database records are ordered before being returned to the client application. The core technical issue stems from insufficient sanitization or validation of the PagerInfo.Sort parameter, which accepts values intended to define sorting criteria such as column names and sort directions like ascending or descending. Because this input is directly concatenated or interpolated into the SQL query structure without adequate protection against injection payloads, it creates a pathway for attackers to alter the logic of the database command executed by the backend system.
This flaw classifies under CWE-89 Improper Neutralization of Special Elements used in an SQL Command and aligns with MITRE ATT&CK technique T1059.007 Command Shell or Scripting, as it allows for arbitrary code execution within the context of the database engine. The vulnerability is particularly dangerous because it affects authenticated users who possess the system:user:list permission. This access level is relatively common in administrative interfaces and content management systems, meaning that a broader range of potential attackers can exploit this flaw compared to vulnerabilities requiring full administrator privileges. By manipulating the ORDER BY clause, an attacker does not merely retrieve data through standard query parameters but can inject complex SQL constructs such as subqueries or CASE expressions into the sorting logic.
The operational impact of this vulnerability is severe, primarily due to its suitability for blind SQL injection attacks. Since the application may not return explicit error messages that reveal database structure directly, attackers must rely on time-based or boolean-based inference techniques to extract information. By carefully crafting payloads within the Sort parameter, an attacker can force the database to perform conditional operations based on extracted data values. For instance, they might cause a delay in response times if a specific character matches expected criteria, thereby allowing them to iteratively reconstruct sensitive data stored in the database. The primary target of such exploitation is often credential stores, including hashed passwords for user accounts, session tokens, or other authentication secrets that are critical to maintaining system integrity and confidentiality.
Exploitation typically involves sending GET requests to endpoints like /system/user/list with a maliciously constructed PagerInfo.Sort value. For example, an attacker might inject a subquery designed to return the first character of a password hash from another table into the ORDER BY clause. If the application's response behavior changes based on whether that condition is true or false, the attacker can systematically extract data byte by byte. This process bypasses standard input validation checks because the injection point is within a sorting directive rather than a direct search filter, which developers often assume to be safer from SQLi risks. The ability to execute these blind techniques means that even without visible feedback in the UI, sensitive information can be exfiltrated over time through automated tools or manual exploitation scripts.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective fix is to implement strict allow-listing for sorting parameters rather than relying on blacklist-based filtering which may miss novel injection patterns. Developers should validate that the PagerInfo.Sort value corresponds exactly to a predefined set of allowed column names in the database schema, rejecting any input containing special characters or SQL keywords outside this whitelist. Additionally, using parameterized queries where possible and avoiding string concatenation for dynamic SQL parts can significantly reduce risk. For existing deployments, applying patches to upgrade ZR.Admin.NET beyond version 3.8.2 is essential if a fixed release has been issued by the vendor. Security teams should also monitor logs for unusual patterns in sorting parameters or delayed responses from user list endpoints as indicators of active exploitation attempts.