A router admin panel, a Jenkins instance, a Redis cache with no password – these are exactly the kind of internal services that DNS rebinding attacks are built to reach from outside the network. The technique isn’t new (researchers were poking at it in 1996 with early Java applets), but it keeps resurfacing because browsers still trust DNS resolution more than they probably should, and because “internal” doesn’t mean “isolated” the way most teams assume.
This piece walks through how the attack works, why it specifically targets internal infrastructure rather than public-facing apps, and what actually stops it – because a surprising number of the standard defenses (firewalls, HTTPS, even a corporate VPN) don’t.
How DNS rebinding actually works
The mechanics are almost embarrassingly simple once you see them laid out. An attacker registers a domain, say evil-example.com, and points its DNS record at a server they control – with a very short TTL, often 1 second or even 0. A victim visits the site, and their browser loads JavaScript from that domain. Same-origin policy allows this JavaScript to make further requests back to evil-example.com, because it’s the same origin.
Here’s the trick: once the malicious page is loaded and the browser has cached the page’s origin, the attacker’s DNS server changes its answer. The next DNS lookup for evil-example.com no longer returns the attacker’s IP – it returns 192.168.1.1, or 10.0.0.5, or whatever internal address the attacker wants to probe. The browser, still convinced it’s talking to the “same origin,” happily sends the JavaScript’s follow-up requests to that internal address instead.
Same-origin policy checks the hostname, not the IP address behind it. That’s the entire flaw. The browser did nothing wrong by its own rules; the rules just weren’t written with attacker-controlled DNS in mind.
Why internal services end up the real target
Public web apps generally sit behind their own auth, TLS termination, and – hopefully – DNS security controls. Internal services rarely get the same scrutiny, because the assumption is that network segmentation already does the job. A Kubernetes dashboard on port 8080, a Prometheus instance with no auth, an old Jenkins box someone spun up for a hackathon in 2019 and forgot about – these sit on RFC 1918 addresses and are treated as safe by default.
DNS rebinding breaks that assumption entirely. It doesn’t need to breach the network perimeter. It uses the victim’s browser, sitting inside the network, as a proxy. The attacker never touches the internal segment directly – the victim’s own machine makes the request on their behalf, and the response comes right back through the same malicious page’s JavaScript.
Craig Young at Tripwire demonstrated this against Google Home and Chromecast devices in 2018, extracting device location and network details just by getting a victim to view an ad or a page with embedded rebinding code. A year earlier, security researcher Tavis Ormandy used a very similar approach against Blizzard’s game client, which ran a local RPC service listening on 127.0.0.1 with no authentication. Neither attack required credential theft or malware – just a browser tab open long enough for the DNS TTL to expire.
A realistic attack walkthrough
Picture an internal admin tool at 10.20.30.40:9000 with no login screen, because “it’s internal, who’s going to reach it.” An employee gets a phishing email with a link to what looks like a webinar registration page. They click it, the page loads, and a background script starts running.
The script first resolves the attacker’s domain (already pointed at the attacker’s server) and fetches an initial payload. Thirty seconds later, once the DNS TTL has expired and the attacker flips the DNS record to 10.20.30.40, the same script issues a fetch() call to that same domain – except now it lands on the internal admin tool. If the tool has an unauthenticated API for creating users or triggering deploys, the attacker’s script can call it directly, and the response streams back to the attacker’s own logging endpoint via a second exfiltration request.
Total time from click to compromise: often under two minutes. No malware, no exploit kit, nothing that a traditional endpoint scanner flags, because the only thing that happened is a browser making an HTTP request it was technically allowed to make.
Common mistakes teams make
A few patterns show up again and again in postmortems and pentest reports:
Trusting “internal-only” as a security control by itself. Segmentation stops direct external connections, not browser-mediated ones.
Skipping authentication on admin tools because they’re not internet-facing. Jenkins, Grafana, Kibana, and internal APIs deployed without auth are the most common rebinding targets found in bug bounty writeups.
Validating requests only by source IP. DNS rebinding requests originate from the victim’s legitimate internal IP – the source address tells you nothing.
Assuming HTTPS prevents this. TLS protects data in transit; it says nothing about which host resolved to which IP.
What stops DNS rebinding – and what doesn’t
The most reliable defense is Host header validation on every internal service: check that the incoming Host header matches an expected value (like localhost, or an internal DNS name on an allowlist) and reject anything else, including raw IP addresses used as Host headers. This alone closes off most rebinding paths, because the attacker’s rebound request still carries the original domain name in the Host header, which won’t match what the internal service expects.
DNS pinning at the resolver level helps too – caching a domain’s resolved IP for the lifetime of a browser session rather than honoring a 1-second TTL. Chrome and Firefox both apply some pinning, but it’s inconsistent and shouldn’t be relied on as the sole control. Browsers also increasingly enforce Private Network Access checks (Chrome’s PNA, still rolling out as of 2026), which requires an explicit CORS preflight before a public page can reach a private-network address – but coverage varies across browser versions and isn’t universal yet.
Firewalls, VPNs, and network segmentation genuinely help against a lot of threats, but none of them stop a request that originates from inside the trusted network in the first place. That’s the myth worth retiring: DNS rebinding isn’t a perimeter problem, so perimeter tools don’t fix it. Internal services need to authenticate every request and validate the Host header, the same way a public-facing service would – because from the service’s point of view, it effectively is public-facing the moment a browser inside the network can be tricked into reaching it. Regular checks against exposure patterns like this are part of what a broader server-side request forgery review should also cover, since the two techniques often get chained together in real attacks.
FAQ
Is DNS rebinding the same thing as subdomain takeover?
No. Subdomain takeover happens when a DNS record still points to a decommissioned cloud resource an attacker can claim; DNS rebinding involves an attacker actively controlling DNS answers for a domain they own to redirect a victim’s browser toward internal addresses. Both exploit weak DNS hygiene, but the mechanics and fixes differ – see how subdomain takeover works for the distinction.
Can a firewall block DNS rebinding attacks?
Not on its own. The malicious traffic originates from a legitimate device already inside the trusted network, so firewall rules based on source IP or network zone won’t distinguish it from normal internal traffic.
Does using HTTPS on internal services prevent rebinding?
It doesn’t prevent the attack, though it does make it harder – a valid TLS certificate for an internal hostname is difficult for an attacker to obtain, which blocks some rebinding paths against HTTPS-only services. Services still reachable over plain HTTP, or internal tools serving self-signed certs that browsers are configured to trust, remain exposed.
The practical fix isn’t exotic: every internal service, no matter how obscure or short-lived, should validate its Host header and require authentication. “Nobody outside the network can reach it” stopped being true the moment DNS became something an attacker gets to control, one TTL expiration at a time.