Cross-site Scripting (XSS) - Stored in aces/loris


Reported on

Aug 15th 2021

✍️ Description

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.

🕵️‍♂️ Proof of Concept

Please follow the steps below:

  • Login in the demo application (
  • Create a new publication (Click on Reports -> Publications -> Propose a new project)
  • Use the payload below to set the publication title
Title"}<img src=x onerror=alert(document.domain)>
  • Browse to the following page:
  • Please note that you might need to change the "id" value from "2" to the number corresponding to your publication.

💥 Impact

If an admin visits the affected point the attacker will be able to perform any action on the admin behalf thus allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

We have contacted a member of the aces/loris team and are waiting to hear back 4 months ago
aces/loris maintainer
3 months ago

I don't see how this can be used as an XSS attack. The result from the database is passed to json_encode, which should ensure that the value is properly escaped for json. The only place that the line of code in question appears to be is from within a React component at, where the data isn't passed to dangerouslySetInnerHTML or anything else that should bypass React's XSS protection (

Can you provide more information about how this XSS can be exploited?

aces/loris maintainer
3 months ago

Sorry, I just saw there's already a proof of concept included.

The URL is an ajax endpoint which is only called from javascript and wouldn't be directly accessed by an admin. In the cases where it's used, it should be safe for the above reasons described above. However, in the event that it is directly accessed by an admin, it looks like the Content-Type header of the response is defaulting to text/html, causing the js to be evaluated.

I don't think the Severity is "Critical", but I've tested that properly setting the Content-Type does fix the problem and I'll send a fix.

Nuno Lopes
3 months ago


Hi, thanks for your message. Exactly, setting the Content-Type to application/json would fix this vulnerability. Let me know if you have any further question.

aces/loris maintainer validated this vulnerability 3 months ago
Nuno Lopes has been awarded the disclosure bounty
The fix bounty is now up for grabs
aces/loris maintainer
3 months ago

This should be fixed by

aces/loris maintainer confirmed that a fix has been merged on b49937 3 months ago
The fix bounty has been dropped