Authenticated SSRF Reaches Cloud Metadata Service via DNS Rebinding, Full Response Disclosed

The Vulnerability

The platform's chatbot integration component let any authenticated tenant register an HTTP "destination" with a target URL and then call a test endpoint. The backend issued a server-side outbound HTTP request to the configured URL and returned the response body, status code, and every response header verbatim inside an invocationData.response envelope. The Authorization header and most other request headers were attacker-controlled and proxied through unchanged. Four HTTP methods were accepted: GET, POST, PUT, DELETE.

An IP allow-list rejected the obvious unsafe ranges (private networks, loopback, link-local, and various decimal, hex, and IPv6 encodings). The allow-list was enforced only at destination-creation time, using a single DNS resolution. At fetch time the hostname was resolved again and used directly without re-validation. That gap was the entire bypass.

The Attack

Bypassing the IP allow-list with DNS rebinding

A public DNS rebinding service was used to register a hostname that returned two different A records on every query with a TTL of zero. One record pointed at an arbitrary public IP (which passed the allow-list at creation time). The other pointed at the cloud metadata service IP (which would have been blocked at creation time). The backend resolved the hostname twice: once at creation, once at fetch. When the fetch-time resolution landed on the metadata IP, the request went through.

The race was probabilistic but reliable, usually winning within a handful of attempts. The PoC script created the destination, hammered the test endpoint in a loop, and watched for the response signature.

Confirmed reach to the cloud metadata service

When the rebinding race landed correctly, the backend issued a GET against the cloud metadata path and the response envelope returned to the attacker contained:

• status: 401
• server: EC2ws (a unique signature of the AWS instance metadata service)
• Round-trip time around two hundred milliseconds, consistent with a same-host hop

The instance enforced the modern token-required version of the metadata service, and the two specific headers needed to mint that token were on the backend's denylist, so this PoC stopped at proof of internal reach without actually retrieving cloud credentials. Any second flaw, a denylist regression, or a host running the older metadata version would lift this directly to credential theft.

Headers reach upstream verbatim

Pointing a destination at a public header-echo service confirmed that an attacker-supplied Authorization, Cookie, Metadata-Flavor: Google, custom markers, and X-Forwarded-For all reached the upstream byte-for-byte. The denylist blocked only the two AWS-specific token-mint headers and let every other cloud-metadata authentication header (including the GCP and Azure equivalents) pass through. Any deployment of the same component on those clouds would be direct credential theft with no further bypass needed.

The Impact

As any authenticated tenant of the platform, an attacker could:

• Reach arbitrary internal services in the integration component's private network, including the cloud metadata service. The full HTTP response (body, status, every header) was returned to the calling tenant in the invocationData.response envelope.
• Forward attacker-controlled Authorization, Cookie, and other request headers across four HTTP methods to those internal services. Combined with the cross-tenant decryption issue tracked separately on the same target, the SSRF became a relay primitive carrying a victim tenant's credentials.
• Stop only at cloud credential theft because the modern token-required metadata version was enforced and the two token-mint headers were denylisted. Any second SSRF, a denylist regression, or a host running the legacy metadata version would lift this immediately to full role compromise of the integration backend.

Remediation

• Remove the upstream response body and headers from the test endpoint's response. Users only need pass or fail and a status code, not the full upstream body.
• Re-resolve the destination hostname immediately before each outbound fetch and re-apply the IP allow-list to the resolved address. Reject if the fetch-time resolution differs from the creation-time resolution, or pin by IP at creation time. This closes the rebinding race directly.
• Disable HTTP redirect following on the outbound HTTP client unconditionally, so that a public-to-internal redirect cannot bypass the allow-list either.
• Expand the request-header denylist to cover the full cloud-metadata header set (the AWS, GCP, and Azure equivalents) rather than only the AWS token-mint headers.
• Gate the test endpoint behind a non-production debug role or remove it from production entirely. Day-to-day destination configuration does not require the upstream response to be echoed back.