CVE-2026-110609 in Skyeye
Summary
by MITRE • 10/14/2026
Dromara Skyeye through commit 65d3ddcede70 contains an sql injection vulnerability that allows authenticated low-privileged users to inject SQL via the keyword parameter in the queryErpOrderItem MyBatis statement using raw ${} substitution. Attackers can send crafted keyword values to the queryWarehousingDetails or queryOutgoingDetails endpoints to extract database data, including other tenants' data, using boolean, UNION, error or time-based techniques.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Dromara Skyeye prior to commit 65d3ddcede70 represents a critical SQL injection flaw rooted in improper handling of user-supplied input within database query operations. This specific weakness allows authenticated users with low-privilege access levels to execute arbitrary Structured Query Language commands against the underlying database backend. The root cause lies in the implementation of the MyBatis persistence framework, specifically within the queryErpOrderItem statement where raw string substitution using the ${} syntax is employed instead of parameterized queries represented by #{}. This distinction is crucial because while #{()} performs safe binding with prepared statements that escape special characters, ${} directly concatenates the input value into the SQL command string before execution. Consequently, any unsanitized data passed through this mechanism becomes part of the executable code structure rather than a simple data parameter, creating an injection vector for malicious actors.
The operational impact of this vulnerability is severe due to its potential for unauthorized data access across multi-tenant environments. Attackers can target specific endpoints such as queryWarehousingDetails and queryOutgoingDetails by crafting HTTP requests that include specially constructed keyword parameters. By leveraging boolean-based blind techniques, UNION-based extraction methods, error-based probing, or time-based inference attacks, an adversary can systematically extract sensitive information from the database schema. This includes not only data belonging to the attacker's own tenant but also potentially accessing proprietary business logic, customer records, and financial details associated with other tenants sharing the same infrastructure. The ability to bypass authentication requirements for high-privilege operations further exacerbates the risk, as it effectively grants low-level users administrative capabilities over sensitive corporate assets.
From a classification perspective, this vulnerability aligns directly with CWE-89 Improper Neutralization of Special Elements used in an SQL Command commonly known as SQL Injection. The specific mechanism involving dynamic string construction via MyBatis ${} substitution highlights the dangers of mixing code and data within query builders. Furthermore, the exploitation technique maps to MITRE ATT&CK techniques such as T1059 Command and Scripting Interpreter if subsequent commands are executed, or more accurately T1113 Screen Capture for information gathering depending on the final goal, but primarily falls under initial access vectors that lead to data exfiltration. The use of boolean-based blind SQL injection corresponds to specific sub-techniques within database reconnaissance phases where attackers infer truth values based on application responses without direct output visibility.
Mitigation strategies must focus immediately on refactoring the affected MyBatis mapper statements to replace all instances of ${} with #{} for user-controlled parameters. This ensures that input is treated strictly as data and properly escaped by the JDBC driver, neutralizing injection attempts at the database interface level. Additionally, implementing strict input validation using allowlists for expected character sets in keyword fields can provide defense-in-depth against unexpected payloads. Deploying a Web Application Firewall with rules tuned to detect SQL injection patterns may offer temporary protection during remediation but should not be relied upon as the primary fix since sophisticated attackers often bypass such filters. Regular security audits and static application security testing focused on ORM framework usage are recommended to prevent similar issues in future development cycles, ensuring that dynamic query construction is minimized or strictly controlled with validated inputs only.