Cache Pollution via Unkeyed GET Parameters on www.omise.co

How it was found

The CDN serving www.omise.co appears to cache pages based on the full URL, including arbitrary query parameters, without normalizing or properly keying them. This allows an attacker to send requests with varying GET parameters ?test=123, ?abc=xyz, etc. to the same page (e.g., /en/contact-sales) and cause each version to be cached separately, even if the page content is identical.

This behavior results in cache pollution, where the cache is filled with redundant versions of the same page, potentially causing:

• Resource exhaustion on the CDN.

• Inconsistent user experience if malicious parameters affect rendering (e.g., error injection, redirect loops).

• Possibility for future Web Cache Poisoning if a parameter is reflected in the response.

Steps To Reproduce:

1- Choose a publicly cacheable page such as: https://www.omise.co/en/contact-sales 2- Send a request with a unique GET parameter:

GET /en/contact-sales?test=123 HTTP/2
Host: www.omise.co

3- Observe the response headers: CF-Cache-Status: HIT

Age: <increasing> (indicates cached response)

4- Send another request with a different parameter:

GET /en/contact-sales?abc=456 HTTP/2
Host: www.omise.co

5- Observe that this too gets cached independently.

Supporting Material/References:

• /en/contact-sales?test=123

• /en/contact-sales?abc=456

• /en/contact-sales?polluted_param=

• Each receives a separate CF-Cache-Status: HIT and a new Age.

  • [attachment / reference]

{F4428092}

Suggested Fix:

• Implement cache key normalization, ignoring unknown or unimportant GET parameters.

• Alternatively, whitelist only certain parameters to be considered in cache keys.

• Use surrogate keys or vary headers carefully to control what’s cacheable.

Impact

• An attacker can generate a large number of unique query variants to:

• Pollute the CDN cache.

• Evict useful cache entries (denial of service on popular pages).

• Potentially inject harmful content if parameters are ever reflected.

• Could be weaponized in combination with future application logic changes or lax CSP/HTML output.

Thank you!

I'm happy to provide further details, logs, or conduct coordinated retesting. Let me know if a more detailed technical PoC is required.