While conducting security research, I discovered an SSRF (Server-Side Request Forgery) vulnerability in an application’s proxy and file parsing APIs. This vulnerability could be bypassed using a DNS rebinding attack. I reported it to the simstudioai/sim project; the development team fixed it quickly, and it was assigned CVE-2025-69660. In this post, I explain how the vulnerability worked, how the DNS rebinding attack was performed, and how the fix was implemented.

What is SSRF?

SSRF (Server-Side Request Forgery) is a security vulnerability that allows an attacker to make the server send requests to its own internal network or localhost. This vulnerability typically occurs when an application directly fetches a URL provided by a user.

SSRF vulnerabilities are particularly dangerous because they can:

  • Provide access to the server’s internal network
  • Access localhost services
  • Access cloud metadata APIs (AWS, GCP, Azure)
  • Bypass authentication on internal services

What is DNS Rebinding Attack?

DNS rebinding is an attack technique where an attacker changes the DNS records of a domain they control, causing the same domain to resolve to different IP addresses. This attack is particularly effective against TOCTOU (Time-of-check-to-time-of-use) vulnerabilities.

How DNS rebinding attack works:

  1. The attacker initially points a domain they control (e.g., evil.com) to a public IP (e.g., 93.184.216.34)
  2. The application validates the URL and accepts it as valid because it resolves to a public IP
  3. When the DNS TTL (Time To Live) expires, the attacker redirects the domain to a private IP (e.g., 192.168.1.1)
  4. When the application performs the fetch, the domain now resolves to a private IP and the attack succeeds

Vulnerability Discovery

I found an SSRF vulnerability in the /api/proxy and /api/files/parse endpoints of the simstudioai/sim project. These endpoints were validating URLs provided by users but were not protected against DNS rebinding attacks.

Vulnerable code logic:

  1. URL was validated (protocol, format check)
  2. It was checked whether the hostname resolved to a private IP
  3. If valid, the URL was fetched

The problem: There was a time gap between validation and fetch. During this time, DNS records could change.

Bypassing with DNS Rebinding

To bypass this vulnerability using a DNS rebinding attack:

  1. I initially pointed the evil.com domain to a public IP
  2. When the application validated, the domain resolved to a public IP, so it was accepted as valid
  3. When the DNS TTL expired, I redirected the domain to a private IP like 192.168.1.1
  4. When the application performed the fetch, the domain now resolved to a private IP and the SSRF attack succeeded

This attack is particularly dangerous in cloud environments because it can:

  • Access AWS metadata API (169.254.169.254)
  • Access internal services
  • Access localhost services

Fix: DNS Pinning

The development team fixed the vulnerability using DNS pinning. DNS pinning resolves a hostname’s IP address once and then uses that IP for all subsequent requests.

How the fix works:

  1. validateUrlWithDNS() function was added
  2. This function resolves the hostname once and returns the IP address
  3. The IP address passes private/reserved IP checks
  4. The createPinnedUrl() helper function replaces the hostname with the resolved IP
  5. The fetch operation is performed with the pinned IP, but the original hostname is used in the Host header

Advantages of the fix:

  • Prevents DNS rebinding attacks
  • Eliminates TOCTOU vulnerability
  • Comprehensively blocks private/reserved IPs (IPv4/IPv6 loopback, private ranges, link-local, carrier-grade NAT)

Blocked IP ranges:

  • IPv4 loopback: 127.0.0.0/8
  • IPv4 private ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  • Link-local: 169.254.0.0/16
  • Carrier-grade NAT: 100.64.0.0/10
  • IPv6 loopback and private ranges

Conclusion

SSRF vulnerabilities are dangerous, especially when combined with DNS rebinding attacks. Fixing this vulnerability improved the application’s security.

Lessons learned:

  • When validating URLs, DNS rebinding attacks must be considered
  • DNS pinning should be used to avoid TOCTOU vulnerabilities
  • Private/reserved IPs must be comprehensively blocked
  • When conducting security research, testing edge cases is important

Finding and fixing such vulnerabilities improves web application security. If you find similar vulnerabilities, report them to the development team following responsible disclosure principles.

Related content:

Resources: