The Ollama server is bound to 127.0.0.1. There is no SSRF vulnerability. The cloud metadata endpoint is blocked by RFC 1918 on the server. Then someone from the team visits a malicious site for thirty seconds, and the attacker has full access to the local API.
DNS rebinding does not exploit a server flaw. The attack turns the victim's browser into an unauthenticated proxy for any service on the internal network. The fundamental distinction from classic SSRF is timing: SSRF filters inspect the URL before the request; DNS rebinding swaps the IP after validation passes.
What Separates DNS Rebinding from SSRF
Classic SSRF is a server making requests to destinations it should not, due to misconfiguration or insufficient validation. SSRF filters resolve the domain and block RFC 1918 IPs before executing the fetch. This works when the same IP is present in both validation and execution, but that assumption is not guaranteed by the DNS protocol.
DNS rebinding operates in two phases separated in time. In the first, the browser loads a page from the attacker's domain, which returns legitimate JavaScript via a public IP. In the second, the JavaScript makes a new request to the same domain, but the attacker-controlled DNS server returns 127.0.0.1 instead of the original public IP.
The browser makes a new DNS query, gets the local IP, and executes the request against localhost while maintaining the origin attacker.com. The destination server never received a URL with a private IP. The SSRF filter on the server was never consulted because the server did not initiate the request: the browser did.
Timing Mechanics: Sub-Second Rebinding in Chrome and Safari
The common assumption is that DNS rebinding depends on TTL expiration, making the attack slow and predictable. Researchers at Intruder.io documented these techniques in 'Split-Second DNS Rebinding in Chrome and Safari' (2024), eliminating the TTL dependency entirely in Chrome and Safari and reducing the total attack time to under one second.
On Safari, the attacker immediately returns the AAAA record pointing to the public server but delays the A record by 100 to 200 milliseconds. The browser loads the malicious JavaScript via IPv6 before the A record arrives. On the next request, the A record resolves to 127.0.0.1 and the rebinding is complete, with no TTL manipulation whatsoever.
On Chrome, the mechanism differs. The attacker returns an A record with the target local IP plus an AAAA record with the public IPv6 address. Chrome prioritizes the IPv6 address, loads the malicious JavaScript, and when the IPv6 connection is dropped, automatically falls back to the local IPv4. Singularity of Origin, NCC Group's DNS rebinding framework presented at DEF CON 27 by Gerald Doussot and Roger Meyer, disables HTTP keep-alive and DNS prefetching to force a new DNS resolution on each subsequent request.
Tavis Ormandy, from Google Project Zero, demonstrated the simplest variant with rbndr.us: the domain alternates between two IPs on each DNS query, with no TTL at all. That mechanism is how he identified the rebinding vulnerability in the Blizzard Update Agent. The core point is that controlling the DNS server is sufficient to control which IP the client sees on each individual query.
Modern Targets: AI Servers Without Authentication
The target profile has shifted. In 2018, it was home routers and BitTorrent clients. In 2024 and 2025, it is AI servers and development tools running on local machines with no authentication enabled by default.
CVE-2024-28224 affects Ollama before version 0.1.29. The server does not enable authentication by default, and port 11434 is frequently accessible on the local network or in development container networks. Gerald Doussot, from NCC Group, published the advisory in April 2024: any browser that visits a malicious page can execute full Ollama API calls, exfiltrate files from the host, and manipulate loaded models, without any credentials.
In 2025, HackerOne report 3176157 documented the same vector against Burp Suite's MCP server on port 9876. The absence of origin validation allows DNS rebinding to access all of Burp's MCP tools, using the tool as an authenticated proxy into corporate internal networks.
The AWS IMDS chain requires the X-aws-ec2-metadata-token-ttl-seconds header on the first request and returns a token valid for 21600 seconds. The attacker rebound to 169.254.169.254 and the JavaScript executes a PUT /latest/api/token with custom headers to acquire an IMDSv2 token. This step is impossible via HTTP redirect in classic SSRF because redirects cannot set arbitrary headers. The browser's fetch() can. Intruder.io documented full IAM credential exfiltration through this path, reaching the /latest/meta-data/iam/security-credentials/<RoleName> endpoint.
The Docker daemon on port 2375 without authentication, kubelet on 10250, and Prometheus metrics endpoints are all reachable when Host header validation is absent.
Why SSRF Allowlists Fail: TOCTOU (Time-Of-Check Time-Of-Use) Across Two DNS Resolutions
A URL allowlist with DNS resolution is a defense with an exploitable time window. Validation and execution are two separate steps, and each step can trigger an independent DNS resolution. The attacker controls the DNS server and can return different IPs on each call.
CraftCMS documented this scenario in advisory GHSA-gp2f-7wcm-5fhx. The URL allowlist resolved the domain to a public IP during validation and the check passed. By the time the webhook executed, the attacker's DNS server returned 169.254.169.254. The SSRF filter never saw a private IP because the private IP appeared only on the second resolution, after the check.
This is a race condition the attacker controls because they are the DNS server. Any system that validates a URL and then fetches that URL in separate steps, with independent DNS resolutions, carries this vulnerability structurally. It is not a CraftCMS-specific flaw; it is a property of the two-step validation model where DNS resolution can change between steps.
Application-layer blocklists see the public IP and approve the request. AlphaSOC (DNS analytics platform) detects the attack at the DNS layer, where the resolution to 169.254.169.254 is visible before the HTTP request reaches the application layer.
IMDSv2 does not close this window. IMDSv2 blocks SSRF via HTTP redirect because redirects cannot set the X-aws-ec2-metadata-token-ttl-seconds header. DNS rebinding uses the browser's fetch(), which sets arbitrary headers directly on the request, bypassing exactly the protection IMDSv2 offers against server-side SSRF.
Defense: DNS Pinning, Interface Binding, and Host Validation
Three controls close the TOCTOU window. URL allowlists without DNS pinning are not among them.
CORS offers no protection: the browser treats the origin as the attacker's domain, which matches the request host after rebinding, so the same-origin policy is satisfied by the attack mechanism itself.
DNS pinning: when the application resolves a domain, the result is stored for the session and any subsequent resolution to a different IP is rejected. This eliminates the TOCTOU window entirely because every resolution returns the same immutable IP. CraftCMS's fix for GHSA-gp2f-7wcm-5fhx implemented exactly this pattern.
Host header validation: services that should not be browser-accessible must reject any request where the Host is not on an explicit allowlist. After rebinding, the browser sends Host: attacker.com. A service that validates the Host rejects the request regardless of the TCP connection's source IP.
Interface binding and Host validation are complementary, not alternatives. Binding to 127.0.0.1 reduces the surface, but Chromium bug 1300021 causes 0.0.0.0 to resolve to localhost on Linux and macOS, bypassing Chrome's Private Network Access. Host validation closes that bypass.
For detection: monitor DNS responses where public domains resolve to RFC 1918 or link-local ranges (169.254.0.0/16, 10.0.0.0/8, 127.0.0.0/8). AlphaSOC fires when any domain resolves to 169.254.169.254 at the DNS layer, before the HTTP request reaches the application. HTTP-only monitoring misses this signal entirely because the private IP never appears in application logs.
SSRF was fixed at the server layer and the industry moved on. DNS rebinding is the same class of attack without the server: the victim's browser is the proxy, the attacker's domain is the credential, and the SSRF blocklist never sees a private IP because the private IP appears only on the second resolution, after the check. DNS pinning and Host validation are the minimum floor for any service that should not be reachable from a web page.
Top comments (0)