In Innoshop through 0.4.1, an authenticated attacker could exploit the File Manager functions in the admin panel to achieve code execution on the server, by uploading a crafted file and then renaming it to have a .php extension by using the Rename Function. This bypasses the initial check that uploaded files are image files. The application relies on frontend checks to restrict the administrator from changing the extension of uploaded files to .php. This restriction is easily bypassed with any proxy tool (e.g., BurpSuite). Once the attacker renames the file, and gives it the .php extension, a GET request can be used to trigger the execution of code on the server.
The Innoshop application implements file type verification only on the client side (frontend), making it easy to bypass the restriction of uploaded files to images. The attacker uploads any file (e.g., a PHP webshell) disguised as a graphic file, and then uses the Rename function in the file manager to change its extension to .php — the frontend block is neutralized by intercepting and modifying the HTTP request using a proxy tool (e.g., BurpSuite). After changing the extension, it is sufficient to send a GET request to the URL of the uploaded file for the server to execute the PHP code contained in it.
The attacker gains remote code execution (RCE) on the server, which can lead to complete server takeover, data theft, violation of system confidentiality and integrity, and potentially further lateral movement in the infrastructure.
Apply patches available from the vendor according to the references. Additionally, it is recommended to move file extension and type validation exclusively to the server side (backend), block PHP script execution in directories intended for user-uploaded files, and restrict access to the administrative panel at the network and authentication level.
Innoshop in versions up to and including 0.4.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L