Your home network probably has things on it that don't speak to the internet. Your router's admin panel listens on 192.168.1.1. Maybe a Plex server on 192.168.1.42. Maybe a smart speaker, a printer, a NAS, a Raspberry Pi running something experimental. Most of these have web interfaces, and most of those interfaces have weak or nonexistent authentication because they assume only people on the local network can reach them.
DNS rebinding is the attack class that breaks that assumption. It lets a malicious website on the public internet make HTTP requests directly to devices on your private network — from inside your browser, on your machine, with your IP address.
The Same-Origin Policy and What It Protects
The web has a fundamental safety boundary called the Same-Origin Policy. JavaScript running on evil.example cannot make a request to bank.example and read the response. The browser enforces this — it lets the request fire, but blocks the page from reading the result. This is what keeps every site you've ever visited from sweeping data out of every other site you've logged into.
The Same-Origin Policy is defined in terms of the origin: scheme, host, and port. http://evil.example:80 is one origin; http://192.168.1.1:80 is another. Cross-origin reads are blocked.
Now the trick. The browser checks the origin by hostname — not by IP address. And the hostname is just a label that DNS resolves to an IP. What if the DNS server changes its mind?
The Attack, Step by Step
A DNS rebinding attack runs roughly like this:
- You visit
evil.example. The browser resolves the name and gets the attacker's real IP, say203.0.113.5. It loads JavaScript from there. - The JavaScript opens a fetch loop, hammering
http://evil.example/probeover and over. - The attacker's DNS server is configured with a very short TTL — sometimes one second. After serving the first response, the cached entry expires almost immediately.
- After the page is loaded, the attacker changes the DNS response. The next time the browser resolves
evil.example, it gets back192.168.1.1— the local IP of your router. - The JavaScript's fetch is still aimed at
evil.example. The browser sees the same origin, allows the read, and routes the request to the new IP. It now talks to your router. - The router's admin interface, which assumed only local users could reach it, dutifully returns its admin page. The JavaScript reads it.
The attack works because the browser's same-origin check is hostname-based and the hostname's resolution is controlled by an attacker-operated DNS server. The browser is following the spec; the spec didn't anticipate that the DNS authority for a name could be hostile.
If a name's DNS record has a long TTL, the browser caches it for the duration and won't see the rebinding. Short TTLs are explicitly allowed by DNS, and many legitimate services use them. The attack exploits a normal protocol feature, not a bug.
What an Attacker Can Do
The damage depends on what you have running locally. Plenty of devices in 2026 still have:
- Router admin pages with default credentials, or with persistent session cookies the rebinding script can use directly.
- Local web APIs (Plex, Sonos, Roon, Home Assistant, Hue bridges) that trust any request from the local network without authentication.
- Development tools — language servers, Jupyter notebooks, Docker daemons — bound to
0.0.0.0with no auth. - Smart speakers and IoT hubs running embedded HTTP servers, often with known vulnerabilities and no patch cadence.
- Cryptocurrency wallet daemons listening on localhost with JSON-RPC interfaces.
The 2018 Ethereum wallet rebinding research is a useful reference point: researchers showed that a malicious webpage could drain on-disk wallets by talking to the wallet's localhost JSON-RPC port. The wallet trusted localhost. The browser was the bridge.
Why It Persists
DNS rebinding has been documented since 1996 by Princeton researchers. So why does it still work three decades later?
The defenses are partial
Browsers added several mitigations over the years. DNS pinning caches the first resolved IP and refuses to use a later one for the same connection. That helped, but didn't fully solve it — some attacks defeat pinning by waiting for the cache to expire, or by exploiting that different browsers pin differently.
The cleanest mitigation is to refuse private-network destinations entirely from public-network origins. The W3C's Private Network Access spec (formerly CORS-RFC1918) does exactly this: a website on a public origin must obtain explicit consent before making requests to private IP ranges. Chrome has been rolling it out gradually since 2021; Firefox and Safari are behind. As of 2026, coverage is partial and still depending on user-agent.
The local services don't help themselves
A correctly defended local service requires authentication on every request, validates the Host header against an expected value, and refuses requests where the header is anything else. Almost no consumer device does this. The Host: evil.example header is accepted because the device's HTTP stack doesn't check.
What Actually Works
| Defense | Where it lives | Effectiveness |
|---|---|---|
| Validate Host header | Local service | Strong — and the cheapest fix |
| Require authentication | Local service | Strong — but only if creds aren't cached |
| Block resolution of internal IPs | DNS resolver / dnsmasq --stop-dns-rebind |
Strong — recommended for routers |
| Private Network Access | Browser | Partial, rollout still uneven in 2026 |
| DNS pinning | Browser | Partial — defeatable in some cases |
| Only listen on localhost (127.0.0.1) | Local service | Helps against LAN attacks; localhost services are still in scope |
What to Actually Do
For most users, the practical defenses come down to a few habits:
- Enable DNS rebinding protection on your router or local resolver. OpenWrt, pfSense, and AdGuard Home offer it as a checkbox; resolvers using dnsmasq can enable it with one flag.
- Change default admin passwords on every device with a web interface.
- Don't run development tools bound to
0.0.0.0. Bind to127.0.0.1. Use--authon Jupyter and similar tools. - Keep your browser current — Private Network Access protections are improving steadily.
- Audit what's listening on your LAN. The output of
nmap -sV 192.168.1.0/24is often eye-opening.
The Quiet Lesson
DNS rebinding is a reminder that the boundaries we treat as security perimeters — "the local network is trusted," "the browser enforces same-origin" — are often weaker than the marketing suggests. Each is a useful default; none survives an attacker who looks for where the defaults break down.
The defense is to never treat network position alone as authentication. If a device on your LAN exposes a sensitive interface, it should authenticate every request, regardless of who appears to be asking. Browsers are slowly, partially, fixing the rebinding problem in their layer. Until that's complete, the burden remains on local services to defend themselves, and on users to be aware of what's listening.