← CodeClarityLab Home
Browse by Category
+ added · updated 7d
← Back to glossary

DNS Rebinding Attack

security CWE-350 OWASP A1:2021 CVSS 8.8 PHP 5.0+ Advanced

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

Added 15 Mar 2026
Edited 22 Mar 2026
Views 28
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings W 1 ping T 0 pings F 0 pings S 2 pings S 1 ping M 0 pings T 1 ping W 0 pings T 0 pings F 0 pings S 3 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 0 pings S 2 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 0 pings S 1 ping S 0 pings M 0 pings T 2 pings W 0 pings T
No pings yet today
Amazonbot 1 Perplexity 1
Amazonbot 8 Perplexity 7 Unknown AI 2 Google 2 Ahrefs 2 SEMrush 2 Majestic 1
crawler 23 crawler_json 1
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

✓ schema.org compliant