AVideo < 8.9 Privilege Escalation and File Inclusion that led to RCE

In this article we will cover security issues in AVideo open-source project that led to RCE. We contacted the project manager and the security issues were fixed.



What is AVideo (Audio Video Platform) anyway?

AVideo is a term that means absolutely nothing, or anything video. Since it doesn't mean anything the brand simply is identifiable with audio video. AVideo Platform is an Audio and Video Platform or simply "A Video Platform".

The project is written in PHP and has more 1k starts on Github and more than 4k live websites. We did a pentest as a project for a client that use AVideo in a live production.




The project is intriguing with many functions and files, so we started to work on the platform in order to create a threat model.


Technical Details

After we take a look at the project internals we take few notes that included:


Privilege Escalation

So in source code reviewing phase we found a lot of interesting endpoints. After taking a deep look into source code

there was an interesting file (objects/import.json.php):


As you can see the check is being done with the following code:

If the user can upload video and doNotShowImportMP4Button is disabled we can pass to the next lines.

The vulnerable line is the following at line 51:


The unlink function is designed to delete files and AVideo provides a way to reset the web application by deleting the config file in the path /videos/configuration.php.

The $source variable is the file path that has been aggregated at line 42:

fileURI is an array that has been assigned at line 16:

So to delete the config file we have to send a POST request to the import.json.php file. Also, we must include a value to $_POST['delete'] in order to access the code block of the vulnerable line.


There are 2 scenarios to exploit this issue in order to escalate the user's privilege:



As a result, we created a user with upload permission and disabled the doNotShowImportMP4Button. We sent the following request using Burp Suite:


After sending the request the file was deleted and we got redirected to install page!



We filed a bug but there is more!


File Inclusion

In case you were able to reproduce the previous vulnerability there are 2 points that you should take care of:

Under those circumstances we have to find the current database credential. And that's what we did!

We scanned the plugin folder in order to find interesting functions and we found something in /plugin/LiveLinks/proxy.php

The line below is vulnerable to File Inclusion

And even more there are no authentication check so anyone can exploit this issue by sending a GET request to the file

However, we must bypass the check in the following code

We only need a valid URL with any URI scheme (file://, ftp://, php://, ...etc) in this case I can read the configuration.php file using the file URI scheme (file:///C:/xampp/htdocs/AVideo/videos/configuration.php)




We have the database credential now :)


Remote Code Execution

After this we can achieve RCE using pulgin upload in case of the permissions is limited for the plugin folder we found another way to execute the PHP code using the install folder. In /install/checkConfiguration.php there is way to inject PHP code in configuration.php file.

We just need to pass $_POST['salt'] as: 123'; exec($_GET["x"]);//


So we are now able to execute system commands in the server!



Now it is the time to combine all of these findings in order to gain shell on the vulnerable system. First, you must turn off doNotShowImportMP4Button in order to the exploit works.

You can find the exploit in GitHub here or copy it from here:




Tested on Ubuntu latest version, result:



New Project Idea

We will publish the static analyzer that we created during the pentest here


What now?

If you think your site/app/network are secure and want to make sure about that then

give us a call contact@cube01.io