DNS Rebinding Attack
Also Known As
DNS rebinding attack
same-origin bypass via DNS
TL;DR
An attacker tricks a browser into associating their malicious domain with an internal IP, bypassing same-origin policy to reach internal services.
Explanation
DNS rebinding works in two phases. First, the victim visits attacker.com — the DNS record has a short TTL. After the page loads, the attacker changes the DNS record to point to an internal IP (192.168.x.x or 127.0.0.1). The browser now considers requests to attacker.com as same-origin for that internal address, allowing JavaScript to query internal services — admin panels, routers, cloud metadata endpoints (169.254.169.254). Defences include: validate the Host header server-side against an allowlist, bind internal services only to loopback, use private DNS resolvers that refuse to resolve public domains to private IPs, and implement network segmentation.
Common Misconception
✗ DNS rebinding only affects poorly configured internal networks. It bypasses the browser same-origin policy to reach localhost services, IoT devices, and cloud metadata endpoints regardless of network configuration.
Why It Matters
DNS rebinding bypasses the same-origin policy by making a hostname resolve to an internal IP after validation — the browser believes it is still talking to the original host.
Common Mistakes
- Not re-validating the resolved IP at connection time after an initial DNS-based allowlist check.
- Trusting the Host header for routing to internal services without IP-level validation.
- Not using DNS TTL pinning or short-lived DNS caching protections.
- Internal services that accept requests from any source, assuming the network perimeter is sufficient protection.
Code Examples
✗ Vulnerable
// Validate hostname but not resolved IP — vulnerable to rebinding:
$url = $_GET['webhook'];
$host = parse_url($url, PHP_URL_HOST);
if (!in_array($host, $allowed_hosts)) die('Blocked');
curl_exec(/* $url — DNS may now resolve to 192.168.1.1 */);
✓ Fixed
# DNS rebinding bypasses Same-Origin Policy for internal services
# attacker.com resolves to attacker's server, then rebinds to 127.0.0.1
# Prevention:
# 1. Validate Host header — reject unexpected values
\$allowed = ['yourapp.com', 'www.yourapp.com'];
if (!in_array(\$_SERVER['HTTP_HOST'] ?? '', \$allowed, true)) {
http_response_code(400); exit;
}
# 2. Bind internal services to 127.0.0.1 only, not 0.0.0.0
# php -S 127.0.0.1:8000 (dev server)
# 3. Require auth tokens even on internal-only endpoints
# 4. Modern browsers block rebinding to private IPs for public domains
# — partial protection, don't rely on it
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
28
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
Amazonbot 1
Perplexity 1
Amazonbot 8
Perplexity 7
Unknown AI 2
Google 2
Ahrefs 2
SEMrush 2
Majestic 1
Also referenced
How they use it
crawler 23
crawler_json 1
Related categories
⚡
DEV INTEL
Tools & Severity
🟠 High
⚙ Fix effort: Medium
⚡ Quick Fix
Validate the resolved IP address of user-supplied URLs, not just the hostname — reject requests to private IP ranges (10.x, 172.16.x, 192.168.x, 127.x) even after DNS resolution
📦 Applies To
PHP 5.0+
web
api
🔗 Prerequisites
🔍 Detection Hints
Hostname checked against allowlist but resolved IP not validated against private ranges before making HTTP request
Auto-detectable:
✗ No
semgrep
⚠ Related Problems
🤖 AI Agent
Confidence: Medium
False Positives: Medium
✗ Manual fix
Fix: High
Context: File
Tests: Update
CWE-350
CWE-918