This is a valid report, and we have published changes to our code to fix the relevant issue in question as of our latest "Rolling Release" version.

Notes on the scope of the possible attack:

• Users cannot create their own accounts in the system; an account must be created by an existing administrator and the credentials given to a user. This vulnerability is only exploitable by users once they have an account in the system.
• This vulnerability DOES affect any page that uses the system's full ("main") theme; i.e. any administrative pages. However, it only displays your username in the header navigation if it's your username, meaning a vast majority of the time, the only data you're able to exfiltrate is your own.
• This vulnerability DOES NOT apply to the "Administer Users" page where users with global administrative permissions can manage user accounts; usernames and e-mail addresses are properly escaped on this page, so simply visiting this page would not facilitate exfiltration of data, nor would visiting any other page while logged in on the super administrator account.
• This vulnerability COULD be used to exfiltrate super administrator data if the super administrator used the "Log In As" feature on the "Administer Users" page to act as that user; it would then show that user's username in the header navigation, at which point data could possibly be exfiltrated from the super admin's session.

I have updated the CVSS scoring to reflect the limitations in exploiting this vulnerability. Limited as it is in scope and applicability, it is indeed still a valid issue, and could especially pose a problem in multi-tenant installations used by resellers, as the likelihood of using the "Log In As" functionality is higher in this case.