Dns Rebinding on Cloudflare

DNS rebinding occurs when an attacker controls a domain that resolves to multiple IP addresses over time, typically switching from a public IP to a private RFC 1918 address after the victim’s browser resolves the domain. In Cloudflare-protected environments, this can bypass same-origin policies and IP-based trust mechanisms because Cloudflare proxies traffic and may expose non-public origins during resolution switches.

Attack patterns specific to Cloudflare include leveraging Cloudflare Workers or load‑balanced origins where the edge can forward to internal origins that are not directly internet‑facing. For example, an attacker registers evil.example.com behind Cloudflare, then configures a Worker that dynamically changes the DNS resolution to point to an internal service at 10.0.0.10 after the victim’s browser has established trust. Because Cloudflare may cache DNS responses and maintain persistent connections, the rebinding can occur mid‑session without the victim noticing an IP change.

Specific Cloudflare code paths where this appears include Workers that use fetch() with dynamic hostnames and per‑request DNS reresolution, and load‑balancer pools where origin IPs can be rotated or switched based on health checks. An attacker can craft a request chain where the initial response comes from Cloudflare’s edge (public IP), then a subsequent fetch within a Worker or origin redirects to an internal IP. This can lead to SSRF against internal services, unauthorized admin interfaces, or cloud metadata endpoints.

Common vulnerable patterns in Workers:

• Using fetch with a hostname that resolves differently at edge versus origin.
• Relying on IP allowlists that assume Cloudflare’s edge IPs are safe, while internal origins are exposed via rebinding.

These patterns can bypass Cloudflare’s proxy protections if the rebinding forces the browser to send requests to internal IPs that the origin trusts based on CF-Connecting-IP or similar headers without additional validation.

Detecting DNS rebinding in Cloudflare environments requires analyzing both the edge behavior and origin resolution patterns. Because Cloudflare masks direct origin IPs, standard network-based detection is less effective; instead, focus on behavioral indicators such as mismatched DNS TTLs, unexpected origin IP changes within a short time window, and responses that include private IP references in headers or bodies.

To identify this issue during scanning with middleBrick, submit the Cloudflare‑protected URL using the CLI or Web Dashboard. middleBrick runs 12 security checks in parallel, including Input Validation and Property Authorization, which can surface anomalies in how hostnames resolve and whether responses contain private IPs or internal hostnames. The LLM/AI Security checks in middleBrick also probe for prompt injection and output leakage, which can be relevant if attackers manipulate DNS to exfiltrate data through crafted responses.

Key detection steps with middleBrick:

• Run middlebrick scan <url> against the Cloudflare endpoint to obtain a security risk score and per‑category findings.
• Review the Input Validation and Data Exposure findings for indicators of DNS manipulation, such as mismatched A/AAAA records or responses containing private IP ranges (e.g., 10.x.x.x, 192.168.x.x).
• Check the Inventory Management and Unsafe Consumption checks for exposed internal hostnames or references to internal services that should not be reachable from the edge.

Example CLI usage:

middlebrick scan https://api.example.com

The dashboard provides a per‑category breakdown, allowing you to see if BFLA/Privilege Escalation or Property Authorization findings correlate with DNS resolution anomalies.

Remediation focuses on hardening how Cloudflare resolves and forwards requests, ensuring that internal origins are never exposed through rebinding, and validating inputs that influence DNS or host resolution.

Use Cloudflare’s native features such as Workers KV for static hostname mappings, Access rules to restrict internal IP ranges, and custom headers to enforce strict validation. Avoid dynamic DNS resolution within Workers unless absolutely necessary, and if required, pin expected IP ranges and validate the resolved IP against an allowlist.

Code examples for Cloudflare Workers:

1. Validate and restrict target hostnames to a known allowlist before fetching:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event))
})

const ALLOWED_HOSTS = new Set([
  'api.trusted.com',
  'internal.service.corp'
])

async function handleRequest(event) {
  const url = new URL(event.request.url)
  if (!ALLOWED_HOSTS.has(url.hostname)) {
    return new Response('Forbidden: hostname not allowed', { status: 403 })
  }
  const response = await fetch(event.request)
  return response
}

2. Use Cloudflare Access to restrict access to internal origins and enforce identity-based policies instead of IP trust:

# In Cloudflare Dashboard or via Terraform
# Define an Access policy that requires SSO for internal services
# Example Terraform snippet (conceptual):
resource "cloudflare_access_application" "internal_app" {
  domain   = "internal.example.com"
  name     = "Internal Service Access"
  session_duration = "24h"
  auto_redirect_to_identity = true
  cors_headers = ["*"]
  # Enforce that only corporate SSO identities can reach the service
}

3. Set short DNS TTLs on public records to reduce the window for rebinding, and use Cloudflare DNS policies to return consistent results for a given client when necessary:

# Cloudflare DNS API example to set TTL
curl -X PUT "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
  -H "Authorization: Bearer {API_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "A",
    "name": "api.example.com",
    "content": "203.0.113.10",
    "ttl": 60,
    "proxied": true
  }'

These measures reduce the attack surface by ensuring that internal services are not inadvertently exposed and that hostname resolution is predictable and restricted.