HortusFox CVE-2026-108100

Exploitation requires the attacker to hold a valid HortusFox API token (PR:L) and requires the REST API to be enabled with the /api/locations/list endpoint reachable; the attacker supplies a crafted include_info parameter whose value is concatenated into the SQL column list by PlantsModel::getSpecificInfo(). The limiting factor is the API-token prerequisite - this is not an unauthenticated flaw, so exposure is confined to deployments that issue API tokens and to actors who have obtained one. Affected versions are all releases before 6.2; upgrading to 6.2 (which adds column-name validation) removes the condition.

This is a moderate-priority, authenticated SQL injection (CWE-89) in HortusFox, grounded in a vendor-confirmed source-code fix. The provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N, score 7.1) is internally consistent with the description: remote and low-complexity, but gated behind PR:L - the attacker must already hold a valid API token. Impact is confidentiality-only (VC:H, with VI/VA:N), matching a read-oriented injection that can dump arbitrary tables including user password hashes; there is no claimed integrity or availability impact. No EPSS score, KEV listing, or public POC was supplied, so by the precision rule the status is 'no public exploit identified at time of analysis' - this is not evidence of widespread exploitation. The key tempering signals are the authentication requirement (API token) and the product's small deployment footprint, which together lower real-world risk well below what a network-vector/low-complexity flaw alone might suggest. No conflicting signals were detected; the main limitation is the absence of EPSS/KEV data to gauge exploitation likelihood.

An attacker who already possesses a valid HortusFox API token sends a request to /api/locations/list with a crafted include_info value containing a SQL subquery. Because PlantsModel::getSpecificInfo() concatenates include_info directly into the SELECT column list, the subquery executes and returns data from arbitrary tables, letting the attacker exfiltrate the users table and crack the recovered password hashes offline. No public exploit code was identified at the time of analysis, though the vendor patch commit publicly reveals the vulnerable code path.