Swagger-UI XSS Leading to Account Takeover on Crypto Exchange

3 min readMay 22, 2024


>Hello World!

Hello, scr1pty on touch! I’m a security guy who decided to change his life once and move my career from security management to ethical hacking. I conduct penetration tests full-time but in my free time I search for bugs. It’s my 1st blogpost and I hope you will find it interesting to you. This post is about how I found a Reflected XSS in Swagger-UI which leads to Account Takeover.

>Recon Stage

As each hacker has their recon approach, I have mine as well [btw comment if you wanna a separate post about recon]. It’s a simple bash script that automates assetfinder, subfinder to search subdomains, and the httpx tool to probe for alive assets. My next step is always to use nuclei-templates, especially nuclei-templates/http/technologies. In parallel, I open all subdomain URLs with Wappalyzer to manually pick up low-hanging bugs (if there are any).

After one hour of nuclei scanning (as I usually work with large scopes), I found the Swagger-UI path on my target:


I started to research any vulnerabilities for Swagger and immediately tried any authenticated API requests with curl but without authentication. I hoped there might be a misconfiguration that would allow access to user data or other sensitive files without authentication. Unfortunately, that didn’t work, but after some hours of research, I came across the following articles:

>The Exploit Idea

The idea is to create two publicly available files (find templates in the above references):

  • scripty.json: This is a .json file as Swagger-UI configuration files accepted in .json extensions. This .json file refers to our second .yaml file.
  • scripty.yaml: This .yaml file contains an XSS payload written in JavaScript. My payload for PoC purposes triggers a pop-up alert with document.cookie.

Here is the tip: If you don’t wanna host your server with exploit files — just upload them to your GitHub repository and use raw links.

>Exploiting the Target

Now we are ready to exploit our target if it is vulnerable. We need to input our link to the .json file in the “configUrl” or “url” parameter by the target’s path:


And see what happens:


When a victim accesses the above URL, the XSS payload is executed, which triggers a pop-up window that can capture and send the victim’s cookies to the attacker.


As demonstrated, the payload currently triggers a pop-up for proof. Modifying this payload could allow an attacker to capture session tokens or cookies, enabling unauthorized access to the victim’s account, including admin privileges if the session belongs to an administrative user.