DNS Rebinding Attacks: Bypassing Browser Same-Origin Policy via DNS

Cybersecurity

DNS rebinding allows a malicious website to communicate with private network services from the victim's browser. A technical breakdown of the attack, exploitation scenarios, and defences that actually work.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 16, 2025 · 9 min read

DNS rebinding is a technique that allows an attacker's JavaScript, executing in the victim's browser, to communicate with services on the victim's private network — services that are normally protected by the browser's same-origin policy. The attack works by manipulating DNS responses to make the attacker's domain resolve to a private IP address after the initial page load.

Attack Mechanics

Phase one: the victim visits attacker.com. The A record for attacker.com returns the attacker's real IP with a very short TTL (1 second). The attacker's page loads and begins executing JavaScript. Phase two: the JavaScript waits for the TTL to expire and triggers a new DNS lookup. The attacker's DNS server now returns a private IP address (e.g., 192.168.1.1). Phase three: the JavaScript makes a fetch() to attacker.com — which now resolves to the router — and reads the response, bypassing SOP because the origin hostname has not changed.

Exploitation Scenarios

• Router admin panel: read and modify router configuration, DNS settings, or port forwarding rules.
• Internal API servers: reach services listening on localhost:8080 or internal RFC1918 addresses.
• Kubernetes API: access the kube-apiserver on 10.96.0.1:443 if the pod network is reachable.
• IoT devices: many smart home devices have unauthenticated APIs on private IPs.
• Metadata services: AWS IMDSv1 at 169.254.169.254 was historically reachable via DNS rebinding from browsers with permissive CORS.

Tools for Exploitation

Singularity of Origin (github.com/nccgroup/singularity) is the purpose-built DNS rebinding toolkit. It provides a DNS server, HTTP server, and payload manager. Configure it with your attack domain, set the TTL to one second, and choose the target internal IP. The manager interface lets you observe when rebinding completes and issue custom HTTP requests through the victim's browser to the internal service.

DNS rebinding turns any XSS vulnerability in the browser into full access to every unauthenticated service on the victim's internal network. It is why internal services must authenticate even when not internet-facing.

Browser Protections and Their Gaps

Chrome 112 introduced Private Network Access (PNA) which requires servers to opt in to cross-origin private network requests via CORS headers. Safari uses DNS rebinding protection by pinning the resolved IP for the lifetime of the browser session. Firefox has partial mitigations. However, all browsers remain vulnerable when the target service explicitly responds with appropriate CORS headers — which many internal dashboards do to support development workflows.

Defences That Work

• Host header validation: internal services should reject requests where the Host header is not a known internal hostname.
• DNS rebinding protection in resolvers: bind9 with response-policy zones blocks public domains from resolving to RFC1918 addresses.
• Authentication on all internal services: even services that only internal users can reach must require authentication.
• Private Network Access headers: implement CORS Private Network Access opt-in if the service must support cross-origin requests.
• Browser DNS-over-HTTPS: DoH providers like Cloudflare filter rebinding responses.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.