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 2 years ago
aces/loris maintainer
2 years 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
2 years 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
2 years 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 2 years ago
Nuno Lopes has been awarded the disclosure bounty
The fix bounty is now up for grabs
aces/loris maintainer
2 years ago


This should be fixed by

aces/loris maintainer marked this as fixed with commit b49937 2 years ago
The fix bounty has been dropped
This vulnerability will not receive a CVE
to join this conversation