Repository navigation
A Long History of Browser-Based Exploited Localhost & Local Network Vulnerabilities #21
Description
The vulnerability addressed by this local-network-access proposal has been an interest of mine ever since I discovered the 2019 vulnerability in Zoom. That vulnerability allowed an attacker to hijack the webcam of a Zoom user's computer due to a lack of protection around the localhost webserver Zoom secretly installed on an estimated ~4 million macs. That vulnerability, Assetnote discovered, later turned out to be an RCE vulnerability.
Over the past several years, I've been collecting a list of these vulnerabilities adjacent to this in my head (and some here mozilla/standards-positions#143), and this seems like a good place to capture all of them again:
| Vulnerability | Year | Real‑world Impact | What Broke | Link to Post |
|---|---|---|---|---|
| DNS Rebinding Wi-Fi Attack (Miki) | 2015 | Stealing Wi-Fi credentials via DNS rebinding and router admin interface access | DNS rebinding exploited to bypass browser-origin restrictions and access private network devices | Link |
| JetBrains IDEs HTTP API | 2016 | RCE on Windows/macOS via project load from attacker-controlled share; file read from local disk | Local HTTP server with no auth, open CORS, and path traversal | Link |
| TrendMicro Password Manager | 2016 | RCE and password theft via browser local API | Node.js app exposed 70+ unauthenticated API endpoints to browser | Link |
| Princeton IoT Device Attacks | 2018 | Websites could discover, fingerprint, and control IoT devices on local network | Lack of authentication and open local APIs in IoT devices; exploited via JavaScript in browser | Link |
| PortSwigger Intranet Port Scanning | 2018 | Browser-based intranet scanning; internal network mapping & fingerprinting | JavaScript-based iframe load detection to infer open ports reliably across major browsers | Link |
| Zoom Localhost Web Server | 2019 | Forced camera access; silent Zoom reinstall | Undocumented localhost web server accepted unauthenticated requests | Link |
| Zoom Localhost RCE (Assetnote Follow-up) | 2019 | Automatic installation of malicious package via Zoom server → macOS RCE | Logic flaw in domain suffix validation enabling download/install of arbitrary installer via /launch |
Link |
| Dell SupportAssist Localhost RCE | 2019 | RCE from local network; websites could launch executables via Dell's local HTTP server | SupportAssist exposed an HTTP API with weak origin validation, allowing command execution via browser | Link |
| Null Sweep Port Scanning | 2020 | Websites fingerprinted users by scanning localhost ports | WebSocket/timing-based port scan from browser | Link |
| 0.0.0.0-Day Localhost API Exploit | 2024 | RCE and sensitive data exfiltration via browser-accessible localhost APIs in AI/dev tools | Localhost services bound to 0.0.0.0 exposed unauthenticated HTTP APIs accessible by any website | Link |
| LocalMess Android App Tracking | 2025 | Websites linked anonymous browsing to app login status | Abuse of localhost ports to exfiltrate identifiers from mobile apps | Link |
| ASUS DriverHub Exploit | 2025 | RCE via browser using ASUS DriverHub’s unprotected localhost API | ASUS DriverHub exposed a local service over HTTP without authentication or origin verification | Link |
| Anthropic MCP Inspector RCE | 2025 | Critical RCE via browser-accessible localhost API in AI dev tooling | Local service exposed HTTP API on 0.0.0.0 without authentication, enabling remote code execution | Link |
I plan to add more to this list as I'm made aware of more examples.
This is a 19 year old security vulnerability that still hasn't been fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=354493
Given this history, I think there's a clear and obvious case for why this vulnerability need to be addressed by the browsers. This recent case where Meta and Yandex's spyware were both leveraging this mechanism as a deanonymization strategy starkly points to how much a protection against this behaviour is needed.
Personally, I think that it's well past time to lay this vulnerability at the feet of browser vendors, this is your mess, and your responsibility to clean up.
Activity
tresf commentedon Jun 18, 2025
@JLLeitschuh this is a nice collection you've shared, thank you.
You've also shared some glittering generalities which come of as sensational when an outsider is reading this for factual information. For example:
^--- (suggests scope is in the billions, with a "B")
^--- (scope is corrected)
...
^-- (suggests scope is due to an application)
^-- (suggests that the communication channel IS the vulnerability... switch of definition)
...
^-- (suggests that this webserver is not needed by zoom, but rather done as a secret for nefarious purposes)
As an application developer of a very similar "listening on localhost" application, I can say that this change will -- overnight -- break things. My point is not to argue your research validity or your use-case, but rather constructively criticize some of the wording used in the OP.
JLLeitschuh commentedon Jun 18, 2025
Alright... quite fair. I've updated the issue description to better reflect reality. I agree specificity is important. Thank you for the criticism
g-ortuno commentedon Jun 18, 2025
There's also https://mrbruh.com/asusdriverhub/
JLLeitschuh commentedon Jun 18, 2025
Thanks. Added this and one additional one:
JLLeitschuh commentedon Jun 24, 2025
Added the following to the table as well:
| DNS Rebinding Wi-Fi Attack (Miki) | 2015 | Stealing Wi-Fi credentials via DNS rebinding and router admin interface access | DNS rebinding exploited to bypass browser-origin restrictions and access private network devices | Link |
JLLeitschuh commentedon Jul 9, 2025
Added the following to the table:
| Anthropic MCP Inspector RCE | 2025 | Critical RCE via browser-accessible localhost API in AI dev tooling | Local service exposed HTTP API on 0.0.0.0 without authentication, enabling remote code execution | Link |
tresf commentedon Nov 17, 2025
This bug report is not actionable. Why is it still open?
JLLeitschuh commentedon Nov 18, 2025
It's more documentation at this point more than anything else. I have a few additional cases I'd like to add to it too. I'm waiting on some pending disclosures before doing so.
tresf commentedon Nov 19, 2025
I was asking the project administrators. There's also a much longer history of applications that use fetch and websockets openly, honestly and ethically that doesn't get sensational articles written.
gunesacar commentedon Mar 12, 2026
@JLLeitschuh In case you are still updating the table: Another locahost-related exploit using WebSockets and password brute-forcing to take over OpenClaw instances: https://www.bleepingcomputer.com/news/security/clawjacked-attack-let-malicious-websites-hijack-openclaw-to-steal-data/
Security advisory: GHSA-jmmg-jqc7-5qf4
The researchers note that the attack would not have been possible if LNA had covered WebSockets (page 4).
https://web.archive.org/web/20260312103936/https://pages.oasis.security/rs/106-PZV-596/images/openclaw-vulnerability.pdf?version=0 (That is not to say, LNA is the only way to fix it).
tresf commentedon Mar 12, 2026
Confidential document behind a
paywall, so no way to actually fact check this. How?Edit: Saw the archive and read it...The YouTube video shows ws:// which means what exactly? That this was done on an HTTP website?I understand OASIS needs to get their ROI on this, but this bug was patched in 24 hours and OpenClaw has more vulnerabilities than a toddler in a razor factory.tresf commentedon Mar 12, 2026
The attack would have been mitigated, not prevented. There's no rate limiting once someone says "Yes" and the "just click yes" fatigue is real.
I forgot, Chrome allows
ws://connections to localhost from HTTPS. This LNA won't fix that, just show a singular popup.What really irks me about this "long history" propaganda is there's also a long history of apps #16 using this technology in ethical ways. I've not seen one person from the localmess team advocate for an approach to maintain the rich, ethical internet from being steamrolled by these changes, just more bad apple examples.
JLLeitschuh commentedon Mar 13, 2026
@tresf I agree that this behavior has been used for legitimate uses frequently, however the point I'm making with this post is that it's also a massive footgun that developers keep, consistently, shooting themselves in the foot with. The problem is that, in the case of local or network adjacent servers that run privileged code. Also many developers think "this code is run on a private network, behind NAT, that will protect me". Attacks like pivoting through the browser, or DNS rebinding demonstrate that this boundary is significantly weaker than many developers inherently believe it to be.
tresf commentedon Mar 13, 2026
Put your money where your mouth is and talk about the solution please. This "I remind you once again how (we) were right" narrative doesn't help us towards a solution. Security can ALWAYS be solved with turning everything off. The browser exists as it does in the world because of its usefulness. Killing this usefulness without due-diligence is blindly killing the ecosystems around it. We can all, always create a list of reasons towards an argument, but it's much, much harder to develop a middle ground that satisfies both parties.
I've made example after example about how this implementation offers almost nothing for good actors to detect if it's needed #71 detect if it's enabled #69 or to ask nicely if it can be used #38, so sorry not sorry that this "long history" thread is salt in the wound that's a failing effort to do good while playing nicely with others.
Not to mention this "just click yes" prompt fatigue problem that seems like it's still not addressed.
That's to say, I think #108 would be a step in the right direction (for both "turn it off" peeps and "let me fetch/ws please" peeps) but it feels more like a design change that would unravel the work done.
JLLeitschuh commentedon Mar 21, 2026
Found another case from 2006: https://www.researchgate.net/publication/220739132_Drive-By_Pharming
tresf commentedon Mar 22, 2026
Although many router IP addresses can be guessed, this article states several times to obtain the network information through Java Applets, which have been blocked by all major browsers since 2017 (2 years earlier for Chrome). Might as well link some ActiveX articles too, no?
JLLeitschuh commentedon Mar 22, 2026
I'm mostly capturing a history of links at this point. But to address your point, the 2018 research by Gareth Hays demonstrated strategies for obtaining network information using timing attacks:
https://portswigger.net/research/exposing-intranets-with-reliable-browser-based-port-scanning
This POC doesn't seem to work anymore, but I'd be curious what caused it to break and if it's possible to fix so it works again.
I'm giving a talk at BSides SF about this research and abusing DNS Rebinding to exploit MCP servers, hence the follow up.
trcrsired commentedon Mar 30, 2026