CVE-2024-0352

What it actually does

CVE-2024-0352 is a critical unauthenticated unrestricted file upload vulnerability in Likeshop versions up to 2.5.7.20210311. The vulnerable HTTP POST request handler in file server/application/api/controller/File.php, specifically FileServer::userFormImage, fails to properly validate the uploaded file supplied through the file argument. A remote attacker can upload arbitrary content instead of a legitimate image, potentially including executable server-side scripts such as PHP web shells. If the uploaded file is stored under a web-accessible path and executed by the web server, the attacker can gain remote code execution with the privileges of the web application process, leading to full compromise of application data, configuration secrets, and potentially the underlying host.

Why it matters to the business

Successful exploitation can allow an unauthenticated remote attacker to take control of the affected Likeshop application, steal customer or order data, modify storefront content, install persistent backdoors, pivot into connected systems, or disrupt service availability. The vulnerability has a critical CVSS score of 9.8, a high EPSS likelihood of exploitation, and publicly disclosed weaponized exploit code, which makes internet-facing Likeshop deployments especially urgent to assess even though the issue is not currently listed in CISA KEV. Because no fixed version is provided in the advisory data, organizations running affected Likeshop versions should treat continued exposure as high risk and apply compensating controls or migrate away from vulnerable builds.

How an attack unfolds

An attacker identifies a Likeshop instance reachable over HTTP or HTTPS and targets the vulnerable upload handler associated with file server/application/api/controller/File.php. They send a crafted unauthenticated POST request to the upload endpoint used by FileServer::userFormImage, placing a malicious payload in the file parameter while disguising it as an image or otherwise bypassing weak validation. If the application accepts the upload and saves it to a web-accessible directory without enforcing safe extensions, MIME validation, content inspection, and execution restrictions, the attacker then requests the uploaded file directly through the web server. When the server interprets the file as executable code, the attacker obtains a web shell or similar command-execution primitive. From there, they can enumerate configuration files, extract database credentials, access customer and transaction data, modify application files, upload additional tooling, create persistence, or use the compromised server as a foothold for further intrusion.

How to fix it

Upgrade to a vendor-provided fixed release if one becomes available. The supplied advisory data does not identify a fixed Likeshop version, so organizations should first determine whether the installed version is at or below 2.5.7.20210311 and contact the vendor or project maintainer for patched code. Until a confirmed fix is deployed, restrict access to the vulnerable upload endpoint, place the application behind a WAF or reverse proxy rule that blocks suspicious uploads, and disable the affected upload functionality if it is not business-critical. Enforce strict server-side upload controls: allow only expected image extensions, validate file signatures rather than trusting Content-Type headers, generate random server-side filenames, store uploads outside the web root, prevent execution in upload directories, and reject files containing server-side code markers. Configure the web server so upload directories cannot execute PHP or other dynamic scripts. Rotate application secrets and database credentials if exploitation is suspected, and rebuild the application host from a trusted source if a web shell or unauthorized file execution is confirmed.

How to confirm the fix worked

Confirm the deployed Likeshop version and verify it is not an affected build at or below 2.5.7.20210311, or that vendor-supplied patched code has removed the unrestricted upload behavior in FileServer::userFormImage. Review the application route or controller handling file uploads and verify that the file parameter is constrained to legitimate image content using server-side validation. Attempt a controlled upload test in a non-production or authorized testing environment: non-image files, double extensions, PHP payloads, and mismatched MIME types should be rejected or stored in a non-executable location. Validate web server configuration by confirming that files in upload directories cannot execute as PHP or another server-side language. Check WAF or reverse proxy logs to ensure upload-blocking rules are active and not only in monitor mode. After remediation, scan web-accessible upload paths for executable files and compare application directories against a clean baseline to ensure no malicious files remain.

Typical attack path

