Pydio Cross-site Scripting

A stored XSS vulnerability exists in the web application of Pydio through 8.2.2 that can be exploited by levering the file upload and file preview features of the application. An authenticated attacker can upload an HTML file containing JavaScript code and afterwards a file preview URL can be used to access the uploaded file. If a malicious user shares an uploaded HTML file containing JavaScript code with another user of the application, and tricks an authenticated victim into accessing a URL that results in the HTML code being interpreted by the web browser, then the included JavaScript code is executed under the context of the victim user session. (2019-05-31, CVE-2019-10047)

It is possible for an attacker with regular user access to the web application of Pydio through 8.2.2 to trick an administrator user into opening a link shared through the application, that in turn opens a shared file that contains JavaScript code (that is executed in the context of the victim user to obtain sensitive information such as session identifiers and perform actions on behalf of him/her). (2019-05-31, CVE-2019-10049)

Pydio version 8.2.0 and earlier contains a Cross Site Scripting (XSS) vulnerability in ./core/vendor/meenie/javascript-packer/example-inline.php line 48; ./core/vendor/dapphp/securimage/examples/test.mysql.static.php lines: 114,118 that can result in an unauthenticated remote attacker manipulating the web client via XSS code injection. This attack appear to be exploitable via the victim openning a specially crafted URL. This vulnerability appears to have been fixed in version 8.2.1. (2018-07-23, CVE-2018-1999016)

Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.

The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:

https://server.com/confirmation?message=Transaction+Complete

what results in:

<span>Confirmation: Transaction Complete</span>

In that case the message can be modified to become a valid Javascript code, e.g.:

https://server.com/confirmation?message=<script>dangerous javascript code here</script>

and it will be executed locally by the user's browser with full access to the user's personal application/browser data:

<span>Confirmation: <script>dangerous javascript code here</script></span>