CVE-2026-108101 in HortusFox
Summary
by MITRE • 10/09/2026
HortusFox (hortusfox-web) through 6.3 contains an unrestricted file upload vulnerability in PlantAttachmentModel that allows authenticated users to store files with client-supplied extensions under public/attachments/. Attackers can upload HTML or SVG files via /plants/attachments/add for stored cross-site scripting, or PHP files where .htaccess is unenforced to execute code.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in HortusFox web application version 6.3 and earlier represents a critical security flaw rooted in insufficient validation of file uploads within the PlantAttachmentModel component. This unrestricted file upload vulnerability allows authenticated users to bypass expected restrictions on file types, enabling them to store arbitrary files with client-supplied extensions directly into the public/attachments directory. The core technical failure lies in the application's inability to properly sanitize or validate the file extension and content type provided by the user during the upload process via the /plants/attachments/add endpoint. This lack of rigorous input validation creates a pathway for attackers to inject malicious payloads that can be executed within the context of the web server environment, leading to severe compromise of system integrity and confidentiality.
From an operational perspective, this vulnerability facilitates two distinct attack vectors depending on the file type uploaded by the attacker. If HTML or SVG files are uploaded, they serve as vehicles for stored cross-site scripting attacks. Because these files reside in a publicly accessible directory, any user visiting the affected page triggers the execution of malicious JavaScript code within their browser session. This can lead to account hijacking, theft of sensitive data such as session cookies or authentication tokens, and defacement of the application interface. The persistent nature of stored XSS means that every subsequent visitor to the compromised area is potentially exposed without needing further interaction from the initial attacker.
Alternatively, if PHP files are uploaded, the impact escalates significantly toward remote code execution. This risk materializes specifically in environments where .htaccess directives are not properly enforced or configured to prevent script execution within upload directories. By uploading a malicious PHP file with an executable extension, an authenticated user can effectively gain shell access to the underlying server infrastructure. This allows for complete compromise of the web application and potentially lateral movement into other parts of the internal network. The attacker could exfiltrate database contents, modify system configurations, or install backdoors for persistent access, turning a simple file upload flaw into a full-scale system breach.
This vulnerability aligns with CWE-434, which describes unrestricted uploading of files with dangerous content, and is closely related to CWE-20 regarding improper input validation. In the context of the MITRE ATT&CK framework, this exploit maps to T1505.003, specifically Web Shell components, as it enables the deployment of malicious scripts on a web server for persistent access. It also relates to T1059, Command and Scripting Interpreter, particularly when PHP code is executed via the uploaded file. The presence of this flaw indicates a fundamental gap in the application's security architecture regarding how user-supplied data is handled during file operations.
To mitigate these risks, immediate remediation steps are required at both the application and infrastructure levels. Application developers must implement strict allow-listing for permitted file extensions rather than relying on block lists or client-side validation alone. Server-side verification of file content using magic numbers or MIME type analysis should be enforced to ensure that uploaded files match their claimed types regardless of extension. Additionally, all uploaded files should be stored outside the web root directory with restricted permissions, preventing direct execution by the web server. If storage within public directories is unavoidable, configuration controls such as .htaccess rules must explicitly deny execution for script file extensions like PHP, ASP, or JSP in those specific folders. Regular security audits and penetration testing focused on input validation and upload mechanisms are essential to prevent recurrence of this class of vulnerability across the organization's software portfolio.