1. Scan the internet or known assets for Likeshop installations and fingerprint vulnerable versions up to 2.5.7.20210311.
2. Send a crafted unauthenticated HTTP POST request to the vulnerable file upload handler associated with FileServer::userFormImage.
3. Place a malicious payload in the file upload field, commonly a PHP web shell disguised as or submitted through an image-upload workflow.
4. Confirm that the application accepts and stores the uploaded file in a predictable or discoverable web-accessible location.
5. Request the uploaded file over HTTP to trigger server-side execution.
6. Use the resulting web shell or command execution to inspect application configuration, database credentials, and filesystem permissions.
7. Establish persistence by uploading additional backdoors, modifying application files, or creating scheduled tasks where possible.
8. Exfiltrate sensitive data, alter storefront behavior, pivot to adjacent services, or disrupt the application.

How to detect it

Investigate web server access logs, reverse proxy logs, WAF logs, application upload logs, filesystem metadata, endpoint telemetry, and process execution logs. Look for unauthenticated or unusual HTTP POST requests to Likeshop file upload routes, especially requests referencing File.php, userFormImage, or a file form field with multipart/form-data content. Pay particular attention to uploads with executable extensions such as .php, .phtml, .php5, .phar, .asp, .aspx, or .jsp; double extensions such as .jpg.php; mismatched MIME types; and uploads followed shortly by HTTP GET requests to the same uploaded filename. On the host, search upload directories and web roots for newly created executable files, files containing PHP web shell functions, obfuscated code, or command-execution parameters. Review web server child processes for unexpected shell execution, including php-fpm, apache, nginx, or web application worker processes spawning sh, bash, cmd, powershell, curl, wget, nc, python, or perl. Examine application configuration files and database access logs for unusual reads after the suspected upload time. If threat hunting across historical logs, prioritize activity since public disclosure in January 2024 and any period where the application was internet-facing without compensating controls.

• server/application/api/controller/File.php
• FileServer::userFormImage
• userFormImage
• multipart/form-data
• name="file"
• filename="*.php"
• filename="*.phtml"
• filename="*.php5"
• filename="*.phar"
• filename="*.jsp"
• filename="*.asp"
• filename="*.aspx"
• filename="*.jpg.php"
• filename="*.png.php"
• filename="*.gif.php"
• <?php
• eval($_POST
• eval($_REQUEST
• assert($_POST
• assert($_REQUEST
• system($_GET
• system($_POST
• shell_exec(
• passthru(
• base64_decode(
• cmd=
• ?cmd=
• /uploads/*.php
• /upload/*.php
• /public/uploads/*.php
• /runtime/*.php
• /storage/*.php
• php-fpm spawned /bin/sh
• apache spawned /bin/sh
• nginx spawned /bin/sh
• www-data /bin/sh
• www-data bash
• curl http://
• wget http://

What your security team should do

• Immediately inventory all Likeshop deployments and identify versions up to 2.5.7.20210311, prioritizing internet-facing systems.
• Because exploit code is public and EPSS is high, treat exposed vulnerable instances as likely attack targets and investigate for compromise, not just exposure.
• If no vendor patch is available, disable or restrict the vulnerable upload functionality and block unauthenticated access to the affected upload endpoint using a WAF, reverse proxy, or network control.
• Harden upload handling by preventing script execution in upload directories and storing user-uploaded files outside the web root wherever possible.
• Search application directories and upload paths for recently created PHP, ASP, JSP, or other executable files, especially files with image-like names or double extensions.
• Review HTTP access logs for suspicious POST requests to file upload endpoints followed by GET requests to newly uploaded executable files.
• Rotate database credentials, API keys, and application secrets if unauthorized upload or code execution is suspected.
• Rebuild compromised hosts from trusted images if a web shell, unexpected executable upload, or attacker persistence is found.
• Add SIEM detections for suspicious multipart uploads, executable file extensions in upload requests, and known web shell command parameters.
• Monitor vendor and project advisories for a fixed Likeshop release and apply it as soon as available.