Clickstudios Passwordstate Cross-Site Scripting (XSS)

I recently performed a penetration test against an instance of Clickstudios Passwordstate, a web based Enterprise Password Management solution.

During testing, three instances of cross-site scripting were identified. This blog post is intended to serve as public disclosure of the issues for CVE-2018-14776, which have since been patched by Clickstudios.

Testing was performed against Passwordstate v8.2 (Build 8256)

1. Uploaded Files

An authenticated user can upload files within Passwordstate which contain JavaScript. If the file is uploaded with a ‘.html’ extension, when viewed through the web application the server returns it with a Content-Type of ‘text/html’, resulting in the browser executing the script.

The following ‘test.html’ file was uploaded with the payload below, demonstrating persistent XSS:


This results in the following JavaScript alert being created once the name of the document has been clicked within Passwordstate.

Clickstudios Passwordstate XSS

It was possible for a lower privileged user account to upload a file containing an XSS payload to a shared password list and then have another account with higher privileges that also has access to the same shared password list view the file, triggering the JavaScript to run in their browser. This demonstrates the potential for a lower privileged user account to execute code within the browser of an administrative user.

2. External Links

An authenticated user has the ability of adding a link to an external URL through the user interface. It was possible to submit an external URL containing the following payload:


Upon clicking the link, the JavaScript is triggered, as shown below:

Clickstudios Passwordstate XSS

This link containing the persistent XSS payload only appears to be viewable to the user that creates it. Based on this it would only be useful in certain scenarios, for example if an attacker compromised an account and added a malicious payload link in the hopes that a legitimate user would later click it.

3. Error Messages

A number of different pages that accept JSON would return an error when invalid JSON was submitted, in this case our reflected XSS payload. For example, upon submitting a POST request to /passwords/shared/folder.aspx the following was sent in the DocumentsDock_ClientState parameter:


This request could only be submitted as an authenticated user and resulted in the following response from the application:

HTTP/1.1 200 OK
Cache-Control: no-cache,max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache,no-cache
Content-Type: text/plain; charset=utf-8
Expires: -1,Thu, 01 Jan 1970 00:00:00 GMT
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
X-UA-Compatible: IE=edge
Date: Tue, 15 May 2018 05:24:21 GMT
Connection: close
Content-Length: 97

83|error|500|Invalid JSON primitive: <script src=""></script>.|

The Content-Type returned is ‘text/plain’, so modern browsers such as Mozilla Firefox and Google Chrome will not see this as JavaScript. Internet Explorer however will not care and execute the script, as demonstrated below:

Clickstudios Passwordstate XSS

This confirms that the external proof of concept script is being executed when using Internet Explorer.


These issues were discovered by myself (Jarrod Farncomb) and the team at TSS. I have been advised that these issues were fixed in version 8.3 Build 8397, released 21 June 2018.

  1. Hi Jarrod,

    What tools did you use for penetration testing? Some off-the-shelf software like Acunetix, or something more sophisticated (e.g. Burp Suite)?


  2. Nice spelling of your name Jarrod. Very rarely do I see my name spelled that way. :)
    And a Linux geek like me also.


Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>