Description

NivoCart through 2.4.0 contains an arbitrary file upload vulnerability in the File Manager multi() endpoint that fails to validate file extensions for new filenames or when chunks parameter is 2 or higher. Attackers with view-only back-office access can upload PHP files to the web-accessible image/data/ directory and execute them for remote code execution.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-20T12:17:05.777Z",
  "pubdate": "2026-09-20T12:17:05.777Z",
  "executiveSummary": "NivoCart versions through 2.4.0 are susceptible to an arbitrary file upload vulnerability within the File Manager component. This flaw resides in the multi() endpoint, which fails to implement adequate server-side validation of file extensions when processing new filenames or handling chunked uploads where the 'chunks' parameter is set to 2 or greater.\nThe vulnerability allows an authenticated attacker, even one restricted to view-only back-office access, to upload malicious PHP scripts directly to the web-accessible 'image/data/' directory. Successful exploitation facilitates Remote Code Execution (RCE) on the underlying web server, potentially leading to a full system compromise. This bypasses security expectations for administrative interfaces by leveraging insufficient input sanitization. The vulnerability necessitates a valid back-office session, placing the risk on systems where unauthorized or malicious actors gain low-level authenticated access.",
  "technicalDetails": "The vulnerability exists within the NivoCart File Manager's multi() function, which is designed to handle file uploads, including those utilizing multipart chunked transfers. The primary root cause is an insecure implementation of the file validation logic. Specifically, the application fails to perform strict allow-listing or verification of the file extension during the upload process. This deficiency is particularly pronounced when the 'chunks' parameter is set to a value of 2 or higher, as the logic responsible for processing and reconstructing these chunks fails to re-validate the final file against the expected security policy.\nThe attack flow begins with an authenticated user initiating a request to the multi() endpoint. By manipulating the filename parameter or bypassing the validation checks during a chunked upload sequence, an attacker can upload arbitrary content, such as a web shell crafted in PHP. Because the application logic does not inspect or restrict the file extension prior to writing the file to the filesystem, the malicious payload is persisted to the 'image/data/' directory.\nThis directory is typically exposed via the web server root, allowing an attacker to navigate directly to the uploaded file's URL (e.g., /image/data/shell.php). Upon request, the web server executes the code contained within the file, granting the attacker arbitrary command execution under the context of the web server service account. The impact of this post-exploitation phase includes, but is not limited to, unauthorized access to sensitive application data, exfiltration of database credentials, modification of application integrity, and potential lateral movement within the hosting environment. The absence of server-side sanitization effectively neutralizes the expected restrictions associated with the back-office environment, allowing a user with limited privileges to escalate their control to the server level."
}