tl;dr A well positioned attacker (needs to be using the same IP as the victim) can hijack a successful authentication flow and take over the session victims session by polling the get.cgi endpoint after the victim’s login was successful but before the victim has polled the same page (which happens every second)

The foundation of this attack comes from the authentication system that is in-place on the device. The basic idea is that the user sends their login to set.cgi. This creates a file containing the login information and some information about the attempt (like a browser category and client ip). It then triggers another program to read that file and write the results to another file.

The browser in the mean time polls get.cgi every second to see the state of the authentication waiting on that result for to be written.

The problem is that get.cgi doesn’t have a good way to determine that the user who started the login is the same user who is polling the get.cgi. So a well placed attacker (needs to be on the same IP, and with the same browser category (bucketed into 5 possibilities)) could make the request to get.cgi before the proper user and be successfully authenticated without having provided the credentials.