PDF Export SSRF with a Redirect and IMDSv2

Yes, the feature is designed to fetch a user-supplied URL server-side, so the question is whether you can control the destination and observe the fetch. Start without internal targets. Host a page on attacker.example that contains unique text, submit its URL to the PDF export, and check the collaborator logs for an HTTP request from the reports.example.com egress address. The request should include a server-side user agent or at least an IP that is not yours. If the PDF output contains the unique text, that independently proves server-side rendering.

Next, test redirect behavior. Create https://attacker.example/r that returns 302 Location: https://attacker.example/landing. Submit /r and check whether the collaborator logs a second request to /landing. If it does, the fetcher follows redirects. That matters because the blocklist is applied to the original URL string and not to the redirect target. Neither test touches an internal address, so it is safe and within a typical program's rules. If the fetcher does not follow redirects, the redirect bypass is unavailable, but the basic SSRF is still confirmed.

The blocklist is a regex on the URL string, so it checks the hostname you submit, not the final destination. Use a redirect on your own server:

https://attacker.example/r returns 302 Location: http://internal-admin.corp.local/

Submit https://attacker.example/r to the PDF export. The original URL passes the regex because it contains only your public hostname. The fetcher follows the redirect and connects to internal-admin.corp.local, which resolves internally. The blocklist is never re-applied. IMDSv2 does not help here because the target is not the metadata service; it is an internal HTTP service. If the PDF includes fetched page text, you can read the response. If it fails, you may still infer existence from error text, response time, or a blind callback if the internal service can be induced to make one.

The limits are the three-redirect cap, the five-second timeout, and internal DNS resolution. If the internal service requires a specific Host header, the fetcher will send the hostname from the redirect URL, which is usually correct. If the blocklist also resolves DNS and checks the IP after redirects, this bypass fails; the setup says it does not. Do not use this to reach the metadata service after IMDSv2; it would require a PUT token request, which the PDF fetcher likely cannot perform. The internal admin service is the better target.

Prioritize validating the final destination, not the first URL string. Resolve the hostname to IP addresses, reject private, loopback, link-local, and metadata ranges, and repeat that validation on every redirect. Better, disable redirects entirely for the fetcher or limit them to an allowlist of trusted domains. A string regex on the original URL is insufficient because redirects, DNS rebinding, and alternate IP encodings can change the destination after the check.

Use an allowlist of approved destinations if the business only needs known reporting sources. Run the fetcher in a separate network segment with an egress firewall that blocks internal ranges and the metadata service. Enforce IMDSv2, but do not treat it as the primary SSRF control. Add a dedicated egress proxy that performs DNS resolution and IP validation at connection time. Log the resolved IP and redirect chain for each fetch, and return generic errors instead of internal response details. The order is: final-destination validation and redirect re-validation first, then network egress controls, then IMDS hardening. The first two address the root cause; the last reduces impact.