Cloudflare Image Proxy CSPT Exploit Explained

The CSPT (Client-Side Path Traversal) vulnerability has recently attracted considerable attention from bug bounty hunters and security researchers because of its flexibility and the variety of real-world impacts it can enable. CSPT arises when user-controlled input is inserted directly into client-side request paths (for example in fetch, XMLHttpRequest, or any other browser-initiated request) without proper validation or sanitization. When that input can alter the request path, an attacker may be able to change the request path to sensitive endpoints, leading to attacks such as forced actions, or cross-site request forgery.

If you’re not familiar with CSPT or want to learn more, you can read more about it here:
CSPT Resources – Doyensec Blog

Why Cross-Origin CSPT Matters?

As mentioned, in CSPT the attacker’s input is placed into one of the request paths, which lets the attacker move between paths and change the request’s destination. But an important question arises: can CSPT change the request’s host or send the request to a different subdomain?

To answer that, first we must understand why sending a request to another origin helps. Imagine:

You found a CSPT on company.tld and can send a PUT request to that domain, but there are no sensitive endpoints on that domain. In that case the exploit has little real effect.
However, in the same organization there might be a more sensitive origin like api.company.tld that hosts sensitive endpoints (for example, change user data, manage tokens, ...). If you can change the host from company.tld to api.company.tld and send the request there, then the CSPT becomes useful and can have real impact.

Similarly, sometimes you find CSPT on low-value subdomains; in those cases your goal is to change the host so you jump from that subdomain to a more sensitive subdomain and carry out the attack.

Therefore, checking whether a CSPT can send requests to other origins is operationally critical, because only then can you turn an apparently harmless gadget into a real, impactful exploit.

How to Change the Origin: 307 / 308 Redirects

Browsers handle redirects in different ways. For our purpose, only 307 Temporary Redirect and 308 Permanent Redirect are useful, because they preserve the original HTTP method, body, and headers. When a browser sends a request and receives one of these redirects, it automatically follows it without changing the request. Other redirect types, such as 301 or 302, may instead change a POST request into a GET, which can break the intended behavior.

Important caveats:

Cookies and SameSite: If the destination relies on cookie-based authentication, cookies are forwarded according to their SameSite policies.
Authorization header: Browsers do not forward the Authorization header automatically during cross-origin redirects. If a target API authenticates exclusively via Authorization: Bearer ... headers, this redirect method will not work.
CORS: Even if you can get a redirected request to reach another origin, the destination must allow the request via CORS.

Practical Gadget - Cloudflare Image Transform

One gadget that demonstrates these mechanics is Cloudflare’s Image Transformation redirect behavior. The image transform endpoint can be abused to issue a 307 redirect to another subdomain, including custom path. That makes it an excellent way to hop between subdomains inside the same domain:

https://company.tld/cdn-cgi/image/onerror=redirect/https://subdomain.company.tld/<path>

Exploitation Workflow (Cloudflare Gadget)

Identify the CSPT vulnerability. Find a client-side request that inserts attacker-controlled input into a request path, for example fetch(baseUrl + userInput) or code that builds a URL from user input and then requests it.
Target gadget. Cloudflare Image Transformation or any open-redirect vulnerability that can issue a 307/308 redirect.
Chain the redirect to the sink. Build a URL that, when the sink requests it, triggers the open-redirect gadget and returns a 307/308 pointing to your target host/subdomain
Exploit CSPT cross-origin. Because the redirect preserves method and body, the sink’s request will be forwarded to the chosen host, enabling cross-origin actions (CSRF, data exfiltration, etc.) depending on the target and the request details

Limitations and Realistic Impact

Not every CSPT finding leads to a high-impact exploit. With the approach described here might be open more ways yo you to exploit the CSPT with highest impact, but there are important limitations to keep in mind.

First, successful cross-origin requests usually depend on CORS being permissive for the target domain or subdomain, something that is common but not guaranteed.
Second, browsers do not forward Authorization headers when following 307/308 redirects, which can prevent some attack flows (This approach is mainly recommended for web applications vulnerable to CSPT that rely on cookie-based or custom-header authentication)

Also sometimes you can find 307 or 308 open redirects that make the browser forward headers to attacker controlled origin and hijack them. If you don’t have any of those, you can use gadgets like Cloudflare’s image transformation API to increase the chance of a good impact. It still depends on the target’s setup, but hopefully one the tricks work for you ;)