CVE-2026-108100 in HortusFox Web
Summary
by MITRE • 10/09/2026
HortusFox (hortusfox-web) before 6.2 contains an SQL injection vulnerability that allows API token holders to inject SQL by supplying crafted include_info values to the /api/locations/list endpoint. Attackers can place subqueries in include_info, which PlantsModel::getSpecificInfo() concatenates into the column list, to read any database table including user password hashes.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in HortusFox versions prior to 6.2 represents a critical SQL injection flaw within its REST API implementation, specifically targeting the /api/locations/list endpoint. This security defect allows authenticated attackers who possess valid API tokens to manipulate database queries by injecting malicious SQL code through the include_info parameter. The root cause lies in the improper handling of user-supplied input during query construction. When an attacker provides a crafted value for include_info, such as a subquery designed to extract data from other tables, the application logic fails to sanitize or validate this input before incorporating it into the database command structure. This lack of validation enables the execution of arbitrary SQL commands within the context of the application's database user privileges, leading to unauthorized access and potential compromise of sensitive information stored in the backend system.
From a technical perspective, the vulnerability stems from how the PlantsModel::getSpecificInfo() function processes the include_info parameter. Instead of treating this input as a simple string value or validating it against a whitelist of allowed columns, the application concatenates the user-supplied data directly into the column list portion of an SQL SELECT statement. This architectural decision creates a classic injection vector where subqueries can be embedded within the field selection clause. By exploiting this mechanism, an attacker can bypass standard access controls and retrieve data from any table accessible to the database account running the application. The impact is severe as it allows for full read-access to the underlying database schema, including critical assets such as user password hashes, personal identifiable information, and other proprietary business logic stored in adjacent tables that were not intended to be exposed through this specific API endpoint.
The operational impact of this vulnerability extends beyond simple data exfiltration. Since the attacker can execute subqueries, they may potentially escalate privileges or pivot further into the network if the database server is configured with excessive permissions relative to other services. The exposure of user password hashes poses a significant risk for credential stuffing attacks and offline cracking attempts, which could lead to account takeover across multiple platforms where users have reused passwords. Furthermore, the ability to read arbitrary tables undermines the integrity and confidentiality guarantees provided by the application's authentication model. Even though API token holders are authenticated, this vulnerability effectively grants them administrative-level access to data they should not be able to view, violating the principle of least privilege and compromising the overall security posture of the HortusFox deployment.
This flaw aligns with Common Weakness Enumeration (CWE) category CWE-89, which describes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. Additionally, from a tactical perspective related to the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with Data from Information Repositories under the Collection tactic and potentially Credential Access if password hashes are successfully cracked. To mitigate this risk, immediate remediation is required by upgrading HortusFox to version 6.2 or later where the issue has been addressed. In cases where an upgrade is not immediately feasible, implementing strict input validation on the include_info parameter using a whitelist approach ensures that only predefined column names are accepted. Furthermore, employing parameterized queries or prepared statements for all database interactions would prevent the concatenation of user input into SQL syntax structures, thereby neutralizing injection attempts at the code level regardless of the specific endpoint being targeted.