Following the journey of the low-hanging fruits in the Joomla plugins, this time we reported two unrestrictive file uploads. One located under the “Subscribers” section, and the other located under the “Templates” section. Both of this vulnerabilities allowed an attacker with access to the administration panel to upload files without any restriction, such as a PHP webshell, to execute commands in the backend.

Furthermore, we also found a way to bypass the file extension validation located in the lib.upload.php file by simply using an extension that was not listed in the plugin’s blacklist.

Proof of concept

Unrestricted file upload [Subscribers]:

The first vulnerability could be found by following the path below:

Administration > Components > Jnews > Subscribers > Import

In the form above, the application expected a CSV file with the name, email and two other fields. Obviously we did not upload a .csv file but instead a .php.

The test.php file was then uploaded to the server at the location: media/com_jnews/uploadtest.php

Note: there’s a small bug here, instead of saving the uploaded file to the upload folder, the component attached the word upload as a prefix for the filename.

The next step was to call the uploaded file with the parameter e= filled with the command: /bin/ls -la ../.. && id

GET request

Server Response

Unrestricted file upload [Templates]:

In this vulnerability, it was possible to upload a zip file containing a malicious PHP script. As this was being done in the templates section (listed below), the plugin automatically extracted the file to a folder accessible publicly, allowing us to execute the file remotely.

The structure of the zip file can be found below:

As similiar to the previous vulnerability, the template file was automatically extracted to /media/com_jnews/templates/<zip-folder>/<shell.php>, allowing us to access the file without the parameter ?e=/bin/ls -la ../.. && id



Bypass file extension filter

Some other functions of Jnews allowed us to upload files to the server, however, the extension of the files were being filtered.

The code responsible for this filtering was located at lib.upload.php, and as it can be seen below, it was a blacklist approach that forbids a determined list of extensions. The default list of blocked extensions was [“php”,”phtm”,”phtml”,”php3,”inc”,”exe”,”dmg”]

Bypassing this type of validations is trivial as we can simply use files not listed in the list above, such as the .htaccess file or a simple .php5.

Report timeline

  • September 01, 2015 - Bug reported to Joobi.
  • September 02, 2015 - Jnews’s team replied asking more info.
  • September 24, 2015 - Jnews’s team releases a new version.
  • October 15, 2015 - Public disclosure.


  • 8.3.1

Fixed in version 8.5.0