Introduction and Overview

Back in late 2021 I was engaged on a penetration test of a client’s implementation of the Imprivata Privilege Access Management (PAM), previously known as XTAM (Xton Access Manager ). The goal of the test was to assess the product for security vulnerabilities that may impact the client’s intended use for managing secrets and secure connections to internal systems by external providers.

During the engagement, I discovered a stored cross-site scripting vulnerability that was present in at least two areas of the application. Successful exploitation of the vulnerability enabled me to escalate privileges from a low-privileged user to System Administrator. The vulnerability was immediately reported to the client, who escalated it to Imprivata for patching. The first patch was released to the client during the engagement, which enabled me to retest it. While it addressed one area of the application, the vulnerability was still exploitable in another, with some effort to bypass restrictions that had been put in place.

After I had discovered that this patch failed to fully address the issue, I contacted Imprivata directly to work with them on a complete fix and discuss a timeline for public disclosure. Initial conversations were positive, and they seemed ok with my 90-day disclosure timeline. However, a week prior to the deadline, I was invited to a meeting with their VP of Customers, who advised me that their primary customer base were health care providers, and requested I hold off until the end of 2022 for disclosure to give them time to ensure patches were rolled out. I agreed, and off we all went. In April this year (2023), I reached out to advise I would be disclosing in 30 days, and the subsequent post is to that effect.

The following sections provide technical details about the vulnerability, the affected versions and the disclosure timeline in full. I acknowledge that I have missed my own 30-day window by approximately an additional 60 days, and this has been a long time coming. I hope that with this disclosure now any remaining vulnerable customers patch their systems to protect themselves from this serious privilege escalation vulnerability.

What is Imprivata Privileged Access Management?

The following has been taken directly from Imprivata’s datasheet:

Imprivata Privileged Access Management is a comprehensive, easy-to-use PAM solution that protects privileged accounts from unauthorised access.

Vulnerability Details

A stored cross-site scripting (XSS) vulnerability was found in the application that could be leveraged by an authenticated, low privilege user to escalate their privileges to System Administrator within the Imprivata Privileged Access Management (PAM) application. The application failed to sanitise user input, and subsequently failed to encode user-controlled output in two distinct areas: the Audit Log and the Messenger functionality.

Audit Log

The application included an Audit Log, which was available in a web view and accessible by users with System Administrator privileges. The Audit Log web view did not encode output, and simply displayed the contents in HTML. As the application did not appropriately sanitise user input, it was possible to inject HTML and/or JavaScript in fields that later appeared in the Audit Log. One such field was the Last Name field of the User Profile. This field had a low character limit, so the payload was adjusted to fit. However, as there were no restrictions, a simple <script> payload could be used to call an externally hosted JavaScript file containing code to perform actions in the context of the victim viewing the payload. For example:

The string Test was added in between the <script> tags so that the payload would appear normal in the Audit Log. This was fixed in version 2.3.202112121126 by adding sanitisation on user input that prevented <script> tags and event handlers being added to user-controlled fields.

Version: 2.3.202112121126 Patch and Bypass

During the original penetration test where this issue was discovered, Imprivata PAM was upgraded to version 2.3.202112121126, which initially appeared to fix both XSS vulnerabilities. However, a bypass was found for the Audit Log issue due to the fact the output was still not appropriately encoded before being displayed. Imprivata PAM was using an out-of-date version of Angular JS, version 1.5.0. PortSwigger, the developers of BurpSuite, publish a cross-site scripting cheat sheet that offers a long list of possible cross-site scripting payloads. Given the application was using a vulnerable version of Angular JS, it was theorised that the following payload discovered by Ian Hickey and Gareth Hayes from PortSwigger may work:


This payload was too long to fit in the Last Name field of the User Profile, so a different input field was needed. One feature of Imprivata PAM is the Personal Vault, which allows users to organise their records into folders. The Name field of a New Record was perfect for the payload as any actions on this folder created a new line in the Audit Log, and the character limit was large enough to allow the full payload, as seen in the screenshots below.


Figure 1. XSS payload injected into a new folder name in the pentest user's Personal Folder

Figure 2. Alert box triggered by the injected payload appears on the Audit Log


It should be noted that there may be other fields in the application that also allow this injection. While this payload demonstrates that a cross-site scripting vulnerability exists, there is no real impact on its own. Using the idea of calling an externally hosted JavaScript file in order to include additional code, the following payload was developed using fetch to perform a cross-origin request:


The server on nothingsus.club was configured to allow requests from any origin, and admin2.js contained the same privilege escalation code as in the previous examples. The privilege escalation commands are left as an exercise for the reader.

Figure 3. Privilege escalation payload as a folder name in the Personal Folder Record List

The following GIF demonstrates the attack end to end.

Demonstration of the attack

Figure 4. Moving GIF of end-to-end attack chain


Additionally, this bypass appears to create denial-of-server (DoS) conditions in the victim’s browser as it makes thousands of fetch requests when the page is viewed, which can use up all of the browser’s memory and eventually crash it.

Affected Versions

  • First discovered in version 2.3.202110311252 but likely affects older versions as well.
  • Partially patched in version 2.3.202112121126, however the Audit Log was still vulnerable with a modified payload.
  • According to Imprivata, the Audit Log vulnerability has been fixed in newer versions, however this has not been confirmed due to issues installing and testing a newer version.

Discovery and Disclosure Timeline

  • First discovered in early December 2021
  • Initially reported to Imprivata via a support ticket on 7th December 2021, with a public disclosure timeline of March 20th, 2022 established with scope for this to change upon negotiation if required
  • Initial disclosure to Mitre with minimal details to have a CVE (CVE-2021-45094) assigned
  • Full details of the bug reported via email on 20th December 2021
  • Further details provided to the Imprivata Security team on 10th January 2022
  • Met with various members of the Imprivata executive team on March 14th, 2022 to discuss delaying the public disclosure to allow time for customers to patch. This was agreed on by all parties.
  • Follow up with Imprivata contact on 13th April 2023 to advise final 30 days until disclosure.
  • Disclosure delayed as I did not have capacity to complete this blog post.
  • 20th July 2023 published on Aegis9.com.au
Back to List