In March of 2025, Toreon organised its annual ski trip. Some other colleagues and I decided not to ski, as we are quite inexperienced, and to go on hikes instead. On one of the last days of the trip, I didn’t feel like hiking and went to the hotel’s lobby to do some bug hunting on my laptop. When connecting to the Wi-Fi, the user is prompted with a web page, where they need to enter the Wi-Fi credentials, given to them after check-in. Since this was the first web page I had to open in order to connect to the internet, I decided to have a look at the page to see if I could find any security vulnerabilities.
Toreon Office | Grotehondstraat 44 1/1 - 2018 Antwerpen | +32 3 369 33 96
How a Toreon ski-trip led to a CVE in MikroTik’s Wi-Fi Hotspot
How a Toreon ski-trip led to a CVE in MikroTik's Wi-Fi Hotspot
The vulnerability
On the login page, a hidden dst input field was present. When the user submits their credentials, a request like this would be sent:
POST /login HTTP/1.1
Host: 192.168.1.2
Content-Type: application/x-www-form-urlencoded
Content-Length: x
username=<username>&password=<password-hash>&dst=https://<target-page>&popup=true
After a successful login, the user is redirected to the value of the dst parameter. Of course, I had to try if the javascript protocol was supported as well, and indeed, it was!
So, if we were to submit the following body in the post request, the injected payload would execute:
POST /login HTTP/1.1
Host: 192.168.1.2
Content-Type: application/x-www-form-urlencoded
Content-Length: x
username=<username>&password=<password-hash>&dst=javascript:alert(1)&popup=true
After discovering this, I went ahead and looked for a way to exploit this against other users. One way to do so was to use the following URL: https://192.168.1.2/login?dst=javascript:alert(1). If the user browses to the URL and logs in, the XSS triggers, as the value of the dst query parameter is stored in the hidden input field. However, the victim still needs to log in. When looking for scenarios where the victim does not have to log in anymore, I noticed that the server accepts the login request as a GET request as well. So by opening the following URL, the victim would automatically be logged in as the attacker, and the payload will trigger immediately:
https://192.168.1.2/login?username=<username>&password=<password-hash>&dst=javascript:alert(1)&popup=true
The login page referred to RouterOS, which is the operating system that MikroTik routers run on. So I knew what software it was, but I didn’t know the version. Therefore, I was unsure if the latest version would even be vulnerable.
Confirming the vulnerability exists in the latest RouterOS
First of all, I wanted to know if the vulnerability was already known. I did some research online and could not find a CVE for the vulnerability, which was a good sign. However, this does not mean that the vulnerability is still present in the latest version of the software. To confirm if the latest version is still vulnerable, I asked Toreon to order a cheap MikroTik router. We went for the MikroTik Hex Refresh. I set up the device at home, configured a hotspot, and verified that the XSS still works in the latest version! The vulnerability was reported to MikroTik, and while they were in the process of resolving it, Toreon became a CVE Numbering Authority (CNA), which was used to register a CVE number for the vulnerability, which you can look up here.
Timeline
About the Author
Robbe Verwilghen, named Ethical Government Hacker of the Year in 2024, led Belgium’s inaugural ‘Hack the Government’ challenge, uncovering dozens of bugs, including several critical vulnerabilities. He has also earned a place on the Centre for Cybersecurity’s Wall of Fame for the past two years.
