Toreon Office | Grotehondstraat 44 1/1 - 2018 Antwerpen | +32 3 369 33 96
A while back, I gave myself a fun weekend challenge: Hack everything in my apartment that’s connected to the internet. So, I started by performing some basic ping-sweeps using nmap. It gave me a good insight into my personal local network. For example, I found out that my washing machine was connected to the internet. Why? Who knows?!
nmap Then I looked up, literally, and saw my Elgato Key Lights. For those unfamiliar, Elgato Key Lights are LED panels designed for creators. For a little sneak-peak into my life: Here’s my desk setup with the two Elgato Key Lights I have.
I can control these lights from my computer or phone with an app, which is cool and very handy. I have a macro on one of my keyboard keys that turns them on. But… how? Well, I wanted to figure that out.
C:\Program Files\Elgato\ControlCenter\Firmware. 
I started, as I always do with firmware, by just running strings on it. This has already provided me with a lot of information. For example, I found many strings like HTTP/1.1 200 OK, /elgato/wifi-info, and so on, that would suggest these lights run a web server on my local network.
I used Wireshark to validate that that these lights indeed communicate using HTTP. Fwieeuw, back into the known domain of hacking web applications!
With some basic reconnaissance completed, let’s get into the vulnerability.
I discovered a A Cross-Site Request Forgery (CSRF) vulnerability in Elgato’s Key Lights that allows any website make your Elgato lights flicker aggressively. It doesn’t matter if you’re streaming on Twitch or just watching cat videos. If your browser loads a malicious script, your lights could suddenly go into disco mode without your consent.
Before we dive into the details, let’s cover the basics for anyone unfamiliar.
CSRF stands for Cross-Site Request Forgery. It’s a type of attack where a malicious website tricks your browser into making a request to a different site, typically one you’re already logged into or have access to, without your knowledge. It works because your browser will often send cookies or session tokens along with the request, thinking it’s just doing what you told it to do.
This technique is well-known and with the many browser protections available, most online platforms are secured against it. But here’s a really great hacking tip for you:
Hacking tip of the day: Software that exposes a port on your localhost also needs to have CSRF protection! Lacking a safeguard, any website on the internet can start making requests to the internal network using your browser and exploit the application that isn’t even connected to the internet that way!
I’ve found this countless times before! Check out this other vulnerability I found in LollMS: NVD – CVE-2024-1522
Yes, you read that right: A CSRF leading to a Remote Code Execution (RCE) because of an /execute_code endpoint that was only expected to be accessible from localhost!
The Elgato lights fit in a similar category: They’re only meant to be accessed by people on the same local network, but their APIs can be called by remote websites through the browser of a victim.
At this point I had already gathered a lot of information:
I knew the Key Lights had a web server on the local network
I wanted to check to if the lights were vulnerable to a CSRF
I had Wireshark hooked up so I could review all HTTP requests made to the lights
The Elgato lights expose an HTTP API on port 9123 of your local network. A lot of API calls weren’t exploitable. They either required a JSON body, or didn’t perform any meaningful action. That’s until I found /elgato/identify. This endpoint makes the lights flash rapidly for a few seconds, useful if you have multiple lights and need to figure out which one is which.
Useful… unless it’s triggered remotely, by someone else.
Here’s the HTML and JavaScript payload I wrote. An attacker can host this on any regular website. Once a victim visits the site, the script runs and sends requests to all addresses in the most common IP range used in home networks (192.168.0.0/24), trying to hit the Elgato device:
<html>
<body>
<script>
function flash() {
for (var i = 0; i <= 255; i++) {
var ipAddress = "192.168.0." + i;
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://" + ipAddress + ":9123/elgato/identify");
xhr.timeout = 2000;
xhr.send();
}
}
flash();
setTimeout(flash, 1000);
setTimeout(flash, 2000);
setTimeout(flash, 3000);
setTimeout(flash, 4000);
</script>
</body>
</html>
Interestingly, browsers are starting to catch up to this class of issue. Chrome has announced plans to start restricting local network requests from regular web pages as part of their Private Network Access (PNA) initiative. In short, if a website served over the public internet tries to send a request to a device on your local network, like a smart light or a printer, Chrome will eventually block it unless the device explicitly allows it through CORS headers. That’s a big deal, because it means these kinds of CSRF-style attacks won’t be as easy to pull off in the future. It’s not a silver bullet (especially for non-Chrome users or legacy setups), but it’s a much-needed shift in browser behavior that helps protect users by default.
Before wrapping up, I want to thank the Elgato team for being responsive and taking this seriously. After I reached out, they issued an update that now validates the Origin header for incoming requests. If a browser tries to send a command from an unknown or untrusted origin, the lights will respond with a 403 Forbidden. Simple, effective, and exactly the kind of fix you’d hope for.
In a world where more and more of our physical environment is controlled through web technologies, CSRF isn’t just about stealing sessions anymore. It can literally reach into your room and start flipping switches.
To developers building for the local network: treat your APIs with the same respect you’d give public ones. To security folks: don’t underestimate the value of poking at the everyday tech around you. Lastly, to vendors: keep making fixes like this. It makes a difference.
Want more information about the CVE? Here’s the link: NVD – CVE-2025-7202
Until next time!
Robbe Van Roey is a security consultant with 6 years of experience in the cybersecurity field. During this time, he has become an expert in web application and network penetration testing by responsibly disclosing vulnerabilities, engaging in bug bounty, competing in hacking competitions, and performing penetration tests. He has identified vulnerabilities in large organizations such as Google Chrome, Amazon, NVIDIA, Corsair and LastPass.
